Zugata Team Analytics

I led the visual and UX for this project, and collaborated with engineers to ship.

Better insights, better managers

Zugata's mission is to "help employees reach their full potential." Everyday, people come to Zugata to give feedback to their teammates. The peer feedback is then used to recommend people learning resources and facilitate conversations in 1:1 meetings.

Because our product collects valuable employee feedback/skill data, we identified an opportunity to help managers make better decisions by empowering them with team insights. To begin with, I read up research on management and interviewed a few managers to understand the challenges they face on their job.

Finding the right product-market fit

While we have a general direction, we were not sure what the exact problem we should solve at the beginning. Therefore, the design process consists of exploring and refining the problem in order to find the right product-market fit.

Defining the audience

Initial persona: Managers in 100+ people organizations who manages 10+ people.

I didn't target managers of small team because I assumed those managers are likely to have close interactions with individual team members, which negates the need to rely on data to understand their team.

Defining a meaningful goal

After considering our grand product vision and the role of managers in large organizations, I think our Analytics feature should:

Help managers build better teams

Understanding the underlying
system and constraints

I started the design process with understanding how data flow through our product. How does the product collect data? How long does it take to collect enough data? How reliable the data is? What are the constraints of the data?

The product collects data as people binarily rate their co-workers’ skills

Hypothesis: what’s useful?

At the beginning, I assumed there are 2 types of data that could help managers develop their teams:

1) Team skill scores, because managers need to know what educational resources to provide or what to look for in new hires.

2) Number (and trend) of feedback given and received by employees, because managers could use this as a proxy to measure the culture of openness and "hard conversation" within their team/company.

Getting internal alignments

Based on the assumptions I’ve made, I sketched out low-fidelity wireframes to explore as many possibilities as possible. I shared these sketches with the team and gained some internal feedback. Our engineers argued that aggregating team skill data was not actionable for manager. Our community manager thought we should prioritize feedback data instead of skill data. Sharing low-fi sketches early on helped facilitate internal discussions and got the team on the same page.

Some of the early low-fi explorations

User testing

After gathering internal feedback, I picked a few directions and developed them into high-fi mockups. I gathered some user insights, and shared them with team.

Module showing team skill scores


“What is the change based on?”
“What is 4 out of 5?”
“I am not sure if I care about change in %, I don’t think it will change much often.”
“It would be interesting to see deviation instead”

Module showing feedback usage


“I don’t know if I care about this…”
“Just give me a simple table, that’s too much to take in”
“I am not sure what to do with this data.”

Documenting research findings and sharing with team through Slack

Make it more actionable

One major theme from the testing is actionability. Managers are busy and they don’t want to be flooded with data. They want to know what exactly they can act on to build a better team.

Exploring a “tip kit” concept, giving managers suggestions on what to do
Suggesting specific action based on data
Making it easy to benchmark with company average

Tough choice: Saying “no” to users

One major request managers asked for was more data on employees’ individual skill scores, because it could help them make specific resourcing decisions. They can also use those data to guide and develop employees. However, by showing that, we would incur 2 main risks:

1) Managers or HR can lower compensation or fire people based on these data.

2) People are less likely to give honest feedback if they knew the data was fully open to their managers, which will harm the foundation of our entire product.

The design needs to avoid these 2 risks. While the managers and HRs are the direct users of this feature, the decisions they make based on the insights we give them can influence the whole organization. Therefore, from a bigger picture perspective, I needed to design a solution that is good for both the managers and the teams they run. I explored more ways to expose specificities without revealing individual employees skill scores.

Showing more specific data

Wait, so what's the problem again?

At this point, after various rounds of validation, we scoped down the problem to the following:

High-level managers in large organizations have very few tangible insight of their employees' competencies, thus cannot make accurate resourcing decisions such as:
1. What skills should we hire more?
2. What learning resources do we need to provide to help teams improve?
3. Which team is best equipped for this project?

Shipping with simplicity

After many design iterations, we decided to “keep it simple” for the first version: focusing on functionalities that are both easy to build and solve the above problems.


This feature has since become a core experience for high level executives and HRs to understand employee skills/competency across organization.