Skip to content

Human-centered design process

Purpose: Frame problems from user needs before jumping to UI solutions.

Harvest / review: 2026-05

Agent hint: Load for discovery/IA phases · Pair with ../website-design/information-architecture.md

Principles

Principle Practice
Desirable + viable + feasible Balance people, business, and technology (IDEO)
Iterate, don't waterfall Short cycles: learn → adjust
Prototype to learn Low-fidelity before high-fidelity code
Define the right problem A sharp problem statement beats feature lists

Modes (Stanford d.school)

Mode Goal
Empathize Observe and interview; find gaps between what people do and say
Define Synthesize into a point-of-view / problem statement
Ideate Generate many options; defer judgment
Prototype Make something testable quickly
Test Get feedback; refine or pivot

Patterns

  • Start interviews with open questions (“walk me through last time you…”) not feature pitches.
  • Capture constraints early (budget, timeline, accessibility, compliance).
  • Use How might we… to open ideation after Define.
  • Test with 5–8 users for qualitative signal (NN/g rule of thumb for iterative tests).

Anti-patterns

Avoid Why
Solution-first mockups Builds the wrong thing beautifully
Single stakeholder = “the user” Misses edge cases and equity gaps
Skipping Test on “simple” sites Assumptions survive to production

Pre-ship checklist (lightweight)

  • [ ] Problem statement written in user language
  • [ ] At least one round of feedback on prototype or staging
  • [ ] Accessibility considered in Define, not bolted on at Test

Sources