How to use Claude to write a designer performance review that shows impact (FREE Skill.md included)

Every designer I've ever spoken to about performance reviews says the same thing. They sit down to write their self-reflection and they just blank. Not because they didn't do good work, they did, but because they can't remember the specifics. The decisions they influenced, the friction they removed, the thing that shipped because of them. And so they write something vague and generic and it doesn't land well with their manager. So they walk away from their review frustrated that their work didn't land the way it should have. In this video, I'm going to show you how to fix that, including a free tool I built

that does most of the work for you. — Stay tuned. Why designers struggle with self-reflections? The problem probably isn't that you don't have enough to say. It's that performance reviews are a retroactive exercise and human memory is terrible at those kinds of exercises. You're asked to reconstruct months of work from memory in a format that you weren't thinking about while the actual work was happening. And on top of that, designers often don't get credit for the invisible work. And I want to spend a minute on this because I think it's the biggest reason strong designers end up with underwhelming reviews. Invisible work is everything that doesn't leave a visible artifact. Here's what I mean. You're in a product review. The team is about to ship a flow that you know is going to confuse users. So you push back. You show the data, you get the decision reversed. It's a meaningful contribution, but it doesn't really show up tangibly anywhere. There's no Figma file for prevented a bad decision. Or you're the person who writes the design brief that gets everyone aligned before a project starts. The engineers know what they're building, the PM knows what success looks like. The project ships on time. Is that because of your brief? Probably partly, but no one's tracking that. Or a junior designer on your team was stuck on a problem for 2 days. You sit with them for 45 minutes, ask the right questions, and they figure it out and ship something that they're proud of. You move on and forget about it by next week. All of that is real work. All of it demonstrates exactly the kind of thing that gets people promoted.

Strategic thinking, collaboration, leadership. And almost none of it gets documented because it happened in conversations and meetings and Slack threads and disappeared. That stuff doesn't show up in your Figma files. It commits. If you don't document it at the time, it's gone. So, the solution isn't to get better at writing self-reflections under pressure. It's to stop treating your review as a one-time writing project and start treating it as a log that you build throughout the year. The mistakes most people make. Before I show you what good looks like, let me show you the mistakes I see most often because they're so common most people don't realize they're even making them. The first one is writing responsibilities instead of contributions. I designed the onboarding flow. That's kind of a job description, not really an achievement. Every designer at your level designed something. So, what did you specifically do and what happened because of it? Mistake two, listing outputs instead of outcomes. I delivered 12 screens for the new dashboard. Mm, okay, but did anybody use it? Did it solve the problem? Did it change anything? Outputs are easy to measure and easy to forget. Outputs are what your manager actually cares about. Mistake three, being vague to seem humble. I helped the team with the Q3 launch. Well, helped how? This isn't modesty, it's erasure. You're not doing anyone a favor by making your contributions invisible. Your manager needs specifics to advocate for you.

Vague is not humble, just unhelpful. Mistake four, only writing about the wins. A self-reflection that's all sunshine reads as unaware. Some of your strongest writing will come from describing a project that didn't go how you expected, what you learned, what you did differently. That's the stuff that signals growth and maturity and reviewers notice. The common thread throughout all of these, they're symptoms of writing your self-reflection in one sitting, from memory, at the last minute, which brings us to the framework. When you do log your work, there's a simple framework that makes entries easy to write and compelling to read, and it's called SBI. Situation, behavior, impact. So situation, what was the context? What problem or moment were you responding to? Behavior, what specifically did you do? Not I contributed, but what was your actual action? And impact, what changed because of it? Ideally with a number, but even a qualitative outcome will work. Here is a weak example of something a designer might write in their self-reflection. Worked on the checkout redesign and contributed to improvements. And here is the same work

but written with the SBI framework. Checkout had a 34% drop off at the payment step. That's the situation. I ran a 3-day research sprint, identified that users were confused by the card input layout, and redesigned the form with inline validation. That's the behavior. And then after launch, drop off at that step fell down to 90%. That's the impact. Same project, completely different picture. That's what specific evidence writing does. All right, let's check out the free Claude skill I built just for you. Now, I built something that makes all of this easier. It's a free Claude skill called the self-reflection performance coach, and it's what I personally use to track my own impact throughout the year. The way it works, instead of sitting down at review time and trying to reconstruct everything, you drop in artifacts from your work as they happen. Meeting notes, a Slack thread, a project brief, even just a quick description of something that went well. And Claude will turn it into a polished SBI entry that gets added to your running document. When you first set it up, Claude is going to ask a few questions. Your role, any competencies that your company evaluates you on, your review period. It only takes about 2 minutes. And then whenever you have something to log, you just drop it in. And here's what comes out on the other side. Situation, behavior, impact. Matched to your competencies, dated, saved into your document. Your review doc is building itself in the background while you're focused on doing the actual work. Now there's also a section for peer feedback. Someone sends you a shout-out or a 360 comment, you paste it in and it gets attributed and saved. At the end of your review period, Claude walks you through a short reflection, reads your entries, identifies the themes, and helps you write a summary. The link to download the skill is in the description, and it is completely free. So, look, the biggest mistake I see designers make with these reviews is waiting until the last minute, and then they're trying to make up for months, or sometimes even a year, of undocumented work. And you can't do that well, and you shouldn't have to do that so last minute. So, download the skill, log one entry every week or two while the details are fresh. Small things count, and by the time your review comes around, you'll have a document full of specific and evidence-based contributions that actually reflect what you did, and you won't have to scramble. It's free, and if you find it useful, let me know in the comments. I'm still kind of iterating on it. It's my first time building a Claude skill, and I'd

genuinely love to hear how it lands. And if you want to go beyond just documenting your work, say if you want to get better at doing the kind of work that earns recognition in the first place, check out Level Up Club. It's in the description, too. All right, see you in the next video.