design-critique

# Product Design Critique A structured critique pass for a screen, flow, or component. The output is a prioritized list of changes a designer or engineer can act on — not adjectives. Critique is not redesign; recommend, do not rebuild. ## When to use - A designer or engineer asks for feedback on a screen, mock, or live UI. - A feature is shipping and someone wants a final UX read. - A flow is suspected of causing user drop-off and you want a pre-research read before instrumentation. ## When not to use - The user wants a redesign. That is a design project, not a critique. - The work is so early that no concrete artifact exists. Sketch with them instead of critiquing air. - You have no context on the user job. Ask for it first; design critique without user context devolves into taste. ## Pre-critique context Before opening a screen, get: - **Who is the user.** Specific role and competence, not "users". - **What job they are doing on this screen.** One sentence. - **What success looks like.** What the user can do after this screen that they could not before. - **Where this screen sits in the larger flow.** What precedes and follows. If any of these is missing, ask. Critique without these is opinion. ## The pass (in order) 1. **Clarity of the user job.** - Within 3 seconds of opening, is it obvious what this screen is for? - Does the primary action match the user's actual job, or a designer's preferred path? 2. **Visual hierarchy.** - The most important thing...