Exercise: map a product's design process

Your exercise

## Map a product's design process

Reverse-engineer the design process behind a product you use regularly, and identify the phase its team gave least attention.

**Choose a product** you use at least weekly, that involves completing a task (banking, delivery, booking, a government service). Avoid products you've worked on — you need to be able to be wrong about it.

### Deliverables

1. **Problem statement** — one sentence, written as you believe the team would have framed it, in the user's terms rather than the company's.
2. **Context-of-use statement** for the primary user group, using the template: *A [user] needs to [task] while [context], so the design must [implication].*
3. **Double-diamond map** — the four phases (Discover, Define, Develop, Deliver), and for each, the evidence *in the product* that indicates what the team did there.
4. **The gap** — which phase received least attention, the specific evidence that tells you so, and what you would do differently.

### The standard

**Evidence, not vibes.** Every claim needs something specific and observable behind it. "The onboarding feels rushed" is a vibe. "Onboarding asks for six fields before showing any of the product, and two are never used again" is evidence. Annotated screenshots are strongly encouraged.

**Assume competence and constraint.** Real teams work under deadlines, legacy systems, regulators and founder opinions you cannot see. The useful question is not "why is this bad" but "what would have had to be true for this to be a reasonable decision?"

### Format

Any legible format — FigJam, Figma, a document, or a photo of paper. It must be readable without you there to narrate it. Budget around 45 minutes; if it's taking three hours, you're polishing.

How it’s marked

Problem framing

The problem statement is written in the user's terms and describes a problem, not a solution or a feature. It is specific enough that a different solution could plausibly address it. A statement that names the product's existing feature set back to itself does not meet this.

Context of use

Uses the full template with all four parts present. The context clause names real conditions (device, attention, interruptions, environment, emotional state) rather than restating the user or task. The implication clause is falsifiable — a screen could be held against it and fail. 'Simple and intuitive' does not meet this.

Phase placement

Activities are placed in the correct phase, and the problem/solution distinction between the two diamonds is respected. Research placed in Develop, or prototyping placed in Discover, indicates the model hasn't landed. All four phases are addressed even where the evidence is thin.

Evidence quality

Each inference is supported by something specific and observable in the product — a named screen, field, flow, message or state — rather than by impression or assumption about the team. Screenshots or direct references are present. Generalised judgement without an anchor does not meet this.

Gap identification and response

Names one phase as weakest and argues it from the evidence already presented rather than introducing a new claim. Proposes a concrete, proportionate action that belongs to that phase — a first-diamond gap gets a first-diamond response, not a redesign. Acknowledges at least one constraint the team may have been working under.

Hand it in

Revision · 4 cards

These come back on a schedule, spaced to catch you just before you’d forget.