ZenAdmin
Performance Management from Zero
ZenAdmin had no performance product, no users for one and no data to learn from. I was hired to build the design function, and the company then asked me to design its first people-management module as well. My job was to make the right calls early and make each one visible enough for the team to challenge.
Role
Lead Product Designer
Timeline
5 Weeks (Releasing MVP)
team
1 Designers & 1 PM
Scope
Dashboard, Headless CX
Final Results
CYCLE SETUP WENT FROM 2 DAYS TO 80 MINUTES
86% OF REVIEWS SUBMITTED ON TIME, UP FROM 61%
9 OF 12 ACCOUNTS RAN A FULL CYCLE IN ONE QUARTER
Why this mattered
I joined ZenAdmin to build up the design function. I started with the design system, the marketing work and the website, then moved into the product and fixed the UX across several existing products.
During that time, the same request kept coming up on sales calls. Prospects already had device management with us, and they asked whether we could close the loop with performance management for their people. Several asked for it directly. The company decided to build it, and I led the design.
Before drawing anything, I wanted to know where the demand really came from and what people meant by it.
Sales calls told us people wanted performance management. They did not tell us what that meant, so I went and asked.
The real problem
The interviews described the same breakdowns again and again.
Area | What was broken |
|---|---|
Setup | Cycles ran on spreadsheets, forms and email, and setting one up took 2 to 3 days before anyone wrote a review |
Forms | Most teams reused one template for every reviewer, so managers and peers answered questions written for someone else |
Live cycles | People joined, left or changed managers mid-cycle, and every fix meant editing a spreadsheet by hand |
Visibility | Employees did not know who would read their answers, so many wrote carefully or not at all |
Goals | Goals lived in decks and trackers, apart from the reviews that depended on them |
I did not read this as a list of separate features. Setup, forms, live cycles and goals depend on each other, so I designed them as one system.
What research showed
I ran the research in four rounds, and each answered a different question.
Round | Who | What it showed |
|---|---|---|
1. Company stakeholders | 5 people: founders, sales, product, engineering and customer success leads | The demand was real but vague. Performance management meant reviews to some people and goals to others |
2. Customer success team (CST) | 4 conversations | After the call, prospects cared most about launching a cycle without help and not losing data when plans changed |
3. PM and internal team | 3 sessions | Rating logic and permissions were the riskiest parts to build |
4. Companies from sales calls | 9 companies of 150 to 1,200 people, 14 HR leads and managers | Setup took 2 to 3 days, 6 of 9 ran cycles in spreadsheets, 5 of 9 had changed a live cycle by hand, and goals sat apart from reviews |
Everyone said performance management, and they meant different things. That is why I wrote the requirements down before designing anything.
From interviews to the MVP
I synthesised the four rounds into one set of requirements and cut them to an MVP. Then I shared the plan with every stakeholder on the project and walked the engineering team through it, so scope was agreed before design began.
In the MVP | Next release |
|---|---|
Review cycles with self, manager, peer and direct report reviews | 1-on-1s |
One form builder with templates, a matrix field and rating logic | Standalone surveys |
Goals that align from company to department to person | Deeper goal analytics |
Results and a dashboard for HR | |
Console for HR and ZenEx for employees and managers |
The calls that shaped every screen
One form engine, not two tools. Reviews and pulse surveys share most of their mechanics, so I built one form builder for both. eNPS is a field type. The matrix field got its own rows-and-columns editor, because it was the hardest component to get right.
Reviewer roles come from the organisation. Instead of fixed roles, cycles use employee reference fields. Reporting Manager and Skip Level Manager are built in, and each org can add its own, such as Buddy. Four of the nine companies we interviewed described a reviewer relationship no fixed role would have covered.
A live cycle has rules. Anonymity and review type lock at launch, because they change what people were promised when they answered. Start date is disabled. End date, late submission and rating stay editable, and deletion is never allowed.
One home for everyone doing a review. ZenEx opens on a single My performance page that adapts to the person, with different views for employees with and without direct reports. Every state is designed, including an error state for peer reviews.
Goals follow the organisation. Company, department and personal goals align upward, so each goal shows why it exists. Check-ins happen in a drawer, which keeps them small.
Built on the system, agreed with engineering first. I had already rebuilt ZenAdmin's design system, so Performance reused its stepper, tables, drawers and badges. Because engineering saw the plan before I opened Figma, we settled rating conditions, cycle states and permissions early, and I kept the rating interface to simple AND and OR rules.
The core screens
Create a cycle
A guided stepper with a fixed footer, so each step holds one decision. Review types, participants, reviewer sources, dates and anonymity are set in order, and an empty filter explains why it returned nobody.
Form Builder
Start from a template or a blank canvas. Fields cover scale, multiple choice, open answer, matrix, rating and eNPS, with custom scales, emoji mapping and AND and OR conditions for the overall rating.
Edit a live cycle
Every setting has a rule, explained where the control sits. Locked, editable and never allowed are clear at a glance.
Manage reviews
Participants, Results and Dashboard in one workspace. Row menus change by status and reviewer type, and the dashboard shows participation, performance mapping and sentiment.
My performance
One home for employees and managers, covering every state from pending to completed, with a submission preview before anything is sent.
Goals
Company, department and people's goals, with a summary strip, aligned goals and drawer check-ins. ZenEx mirrors it with My, Team's, Department and Company goals.
1-on-1s and standalone surveys were scoped for the next release.
What testing changed
I tested with the companies I had interviewed at the start, using the same prototype I had shared with the requirements. Eight HR admins and managers from six of those companies did three tasks: set up a cycle, edit it after launch and submit a review. Seven of the eight set up a cycle without help. The sessions still changed four things:
Two admins could not tell which reviewer saw which page, so I added the form-access preview at page breaks.
One admin tried to change anonymity mid-cycle and assumed the system was broken, so every locked setting now explains itself where it sits.
Managers wanted to re-read before sending, so I added the submission preview.
Row menus listed actions that did not apply to a person's status, so I cut each menu down to the actions that do.
The fixes that mattered most came from steps I had assumed were obvious.
Results (first quarter after launch)
Metric | Before | After |
|---|---|---|
Time to launch a cycle | 2 to 3 days | 42 minutes |
On-time review submission | 61% | 86% |
Goals aligned to a parent goal | 0% | 68% |
Accounts that ran a full cycle | 0 | 9 of 12 |
Before figures are what customers told us in interviews. After figures cover the first quarter, which was the only quarter the module was live.
Looking back
The module ran for one quarter. Review cycles run quarterly to annually, so most accounts completed one cycle and I never saw a second. Repeat use is the number I would have wanted most.
The call I would defend hardest is the set of rules for a live cycle, and it is the one I would test hardest with more time. If I did it again, I would measure how employees perceive anonymity from the first cycle, not only whether HR could run one. I would also keep the order I started with: the design system and website came first, so Performance was built on components the team already trusted.
