Design Sprints are not the be all and end all.
In the last few weeks I have read a lot of articles talking about GV’s Design Sprints and how they fall short, how they’re great, blah blah blah. As someone who has completed four design sprints in the last 5 weeks, these posts seem to be missing the point.
The article that started this was User Research is Overrated by Jonathan Courtney. He talks about how the use of research findings falls off throughout the process, and that the customer feedback is what matters most. I can agree whole heartedly that it is hard to keep the customer in mind while designing around so many other parameters, but isn’t that why great designers succeed? They can take into account so many different inputs: budget, production, customer insights, the list goes on. He goes on to talk about how the research is not needed, rather giving credit to a solid goal. A goal is great — but where does the goal come from? How do you know if that’s what you should be solving for?
Then I read Barry Prendergast’s emotionally charged response to Jonathan Courtney titled Against “shoot first, ask questions later” — my response to “User research is overrated”. Again, there are points that I can agree upon with this author as well — and yet again, they’re missing the point that a Design Sprint is piece of the design process.
A design sprint needs inputs, and also demands a lot of outputs. These inputs start to happen weeks before the sprint, and the outputs can last months after.
Before you even start day one, you need to ensure that you have the right team attending your sprint. How are you going to get your team to take up to 5 days out of their normal daily tasks if they don’t believe in what you’re doing. The answer is, you’re not. Part of assembling the right team is to prove that what you’re doing has value — one of the ways to do this is through research.
Research doesn’t have to be going out and talking to customers, it could be a market overview, internal content review, conversations on internal situations etc. These all involve some level of research, digging, fact finding — whatever you want to call it.
So you have the right people in the room, but how are they going to solve for a problem if all they have is their own situations? Designing for yourself can succeed, but very rarely . Your team should probably understand how all user’s might interact with your product. This information could come from having experts in the room that actually work in the field, it could come from personas, journey maps, customer surveys, whatever you think fits.
I’m not going to go on about where else you can fit in research, you get my point (at least I hope). So you’ve run The Sprint, now what? There are all of these outputs that come out of the sprint that need to be dealt with. What are the capabilities, feature sets, program structure, who needs to be involved, can we even do this? All of these things are not answered by The Sprint, meaning that the project continues long after The Sprint has finished and more research ( digging, fact finding — whatever you want to call it) will need to be done.
Sprints are only as successful as you make them. They’re not this magical entity that just churns out amazing products at the end of it. They take planning, research, and a myriad of people working on some pretty tight timelines.