Design for PMs
You do not need to draw screens to ship a well-designed product, but you do need to judge them. This lesson gives you a repeatable way to review designs against usability heuristics, information hierarchy and accessibility, to give feedback a designer can act on, and to hand designs over to engineering with every state covered.
By the end you can
- Review a design in the right order: flow, then screen, then detail
- Name usability problems with Nielsen's ten heuristics and rate their severity
- Check contrast, target size and frontline conditions such as glare and one-handed use
- Write feedback as a problem tied to a goal, with a severity
- Hand off designs with every state, using a design system
The everyday picture
Walk into a well-run supermarket and you find the milk without asking anyone. Signs hang above each aisle. The layout is the same in every branch, so regular shoppers never relearn it. The price tag sits right under the product it belongs to, and the till shows what it charged before you pay. None of this is decoration. It is design that lets people do a job without thinking about the shop.
When something in a store goes wrong, a good manager does not say "I don't like the bread aisle." She says "customers walk past the bread because the sign faces the entrance and they come in from the car park." That sentence names who, what happens and why, and it leaves the fix open. Reviewing a screen takes the same skill.
Your job in a design review
The designer owns the form of the solution: the flow, the layout, the words on the screen. You own the problem, the constraints and what success looks like. Engineering owns what is feasible. In a design review you bring what the designer may not have: the goal and guardrails from the PRD (Writing specs people read), the users' real context, the scope and the real data.
Review in this order, because each level can make the next one irrelevant:
- Flow: does the path follow the order the work really happens in? Are there steps the user does not need? Where does the user start and finish?
- Screen: on each screen, what is the one thing the user must see and the one thing they must do? Is that what stands out?
- Detail: words, error messages, states, edge cases, and how it looks with real data.
Commenting on button colours while the flow asks users to do things in the wrong order wastes everyone's hour. Always walk the flow with a real scenario and real data: "Ravi's delivery has 38 lines and 3 cartons of oil are missing. The driver is waiting. Show me." Placeholder data such as "Product name, $0.00" hides the problems that break real screens: long product names, translations, a 38-line list, a $1,240.50 total.
Quick check
Leila presents six screens for delivery claims. What should you review first?
If the flow fights the real work, every screen in it changes, so colour and icon comments would be wasted. Flow first, then each screen's hierarchy, then details such as colour and icons.