How to Write a Performance Review for a Product Designer

I’ve read a lot of designer performance reviews and the recurring problem is that they were written by someone who couldn’t actually read the work. The reviews talk about “user-centred thinking” without naming the research the designer ran. They talk about “visual craft” without engaging with the specific screens. They talk about “collaboration with engineering” in the same generic way they’d talk about an engineer’s collaboration with anyone. The designer reads it, recognises that whoever wrote it didn’t engage with the actual craft, and the review quietly loses authority for everything that follows.

This is a guide to writing designer reviews that don’t do that. It’s aimed at design managers, heads of product, founders who manage designers directly, and PMs who contribute to designer reviews in a matrix. The frame is in-house product designers in tech and SaaS contexts, though most of the principles translate to agency and platform work.

Why design reviews are different

Four things make these reviews harder than most managers expect. First, the work is partially legible to non-designers. A senior engineer reviewing a junior engineer reads the code. A sales manager reviewing an AE reads the deals. A design manager reviewing a designer can read the figma files, but anyone reviewing a designer who isn’t a designer themselves has a harder time evaluating craft. The review needs to engage with the work; if the reviewer can’t do that confidently, the evaluation collapses to whatever proxy is available (deadline compliance, stakeholder feedback, vibes).

Second, impact attribution is messy. The designer worked on the onboarding redesign that lifted activation from 41% to 58%, but so did the PM who scoped it, the engineer who built it, the data team who instrumented the cohort comparison, and the copywriter who rewrote the empty-state copy. Naming the designer’s specific contribution requires actually being inside the decision-making, not just watching the metric line move.

Third, the taste question is real. A designer can run a textbook research process, design carefully, partner well with engineering, and ship work that is competent but not particularly good. Or they can ship work that surprises you with its rightness in ways the rubric didn’t predict. Pretending taste is rubric-able usually produces reviews that feel hollow to the designer being reviewed. Pretending it doesn’t matter produces reviews that miss the thing that defines strong designers.

Fourth, designers read prose carefully. They notice when a sentence is generic. They notice when a compliment is structural rather than specific. They notice when feedback is hedged. The audience for a design review is unusually literate in the medium the review is delivered in, and the writing has to meet that bar.

Start by pulling the work, not the metrics

Before drafting a word, spend an hour going through the designer’s actual work from the period. Strong designer reviews are built from engagement with the artefacts, not from headline outcome data. Pull:

• The figma files for two or three flagship projects. Open them. Look at the structure of the files (well-organised vs sprawling and chaotic), the iteration history (versions kept and labeled vs everything dumped in one canvas), and the actual design decisions. The file hygiene is itself a signal; the iteration history shows you how the designer thinks.
• Research artefacts. Interview notes, survey results, usability test summaries, the synthesis documents that came out of the work. The presence and quality of these distinguishes research-led designers from intuition-led ones, and most product organisations want more of the first.
• Specifications and engineering handoffs. The specs the designer wrote for engineering. The comments thread on those specs. The follow-up revisions after engineering started building. A designer whose specs require constant follow-up questions is operating differently from one whose specs let engineering work autonomously.
• Design system contributions. Components added, patterns documented, deprecations flagged, contributions to the team’s shared library. These are some of the most valuable but most uncredited designer work.
• Outcome data tied to specific work. Where you have it. Activation lift on the onboarding redesign, conversion on the pricing-page test, drop-off reduction on the checkout flow. Attribute carefully and acknowledge the team contributions.
• Cross-functional feedback.A 10-minute conversation with the PM and the engineer who worked closest with this designer. You’re looking for patterns: trust, working rhythm, whether the designer is making the PM’s job easier or harder, whether engineering trusts the spec or has learned to assume revisions.
• Design crits and team contribution. How the designer shows up in critique. The quality of feedback they give on other designers’ work. Whether they bring proposals back from crit stronger or whether they over-explain and defend.

An hour here makes the review writeable. The work is the evidence; the metrics are the headline.

The four-section framework

1. Craft

The quality of the design decisions themselves. Not “visual craft” as a generic adjective, but specific decisions in specific projects: the information hierarchy on the dashboard redesign, the empty-state treatment on the new feature, the density choices on the table view. Strong designer reviews engage with the work directly. If you wouldn’t feel comfortable critiquing a specific screen, the section will collapse to adjectives.

2. Process and rigour

How the designer arrived at the work. Research engagement, prototype iteration speed, design system thinking, spec quality, accessibility consideration. This is the section where research-led designers differentiate themselves from intuition-led ones, and where the documentation discipline shows up. Strong reviewers point at specific research artefacts and specific spec decisions.

3. Impact

