Performance Review Tips for Product Designers

Designer performance reviews have a hard job to do. They have to give the designer usable signal about their craft, hold up at calibration meetings against engineers and PMs whose work is more legible to non-designers, satisfy the design org’s own rubric, and avoid the generic-designer voice that strong designers recognise as filler. Most reviews I’ve read fail at least one of those four. The tips below are about not failing them.

Three sections: tactics for design managers, tactics for designers writing self-evaluations, and the moves both sides should get right. For the underlying framework, see how to write a performance review for a product designer.

Tips for design managers

1. Open the figma files, don’t just look at shipped screens

The shipped surface tells you what got built. The exploration file tells you how the designer thinks. How many directions did they explore before converging? Are the rejected directions thoughtful or thin? Is the file organised in a way someone else could pick up? The exploration is where craft and judgement live, and reviewers who only look at the shipped screens miss the most informative evidence in the year.

2. Read the design rationale docs

Strong designers leave a trail of writing behind their work: design rationale docs, project briefs, critique posts, slack threads where they defended a direction. Read three or four pieces from the year. The writing tells you whether the designer can articulate their decisions to non-designers, which is half of what senior craft actually is. A designer whose writing is muddy is a designer whose cross-functional influence is capped, regardless of what their figma frames look like.

3. Talk to two engineers and two PMs before drafting

Ten minutes per conversation, forty minutes total. The engineer who built this designer’s work and the PM who scoped it with them will tell you things the figma file can’t. You’re looking for patterns: did the designer scope responsibly, surface trade-offs early, stay engaged through build, defend the right hills, fold on the right ones? The cross-functional read is usually the part of the review that’s most underweighted on the manager-only draft.

4. Don’t use shipped-feature count as a proxy for impact

A designer who shipped six small surfaces and a designer who shipped one flagship redesign are not comparable on volume, and the volume comparison usually favours the wrong one. Read what they shipped, look at the impact numbers and the design complexity, and weight accordingly. Calibration rooms that anchor on shipped-feature count consistently under-rate the designer doing the harder work.

5. Credit design-system and shared-craft work explicitly

Component contributions, pattern documentation, accessibility work, design-tokens, icon-set stewardship. None of it sits on a product roadmap and most of it improves twelve surfaces at once. The designer who quietly carries this work is doing force-multiplier work; a review that doesn’t name it explicitly is a review that’s about to under-rate someone. If you’re not sure how much they’ve contributed, the design-system lead can tell you in five minutes.

6. Don’t deliver new feedback at review time

If a designer is hearing a piece of feedback for the first time in writing at the annual review, the critique cadence and the 1:1 cadence have both slipped. The review should formalise things you’ve been saying across the year, not introduce them. Designers notice surprise feedback in review documents immediately and the trust cost is real and lasting.

Tips for designers writing self-evaluations

7. Build your portfolio sweep in early November

Self-evaluations written the night before they’re due lean on the shipped-feature list and generic craft language. Sixty minutes in early November, pulling the figma links for your two or three proudest projects, naming three craft moments, and writing down one piece of work that didn’t land, gives you the raw material for the actual writing. See the prep step in product designer self-evaluation examples for the full list.

8. Lead with the design decision, not the feature

“Shipped the onboarding redesign” is a feature. “Reframed the onboarding problem from reducing setup friction to teaching the product’s mental model in the first three screens, which took activation from 41% to 58%” is a design decision plus an outcome. The decision is what makes the work yours. The feature is what makes the work the team’s. Calibration rooms read the decision and weight you for it.

9. Name one specific craft moment you’re proud of

On the “biggest impact” prompt, include one specific craft moment alongside the project- level claim. The empty-state that solved a comprehension problem in three lines of copy. The micro-interaction that quietly cleared up the progress confusion. The IA decision in the permissions model that turned three settings pages into one. These moments are what strong design actually is and they’re invisible in the shipped-feature list.

10. Surface the work beyond your projects

The design-system components you contributed. The critique culture you helped shape. The earlier- career designer you informally mentored. The research-practice change you advocated for. The cross-functional process improvement you ran. These don’t sit on the shipped roadmap and they’re where senior design lives. If you did this work and didn’t write it into the self-evaluation, the calibration room doesn’t see it.

11. Name one project that didn’t land as well as you wanted

On the “what didn’t go well” prompt, pick a real project and tell the story. Not “I’d like to be more proactive with stakeholders,” which evidences nothing. “The notifications redesign opened with three weeks of visual exploration before a diagnostic research round surfaced that the actual user complaint was grouping logic, not row treatment. I’ve added a one-week diagnostic step to my process on all existing-surface redesigns” evidences design self-awareness. Calibration rooms reward this consistently.

12. Frame goals as specific practice changes

“Improve my craft” is a non-goal. “Own the workspace-permissions rebuild from problem framing through to launched product, with success measured by a 30% reduction in permissions-related support tickets within the first quarter of GA” is a goal. Each goal you set should name a concrete behaviour change, a measurable target, and a deadline you and your design manager can both check on.

Tips for both sides

13. Have a pre-review conversation

Two weeks before the formal review meeting, schedule 30 minutes to compare notes. The point isn’t to align documents; it’s to surface disconnects on the headline narrative. If you both think the defining project was the onboarding redesign, great. If the manager thinks it was the onboarding redesign and the designer thinks it was the design-system work, you want that conversation before the documents are written.

14. Acknowledge project context openly

Both sides should name the project context in the documents. The unusual scope shifts, the engineering constraints, the research signal that was strong or absent, the cross-functional handoff moments. Leaving these implicit is one of the most common ways calibration outcomes go sideways twelve months later when the context is forgotten and the shipped-or-not state is the only thing on the record.

15. Treat the review as the start of the next year

The most important conversation is the one after the document is signed. Agree on two or three specific things to do differently next year. Write them down somewhere both of you will see again in February. Return to them in the spring 1:1. A review that doesn’t change practice is paperwork; the follow-up cadence is where the actual development happens.

The shape of a designer review that ages well

Twelve months from now, read the review and ask whether you could picture the year of design work it described. The strong reviews pass. They have specific design decisions named, specific figma files referenced, specific cross-functional moments, specific craft observations, specific development priorities. The weak reviews could have been written about any designer on any team in any company, which means they’ll be treated that way at the next round of calibration.

Everything in this article is in service of that test. The rest of the cluster covers the underlying framework, the worked examples, and the designer-side counterpart:

• How to write a performance review for a product designer for the four-pillar framework and the 90-minute drafting flow.
• Performance review examples for product designers for five worked examples covering different career stages and project shapes.
• Product designer self-evaluation examples for the designer-side counterpart.