Performance Review Examples for Product Designers

Most designer performance-review example posts I’ve seen across the internet have a recognisable problem: they were written by someone who’s never actually opened a figma file in anger. The examples lean on generic design language (“crafts thoughtful user experiences”, “brings a strong eye for visual detail”), the design work is invisible, and the prose could be copied between any two designer reviews without changing meaning. Designers notice.

The five examples below try to do the opposite. Each one picks up a specific scenario, names specific projects, engages with specific design decisions, and treats the work as the unit of analysis rather than an abstraction. The framework behind them is in how to write a performance review for a product designer.

Example 1: Senior designer shipping a flagship redesign

Scenario: Priya, senior product designer, three years on the team. Led the onboarding redesign that shipped in March, which was the team’s biggest project of the year.

Priya led the onboarding redesign end-to-end this year and the work holds up against every level of scrutiny it’s had. The activation lift on the cohorts that went through the new flow ran from a baseline of 41% to 58% over the first two months post-launch, and the lift held through May. That’s the headline, but the work behind it is more interesting than the headline suggests. Priya ran 12 user interviews in the first month of scoping (most designers on the team would have run four or five) and the synthesis from those interviews reframed the problem from “the sign-up flow needs to be shorter” to “the sign-up flow needs to teach the product’s mental model.” That reframing is the entire reason the new flow worked, and it would not have happened without the depth of the research.

The craft on the work itself is the strongest she’s shipped. The information hierarchy on the second screen (where the user picks their primary use case) is a specific design decision I want to record: she considered four alternatives in figma before committing to the option that prioritised three named use cases over a longer list, on the rationale that a long list would tax the cognitive load at the exact moment users are forming their first impression. The empty-state treatment on the dashboard was redesigned to teach the product’s value proposition in three sentences rather than five, and the activation lift on first-week dashboard users suggests the cut paid off. The accessibility audit Priya ran in February surfaced four issues in the legacy flow that we’d been carrying for two years, and she fixed them in the redesign without making it a separate initiative.

The design-system contributions are the under-credited part of the year. Priya shipped three new components (the progress-indicator pattern used across the new flow, the empty-state component now adopted by two other teams, and the form-validation pattern that replaced the previous inconsistent implementations). These are the kind of contributions that compound across the design org for years. Priya is operating at the level of staff designer on impact and the conversation we’ve started about that step is the right next move. The remaining growth area is leading critique across the team rather than only within projects, which we’ve discussed and which she’s already started by running the Wednesday crit through Q3.

What this does well:the headline impact is contextualised with the research depth that produced it. Specific design decisions are named (the second-screen information hierarchy choice, the empty-state cut). The accessibility and design-system work gets specific credit. The forward-looking line offers a concrete next step with a named development area. Notice how the review reads as written by someone who’s actually looked at the figma files.

Example 2: Mid-level designer building strong design-system contribution

Scenario: Marco, mid-level product designer, two years on the team. Has been quietly doing more design-system work than anyone else on the team this year while shipping competently on his own feature work.

Marco’s year has two threads: solid feature work and unusually strong design-system contribution. The feature work first. He shipped the two assigned projects (the notifications redesign in Q2 and the billing-page improvements in Q3) on time, with engineering handoffs that didn’t require rework, and outcome data that landed at or slightly above the targets we set in scoping. The billing-page revision specifically lifted the upgrade-conversion rate from 3.1% to 3.6% in the first six weeks post-launch. Solid mid-level work.

The design-system work is where the case is. Marco has contributed eight components to the team’s shared library this year, three of which (the empty-state pattern, the modal-stack pattern, and the inline-validation component) are now used across more than half of the team’s product surface area. The empty-state component alone has been adopted by 14 different screens in the product, which means Marco’s thinking about empty-state UX is now in code that every user touches. He also wrote the contribution guide for the design system in May, which has materially improved the rate at which other designers add to the library. None of this work was assigned to him; he picked it up.

The case for the senior conversation in twelve months is built on the design-system work, which is the kind of force-multiplier contribution that distinguishes senior from mid-level. The growth area is taking on a single project of senior-level scope (the candidates I have in mind are the permissions redesign and the in-product help rebuild) and running it end-to-end with the same depth Priya brought to the onboarding work. That will be the next-period focus and we’ve already had the start of that conversation.

What this does well:the case for promotion is built from evidence (the specific components, the contribution guide, the adoption numbers). The feature work is credited honestly as solid-mid-level. The next-period growth area is concrete with specific project candidates. Note the line about the design-system work being “picked up” rather than assigned. That’s the specific behaviour observation that evidences seniority.

Example 3: Junior designer at end of first year

Scenario: Sam, junior product designer, joined nine months ago straight out of a design programme. First full performance review.

Sam is nine months in and operating exactly where I want a junior designer to be at this point of ramp. The headline projects look right for the stage: owning small features end-to-end (the saved-views feature in Q2 and the dashboard-filter improvements in Q3), contributing components to the design system with senior support, and shadowing on larger projects to learn how the team operates.

The growth across the year is the bigger story. In the September portfolio walkthrough, Sam was designing screens that read as competent but generic. The saved-views work in May showed the first signs of the next gear: the empty state for the feature wasn’t a generic empty state but a teaching moment for a feature most users wouldn’t discover on their own. The dashboard-filter work in September was the strongest piece of work she’s shipped, with three specific decisions I want to record. The filter-pill component she designed was general enough to be adopted into the design system and is now in use elsewhere. The interaction model for clearing filters was a non-obvious choice that tested better than the obvious one in usability testing. And the error state for malformed filter combinations turned a potential frustration moment into a guidance moment.