What the work changed. Outcome data where it’s attributable. Adoption of design-system components the designer contributed. Decisions the work influenced that wouldn’t have happened otherwise. Be honest about attribution: the onboarding redesign that lifted activation involved the PM and engineering and the data team, and the designer’s contribution should be named specifically rather than implied as sole authorship.

4. Collaboration and influence

How the designer shows up with PM, engineering, research, leadership. Crit contribution. Mentorship of more junior designers. Contribution to the design organisation’s norms and rituals. This is the section where senior designers genuinely distinguish themselves; mid-level designers often have strong craft but the senior step is influence at the system level, not just on their own projects.

Common traps to avoid

The proxy-metric trap

Reviewing a designer on shipping cadence, stakeholder- meeting frequency, or jira ticket throughput. These are real signals about productivity but they’re not signals about design quality, and over-weighting them in a designer review usually rewards the designer who’s busy at the expense of the one who’s actually thinking. The fix is to lead the review with engagement with the work, then add productivity context.

The taste-as-rubric trap

Pretending that taste is reducible to a checklist. It isn’t. The best designer reviews acknowledge the taste dimension directly, name a specific moment where the designer’s judgement was particularly strong (or weak), and resist the urge to score taste against an abstract criterion. Strong designers appreciate this honesty; the alternative reads as evasive.

The "delightful, thoughtful" trap

Universal design-review language. Delightful. Thoughtful. User-centred. Pixel-perfect. Polished. Strong eye. These phrases evidence nothing and could be applied to any designer. Replace each with the specific moment that earned the description. “Thoughtful about empty states” becomes “The empty state on the new analytics module was designed to teach the product’s mental model in three sentences, and the activation lift on first-week users on that module suggests it worked.”

The collaboration-as-likeability trap

Strong cross-functional collaboration is not the same as being well-liked. A designer who pushes back on a PM’s scope or holds an engineering timeline on an accessibility concern is doing collaboration work even when it produces friction. A designer who’s universally liked but never argues for the design is often doing less collaborative work than the first one. Be careful which one you’re crediting.

The 90-minute drafting flow

Plan for 90 minutes per designer review.

Minutes 0–30. Work review. Open the figma files for two flagship projects. Look at the file structure, the iteration history, the actual design decisions on three or four screens. Pull the research artefacts. Pull the design-system contributions. You’re building specific observations to anchor the review on.

Minutes 30–60. Cross-functional evidence.Have brief conversations with the PM and engineer who worked closest with the designer. Look at outcome data where it’s attributable. Note 2 or 3 specific moments worth recording from the period.

Minutes 60–90. Draft and sharpen. Write each section in five or six sentences, leading with the strongest specific observation. Then cut every generic phrase and replace with a specific moment. If you wrote “strong craft,” replace with the specific decision that demonstrated it.

What to do when you’re stuck

Three common stuck-points.

“The work is competent but unremarkable.”Write that honestly, with specifics. Name the work that hit the brief. Name the work that didn’t exceed the brief. Name the specific area where you’d expect more from a designer at this level. Competent-but- unremarkable is its own assessment and the review should land it directly. The alternative (warm prose that pretends the work was stronger than it was) reads as condescending to the designer.

“The designer is technically strong but cross-functional friction is real.” Name the friction with specific examples. Not “could improve collaboration,” which is evidence-free. “In the checkout-redesign project, the spec revisions in week 8 created two weeks of unplanned engineering work that could have been avoided by bringing engineering into the rationale conversation in week 4. The pattern showed up again on the notifications project.” Then name what would change it.

“I can’t tell whether the work is good.”Get help. Ask a more senior designer in your org (or in your network) to spend 20 minutes looking at the work with you. Most managers reviewing designers without a design background under-estimate how much this kind of consultation helps. The alternative is writing a review that doesn’t engage with craft, which the designer will notice.

Don’t let the drafting itself be the bottleneck

Most of the work above is the thinking: engaging with the figma files, separating craft from process from impact, talking to the PM and engineer. The actual typing-up is maybe 25 to 30 minutes per designer if you’ve done the prep. For a design manager with five or six designers to review, that’s still 3 hours of writing on top of 7 or 8 hours of evidence work. If you want to compress the writing time without losing the substance, this is what Crestento is built for. The product designer system prompt is calibrated to craft language, the four sections map onto the structured input, and the AI won’t invent a project or a research moment you didn’t provide.

For the rest of the cluster on writing and receiving designer reviews:

• Performance review examples for product designers covers five worked examples across different career stages and project shapes.
• Product designer self-evaluation examples is the designer-side version: what to write in your own self-evaluation to make the craft work visible.
• Performance review tips for product designers collects tactical tips for both sides of the conversation.