Origin

History & Format

A design sprint is a week-long exercise for teams to create and test realistic-looking prototypes, saving the time and engineering effort it would take developers to build the ideas for real.

Each day has a different focus and set of exercises:

It was initially used internally within Google on various products, before then spinning out to Google Ventures and applied to their portfolio of startups.

Inspired By Agile

Although designers have worked within a sprint format on engineering-centric teams for a long time, what popularized the term is the particular format created by Google Ventures and their subsequent book documenting the process.

Design sprints have a few similarities to the agile version for developers:

• Work is highly atomized and structured.
• Projects are timeboxed to less than a week.
• The focus is on action and working prototypes, not research and planning.
• High amount of interdisciplinary collaboration.

It's easy to see why the practice would be friendly to large engineering-heavy teams or smaller fast companies, given the spiritual kinship to the already ubiquitous practice of agile development.

Criticisms

My Initial Reaction

Still, as fun as design sprints sound, I remember being a bit surprised when design sprints first started to get popular. I remember thinking, doesn’t everyone know this stuff already?

I’m not saying good design is universal these days, just that the principles for tackling those challenges seem pretty well documented.

It’s not like design sprints are bringing awareness to new techniques like when the UX field was first starting up, so design sprints sounded to me like they were just an agile-flavored remix of typical best practices: group brainstorming, usability tests, quick prototypes, etc. Basic stuff taught in any school or bootcamp these days, and also very easy to pick up for self-taught types.

In fact, I should be exactly the target audience for this: a designer from a technical background that’s comfortable with agile techniques and early stage companies. Doing the full-stack of design with fast engineers at startups is my jam. So is doing user research on the fly and without making a big production out of it.

Being a designer at an early stage company is particularly challenging and takes a specific kind of attitude, whether learned or acquired. An army of one that doesn’t mind being outnumbered by engineers and business types.

I’ll check out anything that’s down with the cause of making design faster and comes from the helter skelter world of startups.

So I looked past my initial reaction and dug into it a bit more. After all, it’s an admirable goal to help designers be more nimble and execution-oriented.

But without getting into the age-old debate on the drawbacks of agile, reading up on the rigid schedule and emphasis on collaboration over expertise rubbed me the wrong way and made me see why my spidey sense had gone off. It made me think of a paraphrased version of the old saying about regular expressions:

Some designers struggle to keep up with developers and think “I know, I’ll make my design process more like engineering.”

Now you’ve got two problems.

Well more like a handful problems, when I get into specifics in the section on drawbacks.

Detractors

Ok, so if you’re not already super experienced as a designer or technical enough to be familiar with potential drawbacks of agile development, design sprints still sound great. Actually they sound kind of fun — a whole week to collaborate with your colleagues in new ways and learn various thought-provoking design exercises. So who wouldn’t like that?

Well, it turns out that I'm not alone in having reservations.

I am utterly and completely tired of anyone who claims to have a one size fits all design process to solve all problems. It’s lazy, misleading, and a sign of an inexperienced designer who can’t objectively choose the right process for the current problem.

And the critics aren’t limited to just people that I know personally, like my friend Ian. When I read articles like Erika Hall’s “Design Sprints Are Snake Oil” and Invision’s “When A Design Sprint Isn’t The Answer”, that’s when I decided to document my doubts in a more detailed way and explain my startup-centric view of the practice.

I’m sure every process has its detractors because it doesn't work in every situation, so that’s to be expected and perfectly normal. I thought at first that maybe my qualms were because of the type of teams that I’m used to — super scrappy early stage startups with absolutely no time to spare — but pinging others made me realize that it might be a wider problem and not just an individual preference or work situation.

After all, if I’m not the only one seeing downsides to this trend and sprints won’t work in every situation, then there’s a need for people to learn about alternatives. So let’s get into the details of why a week-long sprint is a non-starter in many circumstances...

Selling Instead Of Doing

