Design Criteria

Purpose

Design Criteria converts qualitative insights into concrete, evaluable requirements. By defining what a successful solution must achieve — and what it must not do — the team creates a shared yardstick for generating, comparing, and selecting concepts. It bridges the gap between empathy research and solution design.

At a glance

• Group size: 4–10
• Duration: 30 minutes
• Difficulty: Moderate
• Facilitation style: Collaborative discussion and prioritisation
• Setting: Workshop room with whiteboard or digital board

How to run

1. Review insights (5 min): Revisit key findings from user research, empathy maps, or personas.
2. Generate criteria (10 min): For each insight, ask: "What must our solution do to address this?" Write each criterion as a testable statement: "The solution must [verb] so that [user outcome]."
3. Distinguish must-haves from nice-to-haves (5 min): Sort criteria into non-negotiable requirements and desirable features.
4. Prioritise (5 min): Rank the must-haves by impact. Use dot voting if the team disagrees.
5. Finalise the criteria list (5 min): Write the top 5–8 criteria on a visible surface. These will guide ideation and concept evaluation.

Materials needed

• Research insights (printed or on a board)
• Sticky notes and markers
• Prioritisation matrix or dot stickers
• Whiteboard for the final criteria list

Pitfalls & common mistakes

• Criteria as solutions: "Use AI" is a solution, not a criterion. "Must deliver personalised recommendations" is a criterion.
• Too many criteria: More than 8–10 criteria dilutes focus. Prioritise ruthlessly.
• No user grounding: Criteria invented without research data are just opinions.
• Forgetting negative criteria: "Must NOT require a login" is as important as positive criteria.

Inclusion & accessibility

• Include accessibility as a design criterion, not an afterthought.
• Ensure all team members can contribute criteria, not just the loudest voices.
• Use inclusive language in criteria statements.

Variations

• Weighted criteria matrix: Assign weights to each criterion and score concepts against them numerically.
• User-validated criteria: Present criteria to users and ask them to rank importance.
• Evolving criteria: Treat the list as living and update it after each prototype test.

When NOT to use this

• When the team has not done research and criteria would be based on assumptions.
• When the project is purely exploratory and constraints would prematurely narrow the solution space.
• When criteria already exist in a formal requirements document — avoid duplication.

Source & further reading

• d.school, Stanford University — "Define" phase methods
• Cross, Nigel — *Design Thinking* (Bloomsbury, 2011)
• Pugh, Stuart — *Total Design* (Addison-Wesley, 1991)