June 13, 2026

How to write a self-review as a designer (with examples)

The research that changed the roadmap, the error states nobody noticed, the system that saved the team months — a designer's impact hides in the work that didn't go wrong. Here's how to claim it.

Designers face a self-review problem of perception: when your work is good, it disappears. A flow people move through without friction, an error state that quietly catches a mistake, a system that lets the whole team ship consistent UI without thinking — the better the work, the less anyone notices it. Come review season, you're asked to prove impact for work whose entire purpose was to be invisible.

The instinct is to show the screens. "Redesigned the dashboard" with a before-and-after looks like proof, but it describes the artifact, not the impact. The designer version of impact-over-activity is to claim the change in behavior or decision your design produced: what users did differently, what the team built because of your research, what didn't break because you handled the edge case.

Concretely: "Redesigned the checkout" becomes "Redesigned the checkout after session replays showed users dropping at the payment step, cutting checkout abandonment from 31% to 19%." "Did user research" becomes "Ran five interviews that killed the planned social feature and redirected the quarter toward the onboarding work that actually moved activation." "Built design system components" becomes "Shipped a form-input system that removed roughly a week of recurring UI work per engineer per quarter and ended the inconsistency QA kept filing bugs against."

What designers under-report: research that changed a roadmap (not just informed a screen), the accessibility and error-state work that prevents support load nobody attributes to design, the design-system leverage that compounds across the team, and the times you pushed back on a bad product or engineering decision and were right. This is the work that demonstrates design as a force on the product, not a service that makes things pretty.

Quantify carefully and mark estimates honestly. Where you have funnel numbers, accessibility audit results, or support-ticket deltas, use them. Where you're inferring — "likely reduced confusion," "probably saved engineering time" — say so. A precise "cut abandonment 12 points" next to a clearly-labeled estimate reads as credible; an unlabeled vague claim reads as fluff and taints the rest.

Read the leveling rubric first. Design ladders reward scope of influence, craft, and whether you're improving the product or improving the design org — not volume of screens shipped. Choose the entries that prove the behaviors at the level you're arguing for, and frame each as research-or-craft that produced a decision or an outcome.

All of this depends on remembering the moment the research changed someone's mind or the edge case you caught — detail that fades within weeks. Capture it as it happens: a note after the interview that killed the feature, the day you shipped the component system. Meritbook exists for this — a private log you capture into daily and generate a review from later, every claim traceable to a real entry. But a notes app you actually use beats the perfect tool you abandon. Capture while it's fresh; translate into impact when it counts.