Various techniques will go in and out fashion over time, that’s just a natural part of any industry. However, there’s one universal constant about them all: there’s what a methodology says it’ll do on the packaging and what its actual purpose is.

For example, it’s a recurring joke that agile development isn’t always very agile. Extremely regimented and formal versions of the process make a development team anything but quick and nimble.

Yet that’s for a good reason, since agile is really about expectation management for stakeholders and avoiding executive randomization of engineering pipelines, not making developers faster.

Similarly, design sprints probably won’t produce the absolute best design work because it’s not about making designers better. There’s a larger meta goal instead: stakeholder buy-in. You can say it’s about teamwork but whatever you call it, the exercise is meant to build respect for designers so that they have the time it takes do more informed work.

So let’s get real — design sprints are about getting buy-in from stakeholders by teaching design basics.

Buy-in for common best practices is useful. It’s a smart idea to teach overall principles of the discipline to stakeholders and engineers so that they’ll understand the time and research it actually takes to cook up decent work. Hopefully they’ll also see the true cost of rushed and reactive work that doesn’t address underlying UX issues.

However, a week is a long time to take off just for subtle power dynamics. Even if your company isn’t in constant survival mode, you should be able to establish solid design principles without completely pausing the product pipeline and asking everyone to learn arcane techniques.

I get that design is fun and everyone’s got an opinion about it, but can you imagine doing this for every role in the company? Taking a week off to learn sales techniques, then another one for customer support triaging, then yet another for leadership, then a bootcamp for picking the next engineering stack…

Come on, let’s get real. That sounds like a course about workplaces, not an actual workplace. At some point, you have to trust that everyone will just do their damn jobs.

All of this means you should temper your expectations about the actual design work that will come out at the other end of a design sprint. You probably won’t emerge from one of these things with a shiny new design that’ll save the business, for example. Because it's not the point — getting your boss enthused about your field is the real aim.

Again, these are admirable goals but the week-long format is not a fit for a lot of teams, ones with pressing and business-critical needs, with stakeholders that trust the expertise of their hires, and with designers that already know when to use the right tools and in self-sufficient ways that don’t slow everyone down.

Startups Don’t Have Time

And neither does anyone else, really.

It might be ironic to complain about design sprints taking too long when it claims to reduce months of dawdling to a single focused week, but even a entire week is too long to waste in my experience.

Time — and the lack of it — is the main reason I’ve become accustomed to using a variety of techniques on an ad hoc basis. The types of high-pressure environments I’m used to can’t take off even just a few days from their usual work of developing and shipping features. It’s impossible for most startups to press pause for that long, no matter how dire their design debt.

Startups aren’t the only ones without time. A healthy sense of urgency is a major commonality between all productive teams and endless meetings is a pretty good sign of the opposite.

Years ago, after I moved to SF but before I went to my first startup, I worked at a mid-sized company that regularly hosted large meetings with dozens of people. I used to amuse myself by estimating how much money we were wasting by doing a little back of the napkin math. It always came out to thousands of dollars per hour! You can try it yourself with an online calculator for meeting costs.

That doesn’t mean small or fast teams never need meetings or a solid product direction. Actually, startups need design guidance the most, because otherwise you accidentally cook up an explosive cocktail; a frenetic pace of feature development doesn’t combine well with an early company poking around in the dark for product/market fit. Startups inevitably run into avoidable pot holes because of their overwhelming emphasis on maintaining momentum, even while in an exploratory mode to define their main purpose.

So how do you reconcile massive design needs with an utter lack of time?

The answer is not to cram a week’s worth of design activities into less time, it’s simply to use the right tools at the right time, as you go along.

Designing humane products and apps while having effective collaboration is not a one time fix — it’s part of the work culture for solid design-driven teams.

And especially when it comes to team exercises, you should be highly selective about only the few key tasks that yield the most benefit and make sure to space it out as much as possible, otherwise you’re wasting not just your time but everyone else’s as well.

Just to jump ahead and preview one of the alternatives that I’ll describe later, you can use a quick exercise like structured sketching to coax out the collective knowledge of a team in a single afternoon, without grinding an entire work week to a halt.

