The Case of Design Sprints
I’ve been following up on the design sprint quite intensively in the past few months, particularly because one of my clients agreed to have it after we offered it, because they didn’t know what to do with their product, and needed our help to jumpstart a revamp. Secondly, I’ve been in a volunteer in a national-scale movement to generate a new spring of startups through a series of mentoring sessions, and finally, incubation.
As a designer, I am sure loving the idea of spearheading design in every possible opportunity, especially the idea of integrating design in the core of businesses. I must say I agree that one of the ways for it is through design sprints. However, I must say that we shouldn’t explicitly conclude that the only way to enforce design thinking is through design sprints, nor the idea that it is just another “gimmicky” effort for make-believe.
A specific counterargument I’ve had about design sprints revolved around the idea that any method or process is useless. You know, that “anti-process” movement. Especially, when you “talk to only five testers in the end,” versus the idea of rolling out a feature or minimum viable product over thousands of users, or doing A/B testing in a quick successive way. That design sprints are a “waste of time”, because “we’ve kind of decided what we want to do.”
I must say this to you: Design sprint is only one method of many. It sprung up lately because it is a very lean activity to jumpstart and validate an idea. As you know, idea is cheap, because most of them are assumptions, and we need to validate those assumptions.
The argument against design sprints
If people argue that “it’s a waste of time” and think they’d rather launch the product first and see the feedback from the people who use the product, then I’d say, be it. Launch your product, and see.
Especially, if you have the time, energy and money to do it.
I suspect Google isn’t trying to force everyone to use design sprints, but I perceive it as a way to democratize design so that everybody in the company, regardless of their roles, can contribute to the design decision. For many years, designers have been in the “sit-in” and silent role. It’s a position where other people constantly question why a design decision made.
Imagine this situation: a CEO comes with a brief for a product concept. He constantly blurbs out amazing data and facts—combined with his enduring experience, most likely 15 years in the “industry”—that this product idea will make the next big thing. Sure, he got that investment money and ready to roll. He just needs everybody below him to see his wisdom and look up to him, and do as he says. The engineers, the designers, the PMs, the business guys, all come in and are obliged to take a nod to the Big Vision.
The “resource” team would do their “magic” and roll things out as the Big Vision tells it. No questions should be asked.
The product launches, after millions of dollars spent, and somehow, it delivers, but only in mediocre scale. What went wrong? “My team is terrible,” I believe that would be somehow in one of those train of thoughts by the CEO.
This is where design thinking should come in and hopefully save the day. The CEO could ask everybody to assess his Big Vision and try to see what would work better. Better yet, the idea by the team then will be validated by the users quicker. From 10 possible directions, they could narrow to 3, and their chance of failure is reduced, or at least, they are trying to answer a better question.
Now, if the CEO doesn’t mind spending millions of dollars to validate his idea, then by all means, skip the design sprint part. I am not going to argue against your business model.
Design sprints have been designed to reduce the wide varying answers for the very basic business & product question: will this work for my customers or people who will use my product? It will not produce the correct one, nor the God-forsaken the destiny of your product, but it will help you reduce your choices into the better ones. Nothing guarantees success!
The 5-day format is also designed so that it can be executed in a short period of time, with the most-readily available tools and space, and with the most compact composition of participants as possible. It is just the right size. It is basically a solid answer to the worry that “design thinking takes a lot of time and my company doesn’t have the time or resource to do that.”
Why is it so structured?
Designers and engineers probably think the way the sprint is structured look very rigid, because they’re used to thinking quickly, acting quickly and the most dangerous thing of all: jumping into solutions and conclusions before understanding the problem. I believe, this also applies to businesspeople as well.
Design sprint is designed so that we can all follow the proper problem-solving flow, one thing at a time, so that we find clarity every single day. It is pushing people outside their comfort zone: the easy way, the jumping-t0-solution way, the non-fussy way. Dive deep into the problem, and let it sink over nights. By the end of the sprint, we all find a common understanding, a common clarity.
It is also structured in a way that it accomodates every single type of personality. Every meeting that I’ve been always focused on the extroverts. The worst meetings are when the bosses are the extroverts. The bad meetings are when one of the staff is an extrovert and he pushes his thinking to everyone. With a voice. So loud. Cutting every conversation. This is truly bad for the team.
Design sprints have varying dynamics of ideation: sometimes it’s speaking, sometimes it silent work, sometimes it’s zen voting an idea. Or, call it “brainwriting” if you will. It makes sure that everybody gets listened to. Nobody gets in a way, regardless of their position in the company. A VP of Engineering will not push his opinion against designers just because he talks louder.
I am thinking that while design sprints are not perfect, and that there are many other methods, they are quite versatile and adaptable. If the team is not comfortable with 5-day duration, I’ve seen cases where people do it in 3 days. Although, I must say that, if your team is just starting a design sprint tomorrow, I’d highly recommend that it will be the 5-day one, and see whether the pattern fits your team. If your team is experienced enough and can think through quicker, 3-day sprints are fine.
Just make sure one thing is being done: validating with customers. Without this, your sprint is just another “self-satisfying” session with no purpose to serve the people who will use your product.
Unless you don’t care about the people who will use your product, or you just have a lot of money and time to burn.