How can we design a performance review system where managers always know what to do and what's next?
ROLE:
LEAD PRODUCT DESIGNER
TIMELINE:
OCT 2025 - FEB 2026
SKILLS:
DESIGN, RESEARCH, AI PROTOTYPING, PRODUCT
ABOUT
Lattice is a people platform supporting performance, growth, engagement, and compensation. Reviews is its flagship product — the foundation that originally defined the company and continues to drive adoption.
Over time, Reviews expanded to include peer nominations, multi-directional feedback, calibration, and more. What began as a focused workflow evolved into a complex system of features and states. The result: rising manager confusion, 57% CSAT, and growing admin dependency.
To maintain our leadership in performance management, Reviews needed to be structurally rethought — not patched.
CHALLENGE
Across workflow audits, data, and customer interviews, we found a pattern: users could not orient themselves. They failed to answer simple questions like what phase are you in, what actions are left, how far along are your direct reports, and more…
Recurring customer feedback included:
✷ “Duos had no idea what phase they were in.”
✷ “The steps for managers to check on review status was awfully cumbersome.”
✷ “Review sharing takes 3+ clicks—RMs often miss the final step.”
✷ “Confusion around ‘Submitted’ vs ‘Submitted and Shared’.”
✷ “Admin is overwhelmed by the hours spent explaining Lattice UI.”
Customers weren’t asking for more features. They were asking for predictability.
PROCESS
Principles
✷ Design for Role Clarity: The experience should clearly separate responsibilities between individual contribution and managerial oversight.
✷ Make Statuses Crystal Clear: Treatments for progress and statuses should be predictable.
✷ Optimize for Primary actions: Frequent bulk actions like approving, sharing, reminding should be frictionless. High-stakes actions should require more intent.
✷ Design for “Nothing Required” States: Users should clearly know when there's nothing needed from them.
Structural Decisions
Introduced Role-Based Navigation (Me / My Team): Instead of organizing by feature or phase, we structured the system around responsibility.
✷ Overview for cycle details and tasks
✷ Me for sequential personal tasks
✷ My Team for parallel managerial oversight
This reduced cross-role cognitive switching and aligned directly with manager mental models we discovered during research. The original phase-based navigation blended both modes into a single linear structure which created cognitive switching and confusion.
Retained Phase Outline as Context — Not Navigation
Managers wanted phase awareness across both views. We updated the stepper to more accurately communicate process across Me and My Team, but intentionally made it non-interactive.
On Me, it reinforces a sequential journey. On My Team, it serves as a temporal cue without implying a linear manager workflow. This preserved shared context without allowing users to navigate ahead to phases that were still closed.
Rebuilt Action Hierarchy
Rebuilt approval and sharing flows around clarity:
✷ Primary actions like Approve All, Remind, Share should be quickly accessible
✷ High stakes actions like decline, override should require explicit intent
✷ Nothing should take 5+ clicks!
Added a Review Cycle Summary as a Verification Surface
Introduced a lightweight confirmation layer where managers could spot-check actions from throughout the review cycle: Peer Nominations, Review Writing, Review Packets, Promo Status.
Not a new workspace — just a trust checkpoint.
TRADEOFFS
Phase awareness vs. phase control
Managers need to understand the phase, but they don’t control phase progression. So I kept the stepper as a visual cue across both views, but made it non-interactive.
Why: Clarified system state without implying false control to users.
Speed vs Safety
We optimized approvals for confident defaults with a fast “Approve All” path while requiring explicit intent for high-stakes exceptions like declines.
Why: Most managers trust their team and want to move quickly, but declining a nomination or review can impact careers and morale. The design needed to support speed without normalizing irreversible decisions.
Features vs Predictability
Customer feedback always pushes for more features, controls, and configurability. For this project, I prioritized clearer status signals over adding new features or UI surfaces.
Why: Predictability reduces admin dependency more than feature density. And adding additional complexities to the existing system creates for futher rework.
Side Panel vs In-page experience
Primary actions and additional context originally lived in a side panel but Lattice Design sytem was moving towards using the side panel for AI agent interactions. I moved core workflows and additional context to live in-page.
Why: Prevented pattern fragmentation and future rework/conflict as Lattice's AI patterns are evolving.
RESULTS
The redesign made Reviews feel predictable, guided, and self-serve.
Beyond usability, the work established a reusable role-based architecture for multiple cyclical products @ Lattice for long-term scalability.
In usability testing, managers consistently:
✷ Identified the current phase
✷ Knew whether action was required
✷ Approved and shared with confidence
✷ Felt comfortable when nothing was needed
Rated ease of completing the cycle: 4.6/5
Rated navigation intuitiveness: 4.8/5
Defining the Cutline & Success
With a 1-month dogfood timeline, I established a hard cutline to ensure we validated the structural shift before investing in refinements.
I prioritized: Role-based navigation, Phase outline, High-frequency manager actions
Success criteria
✷ Reduction in approval and sharing clicks
✷ ≥4/5 clarity rating in phase-based pulse surveys
✷ No increase in navigation-related support pings
✷ Internal dogfood slack channel