Most of the techniques in a design sprint are ones that a self-sufficient designer should be able to carry out in parallel, whether solo or by pairing up with devs and PMs, so why waste everybody’s time by exposing them to esoteric techniques?

Execution Trumps Strategy

The underlying reason why startups don’t have time is actually pretty rational and applies to most other company types too: staying busy is a survival mechanism. People try to stay busy shipping meaningful work, otherwise they risk stagnation at best and existential threats at worst.

One of the dirty secrets of business is that work is 90 percent execution. Success is less about inspiration or random strategizing than it is just plain getting shit done, day after day. Even at startups. Especially at startups, actually.

It doesn’t matter whether we’re talking about companies that are large or small, remote or co-located, ones with green logos or blue… The hard truth is that all truly effective teams are stocked full of high performing “armies of one” that use their energy to come up with and implement solutions, not to generate stunningly original ideas for work.

Everyone has ideas but real artists ship.

It makes sense, right? You can’t afford to have a company filled only with “visionary” types, daydreamers making academic arguments all day. You need people that can soldier on and learn by doing.

Yes, you need both modes of work — productivity and reflection — but that doesn’t mean equal amounts of time or a rigid schedule for each. Every person and team have to find their own rhythm and balance. Avoiding too much action without thought or thought without action is about team chemistry, personal challenges, and the interplay between them.

Plus anyway, it’s not like taking a break from the rigors of the usual execution-oriented work to host a strategy session is guaranteed to stimulate calm and reflective thought, peppered with smart conversation and interesting doodles that culminate in brilliant insights. Ha! If only.

In the real world, strategy sessions are usually the opposite of productivity. Sharpie showdowns at the whiteboard, going in circles with endless debates, all while losing momentum on shipping meaningful work. Meeting hell. Wasted time. Vacillating ad nauseam.

Good designers abhor vacillation and make teams faster, not drag them down.

Just even imagining taking an entire week off of shipping features gives me the heebie-jeebies. And don’t get me started on spending a day voting on features with post-its like grade schoolers assigning gold stars!

With all of my harping on speed, independence and most of all, high quality end results, I guess you could say that these are my version of Dieter Rams’ principles of good design, especially at startups.

A good designer knows how to:

• Trawl through support requests to understand customer needs.
• Interview stakeholders to distill business goals.
• Do competitive analysis.
• Make their own prototypes to test solutions.
• Prioritize feature work.
• And countless other things, without having to stop for guidance at every step.

Basically, try to work fast and independently.

And when it comes to group collaboration techniques, keep your powder dry and only gather the entire team when absolutely necessary and for the minimum time possible, to respect their colleagues’ time and energy.

Design Exercises Look Funny

While we’re at it, let’s also be real about how design exercises come across to most people.

Design exercises may have good intent but they look like pointless artsy vacillation to everyone else.

Stickies, whiteboard doodles, giant markers, weirdly scripted interactions that treat valuable customers like lab mice… they’re all insanely valuable tools that I love using. Hell, I’ve been running usability tests for two decades. The first book I bought with my first paycheck at my first gig out of college was Designing Web Usability, the Jakob Nielsen classic.

But I live in the real world and recognize that these techniques are completely unfamiliar and strangely childish for most non-designers, so they have to be used as needed on a project and definitely not all at once as a substitute for critical thought.

That’s why I usually assume everyone else is just too damn busy spinning their own plates to stop and want designers to just get on with doing their job, not to push the esoteric details of their internal methods on to everyone else.

It’s an absolute non-starter to ask most teams to pause their work for a week to play with kindergarten-style toys, just so you can figure out what the hell to work on and how to test its efficacy. It will get you laughed out of the room — as well it should!

You might as well turn down the lights, put on some crappy world music and scroll through random nature scenes while asking whether the end result should feel like a leopard or a butterfly.

You Can’t Crowdsource Expertise