Sam has also been the most consistent contributor in critique, which is unusual at junior level. The feedback she gives in crit is structured, specific, and useful to the designer being critiqued. That’s a force-multiplier behaviour I want to credit explicitly. The development priorities for next year are scope (taking on a feature with more cross-functional complexity, where the design work requires real negotiation with engineering on scope and with the PM on prioritisation) and beginning to lead research engagements rather than only participating. The observation cadence will step down from monthly to quarterly.

What this does well: ramp gets its own framing rather than being measured against senior expectations. The growth across the year is named with specific projects and specific design decisions. The crit contribution is credited as a senior-level behaviour even though Sam is junior. The development priorities for next year are concrete and matched to ramp stage.

Example 4: Designer with strong process, unremarkable craft

Scenario: Dani, mid-level product designer, two years on the team. Strong on research, accessibility, design system thinking, cross-functional partnership. Craft on the design work itself is competent but rarely surprising. The team has noticed.

Dani’s year has been strong on every dimension of design work except the one most central to it, which makes this review harder to write than most. The process work is the strongest on the team. Her research engagements (three substantive interview rounds, four usability tests, one diary study) were the most thorough this year. Her specs are the cleanest engineering receives. The accessibility audit she ran in October surfaced 19 issues across the product that the rest of the team had been coasting on. The cross-functional feedback from PMs and engineering is universally positive: she’s the designer the PMs request to partner with on complex work.

The work itself is where I want to be honest. The notifications redesign she shipped in Q2 was competent and met the brief, but it didn’t surprise anyone. The settings-page rebuild in Q3 was the same: structurally correct, met the accessibility bar, shipped without rework, but rarely the design decision the rest of the team pointed at as “that was a good call.” The critique feedback from senior designers over the year has consistently flagged that her work hits the requirements without exceeding them.

I think this is fixable and I want to be specific about what it would take. The process strength Dani has built is the foundation that strong craft develops on top of, not a substitute for it. The development priority for next year is craft risk-taking: pursuing the more interesting design proposal in scoping rather than the safer one, and bringing more provocative work to critique even if it gets pushed back. The two senior designers on the team have offered to do a structured critique-pairing cadence in Q1, where Dani brings early-stage work to them weekly and they push on the design decisions specifically. I think this is the path to the senior step, and I’m confident Dani can make it. The structural foundation is already in place.

What this does well:the process strengths are credited credibly first so the harder feedback doesn’t feel like a setup. The craft gap is named directly with specific projects, not hedged behind “could push further on creative.” The path forward is concrete with a specific structured intervention. The closing line is honest about the writer’s belief in the designer’s capacity to grow.

Example 5: Strong craft, real cross-functional friction

Scenario: Jordan, senior designer, four years on the team. Universally respected for craft. Two PMs and the engineering lead have separately raised concerns about working relationship friction over the year.

Jordan’s craft this year was outstanding. The permissions redesign was the most architecturally ambitious project the team shipped, and the information design alone is worth recording: the mental-model shift from role-based to capability-based permissions is a non-trivial reframing, and the interface decisions that came out of it (the permission-pill pattern, the explain-this-permission affordance, the access-trail view) are likely to define how the team thinks about permissions UX for the next several product cycles. Three new components landed in the design system on the back of this project, and the accessibility consideration in the access-trail view was substantive in a way that accessibility consideration on most of our work isn’t.

The pattern I want to address is cross-functional working relationship, which has been the subject of feedback from two PMs and the engineering lead, and which I haven’t named clearly enough across the year. The specifics: in the permissions project, the spec went through three substantive revision cycles after engineering started building, which created roughly three weeks of unplanned rework. The PM on the project flagged in March that scope conversations had felt like negotiations rather than partnerships. The engineering lead mentioned in our June 1:1 that the team had started planning for revisions when working with Jordan rather than assuming the spec would hold. None of these are process failures by Jordan in isolation; together they’re a pattern.

I don’t read this as a craft or character question. Jordan’s work is genuinely strong and the cross-functional friction has a fixable root cause: Jordan’s instinct to keep design decisions open longer than the project timeline wants is producing the revision pattern. The development priority for next year is committing to scoping discipline: bringing the final design decisions into the kickoff conversation rather than deferring them to spec time, and naming explicitly when something is going to change after engineering has started so the team isn’t surprised. We’ve discussed this and Jordan has the self-awareness on it; the next-period work is building the new habit.

What this does well:the craft strength is named credibly first with specific design decisions credited. The friction pattern is named with specific evidence (the spec revision count, the PM’s March feedback, the engineering lead’s 1:1 comment). The root cause is identified as a fixable habit rather than a character problem. The forward plan is concrete. The closing line preserves the relationship rather than reading as a verdict.

What these examples have in common

• Specific design decisions named. The information hierarchy choice, the empty-state treatment, the filter-pill component. The reviews work because they engage with the actual work rather than gesturing at it.
• Process and craft assessed separately. Research engagement, accessibility audit, spec quality, design-system contribution: all separate from craft. Reviews that conflate them tend to over-credit process designers and under-credit craft designers.
• Design system work credited. Components added, patterns documented, adoption tracked. This is the most under-credited designer work in most reviews; the strong reviews surface it explicitly.
• The manager engages with the work. Lines like “the empty-state cut paid off” or “the mental-model shift is non-trivial” carry a point of view about design. Reviews that read as written by someone who can’t evaluate craft fail the design team’s trust test immediately.

For the designer-side counterpart (what to write in your own self-evaluation), see product designer self-evaluation examples. For tactical tips on both sides of the conversation, see performance review tips for product designers.