🧰 Design Methods Toolbox

# Phases and sprints

If you spend even a little time in user experience or product design land, you'll hear a lot of (often conflicting) talk about how to break the design process up into nifty, easy-to-chew phases. And if you've spent any time at all in or adjacent to software development, you'll almost certainly have either been asked to lead or participate in some sort of (usually week-long, full-day) design sprint.

Enthusiasts may fight to the death about which design phase framework is the right one to commit to, or insist upon a mandatory design sprint at a fixed point in every project's progress. Skeptics may suggest that design phases lock us into waterfall-style processes, and design sprints are too rushed to prototype that they encourage hollow solutions and shaky architectural practices.

Your (and your project/team's) truth will probably lie somewhere in between. We've suggested a framework for design phases and a global format for design sprints, but if these don't quite work for you, you can find alternatives here.

# Design phases: here, there and everywhere

We've organized the tools in this toolbox within a framework of three main phases, each with several areas of focus. (You'll see that each tool indicates up front where it fits in within this framework.) Just to recap, "our" phases are as follows:

Three design phases

🔎 Problem seeking

  • Landscape: Research the current state of solutions (or lack thereof) from the user's perspective
  • Empathize: Discover users' primary use cases, typical journeys, pain points, and ideal end states
  • Synthesize: Group users according to the most appropriate axes for the problem and use those groups for guidance going forward

🎨 Problem shaping

  • Diverge: Brainstorm, think outside the box, come up with ideas, pain points, opportunities and potential directions
  • Converge: Find patterns, synthesize, find insights toward solutions or opportunities for change
  • Align: Decide on one (or several) directions for prototyping and testing and define success for each of them

🛠️ Problem solving

  • Prototype: Create a "minimum believable product" that enables you to test in ways that measure a solution's success
  • Test: Evaluate your prototype with real humans (or anything else you’ve created earlier in the process) and measure its performance against your definition of success

# Other approaches to design phases

However, this approach isn't the only way to think about a phased approach to design methodology. Your particular project or problem may benefit from reframing it under a different approach. Want to try something else? Here are some other frameworks for design phases, organized rather arbitrarily by number of phases 🤷:

# Two phases

# Three phases

  • Design for America (opens new window) uses three primary phases broken into sub-areas: understand (identify, immerse, reframe), create (ideate, build, test) and implement (pitch, plot, measure impact)
  • IBM's Loop framework (opens new window) is handily visualized as an infinity symbol to illustrate that its three phases are iterative: observe, reflect, make
  • Mozilla's Open Innovation Toolkit (opens new window) collects its three phases in a repeatable loop: gather insights, ideate, prototype/test
  • Austin Center for Design (opens new window) consolidates seven areas of activity into three main phases: ethnography (identify the problem, discovery, ideation), synthesis (iteration, refinement), and prototyping (validation, implementation)
  • SAP (opens new window) recently switched from a five-phase model to a three-phase one with sub-foci: discover (scope, research, synthesize), design (ideate, prototype, validate), and deliver (implement, test, deploy)

# Four phases

# Five phases

# How does this fit in with the "design sprint" concept?

Originally popularized by Google Ventures and Jake Knapp's book Sprint (opens new window), design sprints essentially consolidate all of your design phases into a compressed timebox — usually five days — with an aim to rapidly advance problem solving, design and testing. Design sprints can be incredibly useful, but have several caveats:

  • They work best once a primary challenge has been identified; because of the rapid pace, problem definition doesn't really have space within a design sprint
  • Because of the heavy compression of effort, it's important that the sprint team be able to devote themselves entirely to this work for the duration of the sprint
  • Because of the rapid-fire iteration, design sprints can be extremely difficult with remote teams (call your travel agent and find a conference hotel!), but in the right situation worth the effort of temporarily colocating a distributed team
  • Because of the breakneck pace, solutions (and their prototypes) generated by design sprints will usually be effective, but not production-ready; keep in mind that the outcome solution will likely come with some measure of design, testing and technical debt

This isn't to say that design sprints are a poor fit for an distributed and/or async organization — just that it's advisable to make sure that a design sprint is the best fit for a particular challenge before booking a whole team's airfare.

If you're ready to embark on a design sprint, here are three frameworks to investigate, depending on the complexity of your task and how long you're willing to colocate your team:

← Content audit →