What nicer thing can you do for someone than make them breakfast?

- Anthony Bourdain


There’s no one-size-fits-all design process, but there is freedom within a framework.


Over 20 years spent working within agencies, in-house, and startups, we’ve learned (the hard way) that lengthy, multiphase engagements waste time, money, and creative energy.

Instead, we package our services in fixed time and cost blocks of Design Sprints.

A sprint is like a hackathon, with a relatively short amount of time spent making sure everyone understands the problem followed by sleeves-rolled-up making, with the ultimate goal of testing a prototype that feels real (or real enough) with actual users. It compresses potentially months of work into a few days.

We’ve been facilitating design sprints for the past five years, since we first learned about the original Google Ventures method here (and then later, in Jake Knapp’s detailed guide) and have found that they work well for almost any design challenge, from developing or improving products and services to making transformation initiatives more tangible.

But because we’re pretty anti-dogmatic, we see design sprints more as a framework than a process. The format applies just enough rigor and discipline to collaborate efficiently, but also gives us freedom to customize the tools and team to suit the task at hand.


What does a Sprint look like?

Whatever the starting point, sprints follow four basic steps:



Frame the challenge
Get perspective
Generate questions + assumptions
Produce a lot of ideas



Curate + vote on best ideas
Establish a journey map
Define focal points
Divide tasks



Build the prototype
Set up user tests



Test the prototype with real users
Translate feedback into direction and action steps


Fancy a breakfast date?
Yeah you do.