I like design sprints. In Alan Cooper’s mind, I’m now a fake designer.
Right now thousands of faux designers are trying to find ways to justify the existence of design sprints. Can’t do it. https://t.co/kbiGSGl4oH
— Alan Cooper (@MrAlanCooper) October 24, 2017
But I like them, when used correctly, in the correct context. Design sprints package up the business and design thinking in a larger process and exposes a cross-functional team to them. They also lay bare holes in research, team expectation misalignment, and organizational problems. Design sprints are great at driving alignment.
They’re not so good at making sense of messes for users. During a poorly-prepared sprint, the user may be left out of the equation, especially if the research brought into the sprint is too sparse or relient on personal opinion.
In both cases, it comes down to what a sprint does well — help the people in the room move fast, learn fast, and drive to agreement.
Designers need tools, methods. We need plays in our playbook. Some work better for driving business alignment, others work better for making sense of a mess from the eyes of a user.
The problem rises when you treat design sprint not as a tool or a method but as the whole of your design work for a product. Do this and your clean view of the world will slam hard into the cold, difficult, and messy reality of humans using your product in ways you never expected.
I’m not one who likes the idea there’s a “bright line” between designers and the rest of the world. It’s like saying only scientists can practice science. We’re all designers, just as we’re all scientists. Some of us do it professionally, with rigor and tens of thousands of dollars invested in our names and degrees. But designers are not the holders of all the Great Design Ideas Of History. We are designers because our knowledge and experience allow us to make great ideas happen more often than bad ones.
What you take into a design sprint is important to the ultimate outcome of the method. Bring your research and domain knowledge and you’ll stand a good chance of making a prototype that sends you in the right direction. Go in without research or with strongly held but untested beliefs and you will be spending five days doing self-design, the surest way out there to guarantee you’ll create a Homer Car.
I don’t like the term “design sprint.” It’s neither “design” nor a “sprint;” rather, it’s a highly compressed discovery and prototyping session. Sprints are built to break up work into deliverable chunks; they’re not one-off deals. As for design, without research it’s just five days of wild guessing.
But I also don’t like this desire for purity in the design process, either. I’d love for design to get all the time and resources it needs, for all design to work like agencies with unlimited expense accounts and all the time in the world. But, to paraphrase Hamilton, “Welcome to the present, we’re running a real design organization.” In a time where UX is still, still fighting its way into companies and evangelizing more than a Baptist tent revival preacher, none of us can just sit idly by and wait for organizations to just “give” design what it rightfully deserves. We have to win the right to be heard, show business value, and continue driving towards truly design-centric thinking in organizations.
So. I don’t hate design sprints. I’ve used them (and similar discovery practices) to get design a beachhead in skeptical organizations. If you treat them as a play in your playbook and understand their advantages and limitations, you will get value out of them.
Don’t treat them as miraculous. They’re not. Silicon Valley loves to hype its newest one-solution-for-everything. But it’s just hype. Like a playbook or a toolbox, take the things you need, understand what they’re useful for, and leave out the useless things.
And that’s what “real” designers do — they understand their tools and methods, their power, their limitations. And they are always open to new tools and methods. They also don’t believe in miracles. They only believe in the effective, rigorous drive of delivering to the user everything they need to get their jobs done.
