Value-Ease-Delight Feedback Ladder
Synthesize broad feedback in order: value first, ease second, delight last.
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 7
- Confidence
- 98%
Zhuo recommends collecting feedback from multiple audiences rather than relying on one decisive review. Designers, close product partners, outsiders, and target customers each contribute a different perspective, even when their opinions conflict. The team's job is synthesis, not consensus. Anchor the synthesis in a clearly defined customer and job, then sort feedback through a three-level ladder. First ask whether the product is valuable and solves the important problem. Next ask whether people can access that value easily. Only then optimize joy, aesthetics, animation, and exceeded expectations. Before each review, state the product's stage and the question that matters now so premature polish feedback does not displace a more fundamental decision.
Origin
Drawing on years of product and design reviews at Facebook, Zhuo explains that broad feedback is useful but cannot be applied equally. She uses a sequence of value, ease of use, and joy to organize conflicting input and keep teams focused on the most important unresolved layer.
Core principles
- 01More perspectives improve the input, but consensus should not choose the product.
- 02Feedback only becomes actionable after synthesis.
- 03The target customer and their job anchor every judgment.
- 04Value outranks ease, and ease outranks delight.
- 05The product stage determines which feedback matters now.
How to run it
- 1
Anchor on the customer and job
Describe the target person, their most important problem, and the job the product should perform. Use this shared picture as the standard for judging feedback.
Pro tip Make the customer specific enough that reviewers can distinguish their own preferences from the target user's needs.
Watch out Without a shared target, contradictory opinions cannot be prioritized coherently.
- 2
Collect different perspectives
Run separate sessions with design peers, the direct product team, people outside the team, and target customers. Accept that the groups may disagree.
Pro tip Use outsiders to expose assumptions that have become invisible to the core team.
Watch out Do not interpret more feedback as a requirement to design by consensus.
- 3
Set the review stage
Tell reviewers where the product is in development and what the team needs to validate now. Match the artifact's fidelity and the review question to that stage.
Pro tip Say explicitly whether the review is about the problem, the flow, or the finishing details.
Watch out A realistic prototype can attract detailed UI comments even when the team only wants to test the core concept.
- 4
Validate value
Ask whether the product solves the target customer's important problem and performs the intended job. Ignore lower-level polish if the core value is missing.
Pro tip Treat value as the gate that every later layer depends on.
Watch out A pleasant interface cannot rescue a product that does not solve a meaningful problem.
- 5
Validate ease
Once value is credible, identify confusion, wrong turns, slowness, and other barriers that keep people from reaching it. Prioritize access to the value before decorative refinement.
Pro tip Frame usability as the path to value, not a separate collection of preferences.
- 6
Add delight
After the product is valuable and usable, improve pleasure, surprise, aesthetics, animation, and exceeded expectations. Use this layer to raise a functioning product above the expected bar.
Pro tip Return to saved delight feedback once the first two gates are secure.
Watch out Do not let an attractive detail distract from a broken or slow core experience.
- 7
Synthesize and prioritize
Bucket all feedback by layer and decide what the current stage requires. Preserve useful later-stage input while acting on the highest unresolved layer first.
Pro tip Explain which bucket each decision belongs to so reviewers understand why some comments wait.
In the wild
Zhuo gives the example of a product that looks delightful but takes ten seconds to load. The animation may be excellent, yet users still cannot access the product's value in a usable way.
→ The ladder directs the team to fix access and speed before spending more attention on delight.
A team builds a prototype to communicate how an idea might work, but reviewers immediately debate the shade of blue or the ordering of small steps. The team has not yet established whether it is solving an important problem.
→ Stating the stage and desired feedback refocuses the review on value before detailed UI choices.
Common mistakes
Using one meeting as the only review
Different audiences hold different useful knowledge. One mixed session is not a substitute for recurring feedback from several perspectives.
Designing by consensus
Valid opinions can still conflict. The team must synthesize them against the target customer and job rather than seek unanimous preference.
Polishing before proving value
Colors, animation, and delight are lower-priority decisions when the product may not solve the problem or let users reach the value.
Is it for you?
Best for
Teams running recurring product, design, prototype, or user-research reviews during development.
Not ideal for
A finished product facing a narrow cosmetic defect where value and usability are already established.
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