Design sprints

Work through an unclear product decision before your team commits to building it.

Start a project
Sprint scheduleWeek 1 of 2
Ships Friday
Mon
Tue
Wed
Thu
Fri
To do2

Map user flows

Queued

Define success metrics

Queued
In progress2

Natural-language finder

Active

Empty + error states

Active
Done2

Research synthesis

Done

Stakeholder kickoff

Done
What you get
  • Framed problem statement + success metrics
  • Concept sketches and option exploration
  • Just-enough screens to test the direction
  • Feedback from available users or stakeholders
  • A clearer direction ready for further testing
  • Decision log so the "why" survives
How it runs
  1. 1

    Understand

    Map the problem, constraints and what success means.

  2. 2

    Diverge

    Generate competing directions instead of one safe bet.

  3. 3

    Decide + test

    Commit to a direction and mock it up just enough to test.

  4. 4

    Validate

    Test with available users or stakeholders when possible.

Example

Desearch: the open question was how to make AI answers trustworthy. Instead of adding disclaimers, the chosen direction put the sources beside every answer so people could check them.

Common questions

A short, focused effort that turns uncertain requirements, competing priorities, and early ideas into a clear product direction you can test.

One to two weeks. If the direction is still unclear at the start of a larger project, we can use the first week or two this way before moving into interface design.

A framed problem statement with success metrics, concept sketches and option exploration, just-enough screens to test the direction, feedback from available users or stakeholders, and a decision log so the reasoning survives.