Playing with crayons and crowdsourcing product decisions by voting with post-its isn’t the best way to show design expertise anyway.

That’s not how to demonstrate authority. You’ll get respect if you respect other people’s challenges — their business needs, engineering constraints, customer support backlog, and a thousand other things — all without bringing the whole team to a stop.

Gaining respect comes from understanding everyone else’s needs, on the fly and under massive time pressures.

And most of all, respect comes from doing great work. You might not always get credit for nailing a design but guess who gets the blame if you throw every single idea into a blender and call it a group decision? Not the team or process. They’ll blame you, the designer. And rightly so — you’re supposed to be the arbiter of team input that distills down disparate needs into distinctly understandable visuals, not a hoarder that throws every idea into a junk drawer.

Good designs are hard decisions made visual — don’t shirk the responsibility under the guise of collaboration. Otherwise you’re no better than a PM or technical lead desperately cobbling together wireframes out of random design kits.

“Bad design gets out in the world not because the people working on it lack skills, but often because the decision-making process is broken. Fixing that is a team effort that has to go bottom up, top down, and all the way across.”

I don’t know why but so many designers suck at leading people. Getting your team to brainstorm up a few product ideas won't fix that core issue.

I can think of a few possible reasons that many designers struggle to lead teams:

• Communication skills and independent thought are essential soft skills that are often overlooked in a typical curriculum.
• Leadership can be more challenging to develop for some of the more introverted personality types that are attracted to aesthetic and creative expression.
• Designers are defined in some quarters as more of a facilitator than a producer. They’re like artsy visual versions of project coordinators that emphasizes consensus and research, rather than strong product managers that sets vision and drive action.

That last point in particular bugs me because it seems so ingrained culturally, like a warped version of "the client is always right" that metastasized into "all of my non-designer colleagues have equally valid opinions on design as I do."

It’s a critical skill for designers to think for themselves amidst the pressure of being vastly outnumbered by other roles. The stakes are high. It’s about more than just doing good individual work, it’s setting the bar for expected product quality for everyone and avoiding the lowest common denominator outcomes.

Don’t just take my word for it, look at the science — there are research studies backing this up. Groupthink is the most common team dynamic and the results of groupthink are inferior to solitary thought by individuals.

So collaboration is great and all but that’s not the only thing you’re hired to do, to make sure everyone gets along no matter what. You’re there to make great products. You need to be strong, speak up and most of all, lead.

Conclusion

That pretty much covers my take on design sprints. I can see a lot of positives but for myself personally, I guess I’m skeptical of sticking to any one approach and taking off an entire week for a rigid format that makes an exciting workplace feel like I’m stuck in a remedial school.

I’m not saying I have all the answers, just that people should try something different if they’ve had similar reservations.

If you don’t and your team is down to try a design sprint, or you run them already and find it valuable, then that’s great! Don’t let me stop you. Rookies should have fun practicing their craft and learning new skills, and vets can use it to shake things up from the usual routine.

One thing I’d keep in mind before going into one of these: don’t worry about whether the deliverables are world changing or will fix all of your business needs in 5 days. Just think of it more as a team building exercise that indoctrinates the value of design and familiarizes everyone with the tools of the trade.

Teamwork is the ultimate end result of a design sprint because the team will still be there while various business trends come and go, so use whatever means necessary to wear all the different hats that designers are expected to be comfortable with.

On the other hand, if you’re a designer experiencing any of the problems I described about design sprints — if you find yourself chafing under rigid formats like I did with agile when I was starting out, if you like fast teams but all you want is better design input and don’t want the overhead of a dozen different exercises over the course of a week — you should probably experiment with other methods, techniques that are quicker and more flexible.

Try to mix things up a bit occasionally with things like structured sketching. Block out an afternoon once in a while (let’s say quarterly or so, whenever you feel like there’s pent up demand for brainstorming) and give the exercise a whirl instead to see how it works for you.

And most of all, just try to keep your head on straight. This job is hard but rewarding.