#02 - A short guide for PMs reviewing prototypes built by Designers
An opinionated note from a Designer to PMs
A few months ago at Atlassian, I built a generative summary prototype for a dashboard. You know those glowing boxes on top of the page that tell you what the contents are about and are supposed to help you get a gist quickly? Yeah… that.
I built it with Cursor with Rovo Dev, got it to a place where it felt extremely real, like the end user experience. Took that to a review call with my PM, a couple of engineers, and a couple of design teammates.
The review was almost embarrassingly short…
The PM clicked around. He picked on a few things.
He saw the experience instead of imagining it out of static mockups. Gave me a few notes, and approval came almost instantly.
The review went well not just because I built a great prototype, but because of how the PM engaged with it. And the more reviews I sit through these days, the more I’m convinced that the way Product Managers and Designers engage in review meetings these days has a lot of room to grow.
This is an opinionated post. It is a designer telling you, the PM, what I expect from you. Just a few things worth speaking about, that will make your relationship with your design teammates better.
About the new kind of artifacts designers are building nowadays
For most of the last decade, what designers brought into a review was a static mockup. A Figma frame, maybe a prototype in Figma itself with limited things that could be interacted with.
I understand, until now, you had to imagine the experience, think about what the user would feel. Half the review was the team trying to picture the experience in their heads.
That’s changed quite a bit.
When I bring a coded prototype to a review now, it’s usually a working thing. Real interactions and real states. The artifact in the room is no longer asking you to imagine the experience. You just have to react to the real thing now.
A working prototype is positioned to put you in user mode. You feel the weight of a flow before you can articulate why it feels off. You might ask questions about the thing in front of you, not the thing you imagined the user would see.
What I expect from PMs in a prototype review
Now that we’ve established building prototypes as the new norm, these are a few things I appreciate in my working relationship with a PM. Not an exhaustive list, just scenarios I’ve thought about often.
Click around like a user, not an auditor
The first and best thing you can do is to use the prototype. Don’t just look at it, click around and explore what we’ve built. The most valuable thing you can give the room in the first two minutes is your honest, unrehearsed reaction as someone using it for the first time. That reaction is data for the designer.
Lead with initial reactions, not suggestions
When you do start talking, start with the experience. What felt fast or slow, what surprised you, what you didn’t understand. The “I think we should change X” feedback is welcome, but it lands much better after we’ve discussed initial impressions.
First impressions + suggestions is a partnership. I can do a lot with that.
Hold right idea vs. right execution questions separately
This is the one I care about the most. “Is this the right idea?” and “Is this the right way to execute the idea?” are very different conversations.
If the idea is wrong, no amount of polish will save it.
If the idea is right, but the execution could be better, that’s a different set of next steps for a designer.
I'd love for you to tell me which one you're reacting to, separately.
Treating the review as a discussion rather than an approval meeting
Every interaction, every piece of copy is a small bet about what the user wants. I’d love to discuss with you what the right bets are.
“Why does this default to a summary view instead of detail view?” is a much more useful question than “can we change the heading?” Both are valid, but one moves product forward and the other moves pixels. I’ll take care of the pixels myself.
Talk about the prototype, not the spec
Specs are great at describing what we’re building, but they’re terrible at predicting what the working version of the thing would look like.
The moment you see a real prototype, your brain starts filling in gaps not included in the spec. Could be some states we didn’t handle or edge cases we didn’t note. Tell me about those. That’s what I’m in the review for.
A few things designers don’t usually like talking about in review calls
A small but important note before I wrap up.
When you sit down to give me feedback on a prototype, the most useful thing you can do is to talk to me like a product partner, not service folk rendering pixels. The difference is small in language and huge in outcome.
“Make the button blue” is a directive. It doesn’t tell me why I should make the button blue, and frankly, if I’m a good designer, I’ve thought about the button more than you have. I won’t make it blue just like that
“Can we make this more modern?” is a vibe I have to guess at. What if our design system doesn’t allow customizations there? If you tell me something actionable from the user’s point of view, I can do something about it
“Ask the engineering team for approval” is something we don’t want to do. Sure, I’ll go speak to engineering partners and figure out if there are technical challenges. But we got the approval to build this together as a team already
Tell us what’s not working from a user’s POV or tell us a business/technical constraint. We will figure out a way around that. That’s what we’re trained for.
Ask us about flow, sequence, edge cases, naming, assumptions, data issues. I’d love to figure things out together than being told.
Since most companies now do prototype reviews (and they should if they don’t), I think those reviews can be the best part of a product team’s week. The moment everyone sits with the actual thing, reacts honestly, and walks out with sharper conviction about what to build, we all win.
Try one of these in your next review and tell me what changed.
If you’re a designer, forward it to your team’s PMs, maybe something gets better.