Problem-First Design Feedback
Explain the observed problem before offering a solution, then let the owner solve it.
- Difficulty
- Easy
- Time to result
- ~days to results
- Steps
- 5
- Confidence
- 98%
Problem-First Design Feedback separates the observation from the proposed fix. Reviewers naturally jump from noticing friction to suggesting a color, feature, or layout change, but the suggestion conceals why the current design seems insufficient. Start by explaining the actual problem, where you became confused, what value is missing, or why the experience fails the intended user. Provide examples and confirm that the team agrees on the problem and its importance. The designer or owner, who has spent the most time with the work, then remains empowered to generate alternatives. Suggestions are welcome, but only after the underlying reasoning is visible. The group can then compare solutions against a shared problem instead of talking past one another.
Origin
Zhuo developed this rule through design critiques involving cross-functional partners. She observed that builders enjoy solving, so reviewers often skip straight to instructions such as changing a logo color or moving a button. That shortcut removes context and can disempower the person responsible for the solution.
Core principles
- 01A proposed fix hides assumptions about the underlying problem.
- 02The person closest to the work should remain empowered to solve it.
- 03Concrete observations make feedback easier to evaluate.
- 04Problem alignment should precede solution comparison.
- 05Suggestions are useful after the reasoning is visible.
How to run it
- 1
State the observation
Describe what happened in the experience without prescribing a change. Point to the moment you became confused, unconvinced, or blocked.
Pro tip Use first-person evidence such as where you got stuck rather than presenting a preference as a universal fact.
Watch out Opening with a fix makes it harder for others to see the reasoning behind it.
- 2
Explain the underlying problem
Connect the observation to the user, value proposition, or intended outcome. Make the insufficiency you see explicit.
Pro tip Give an example that lets the owner reproduce or inspect the issue.
- 3
Align on importance
Ask whether the group agrees that the issue is real and whether it is the most important problem to address now. Resolve disagreement at the problem level first.
Pro tip Separate disagreement about the diagnosis from disagreement about a proposed treatment.
Watch out Teams that skip alignment can spend the review comparing fixes for a problem some members do not accept.
- 4
Return ownership to the solver
Invite the designer or responsible owner to explore solutions using their deeper context. Add ideas as possibilities rather than instructions.
Pro tip Phrase your idea as one option after the problem is clear.
Watch out Prescribing the answer can take power away from the person who knows the problem best.
- 5
Compare solutions against the problem
Evaluate alternatives by how well they address the agreed issue. Keep the discussion tied to the user and intended outcome rather than personal taste.
Pro tip Restate the problem before choosing among close alternatives.
In the wild
A reviewer says to make the logo purple without explaining what is wrong. The suggestion may be hiding a concern about clarity, emphasis, brand value, or the current color, but the designer cannot judge the idea without that reasoning.
→ Explaining the concern first gives the designer room to produce and compare better solutions than the initial color suggestion.
A product manager wants to move a button higher and presents the placement as the answer. Reframing the feedback around the user behavior or confusion that prompted it makes the actual problem available to the full team.
→ The designer can consider placement alongside other ways to solve the same user problem.
Common mistakes
Leading with the fix
A specific instruction compresses several assumptions into one preference and makes the underlying concern difficult to examine.
Withholding concrete evidence
Saying something feels wrong without showing where or why leaves the owner unable to reproduce and interpret the concern.
Solving before agreeing
Brainstorming options before the team agrees on the problem causes people to talk past one another.
Is it for you?
Best for
Product managers, engineers, data scientists, and other partners giving feedback to designers or creative owners.
Not ideal for
Immediate incident response where a known fix must be applied quickly and the underlying problem is already agreed.
From the episode
Julie Zhuo on accelerating your career, impostor syndrome, writing, building product sense, using intuition vs. data, hiring designers, and moving into management