Guide · Self-reviews

Self-review examples for product designers.

Designers often write a self-review like a portfolio: screens, before and after, nicely framed. Reviewers want the reasoning behind the screens. What problem did you find, what did you learn, which decision changed because of it, and what happened after it shipped?

What reviewers look for in a product designer

Problem framing. Did you find the right problem before solving one?
Evidence from people. Research, usability tests and support themes, and what you changed because of them.
Outcomes after launch. Task success, fewer support requests, adoption. Not only the launch itself.
Systems thinking. Components, tokens and patterns that make the next design faster.
Partnership. How engineering and product experienced working with you.

Example: impact

The projects, people and numbers in these examples are made up. Keep the shape and use your own facts.

Impact • Redesigned the Recipe App 2.0 create-recipe flow after eight usability sessions. In the follow-up test, 7 of 8 people finished without help, up from 3 of 8. • Designed the offline states for sync (saved, waiting, conflict) with Ravi. After launch, support requests about "lost recipes" fell to a handful a month. • Added 18 components and dark mode tokens to the design system. The web and iOS teams built the 2.0 settings screens from them with no new one-off styles.

Small research numbers are fine when you report them honestly. "7 of 8" is more convincing than "most users".

Example: collaboration

Collaboration • Shared clickable prototypes with engineering before tickets were written. Edge cases came up in design review instead of in QA. • Worked with Neha (product) to cut recipe import down to a first version. It shipped a month earlier, and its usage shaped version two. • Opened fortnightly design critiques to engineers. Engineering attendance grew from one or two people to most of the team.

Example: growth

Growth • Learned to run unmoderated tests, so a question no longer waits for the next research round. • Wrote my first research plan for a whole quarter instead of a single feature. • Next half: shorter design rationale docs that engineers actually read.

Phrases that land

"7 of 8 finished without help, up from 3 of 8": small numbers, honestly reported.
"we changed X because research showed Y": a decision that moved because of your work.
"built with no new one-off styles": the system, working.
"edge cases came up in review instead of in QA": partnership written as an outcome.

Phrases that don't

"Pixel-perfect." Reviewers already expect craft. Say what it changed for users.
"A delightful experience." Show what people did differently.
"User-centric design." Name the users and what you learned from them.
"Made it look better." Say what it made easier.

Gather your evidence

Most of a designer's history isn't in git, so collect it before it scatters:

Design files. Version history and page names show when each decision happened. Export the key frames from before and after.
Research. Session notes, test results and the summary you shared. Keep the counts ("7 of 8") with their dates.
Launches. Release notes, announcements, and the first weeks of support themes after each launch.
Decisions. The thread or doc where a direction changed because of your work.

If you commit to a tokens or component repo, the engineers' command works for you too:

git log --since="6 months ago" --author="$(git config user.email)" --no-merges \ --date=short --format='%ad %s'

Let Sill keep the record

Sill is built for developers, and its git features need a repo on a Mac. Most of it doesn't. The tasks you finish, the releases you ship and the follow-ups you send are recorded on iPhone, iPad and Mac, with receipts on everything you wait for, like engineering estimates at day 6, asked 3×.

At review time, Sill Pro's Review generator turns months of that into a draft per project. Where Apple Intelligence is available it writes a first-person draft on the device, and nothing leaves it. The last 7 days are free; longer periods need Sill Pro, an optional paid upgrade.

Get Sill on the App Store — for Mac, iPhone, iPad and Apple Watch. The daily standup and its set-time reminder are free.

More self-review examples: backend engineers · frontend engineers · iOS engineers · Android engineers · QA engineers · SRE and DevOps engineers · data engineers · engineering managers · product managers. Or start with how to write a self-review.