In the past few years, few concepts in design have gotten as broad of traction as the Google Design Sprint, a condensed design methodology that goes from problem to solution in 5 days. The allure is obvious — it’s a complete recipe, meaning there isn’t a requirement for experienced designers to facilitate, and it gets results quickly. But does it go far enough?
Whether you spend 5 days or 5 months solving a problem, the overall design process typically remains much the same: identify a problem, learn as much as possible about the problem space, develop ideas, refine ideas into solutions, and then test, iterate, and implement (and test and refine some more). With UX problems, research should be part of many of those steps, both to help understand the problem and to validate any proposed solutions. Sprints, on the surface, seem like a complete solution, following the design process while incorporating research — and in some cases this might be enough. But that research, typically just a day of validation research, is purely tactical. And broadly, that’s the differentiation between a sprint and a more robust UX methodology: sprints are necessarily tactical, narrow, rigid. Teams thinking “we need UX design” — or those mandated to include UX design — often find design sprints alluring as an easy way to check the “UX Design” box, but must seriously weigh the shortcomings against the appealing timeline and approachability.
Good design at the core is problem identification, the solutions are secondary.
What good is a sprint toward on wrong problem?
The value of strategic research is manyfold. By starting at the beginning — what your users are doing right now, whether with your product or through another process — and going in with a goal of understanding, rather than validating, you will uncover problems and opportunities you didn’t previously know you had. You may find that the problem you started with isn’t really the problem at all, but a symptom of a different problem. Good design at the core is problem identification, the solutions are secondary. An incredible solution to the wrong problem may win points on Dribbble but won’t attract and retain users. Beyond your existing product, strategic research is essential for exposing opportunities for new features and products. It’s much harder to reach such insights through tactical, validation research, as the focus is too narrow.
Experience matters
Strategic research takes time, often longer than an entire sprint. Longitudinal research methods, such as a diary study, may take weeks or months to yield results. And while the technical process of conducting research may seem straightforward — just talk to users, right? — anyone who has done it a few times can attest to an evolution of research skills over time. Learning how to structure research, when and how to probe for more information, and how to interpret what you’re seeing and hearing is a learned skill. Anyone can run research, and many people throughout the organization should be involved in the research process, but it helps to have experienced researchers facilitating. This time and resourcing can be at odds with the sprint process, which is meant to be quick and completed by anyone.
A little flex goes a long way
Within research, and the design process at large, flexibility is essential. While the overarching process may be the same, different problems benefit from different approaches to that process. Whether the product is content-heavy, workflow-heavy, or both has considerable implications for what sort of research, ideation, prototyping, and ideation are effective — and not all methods take the same amount of time. In the sprint world, flexibility is traded in for ease of implementation — a prescriptive recipe for design, rather than a set of ingredients. This makes sprints more approachable, but not optimized to the project at hand.
Sprints can be useful, with the right expectations
Are design sprints bad? Not at all. They’re just not the solution for everything, and especially not for solving big problems — a point which can be lost amongst teams looking for a magic bullet. Design sprints can be helpful in solving small, tactical problems, such as UI-level problems (“how do we better display this list of items?”), to achieve incremental improvement. They can even be implemented alongside strategic design. In organizations with internal or external design teams, an effective paradigm can include product teams running sprints to solve backlog issues, while design teams tackle strategic issues. Those strategic efforts lead to insights and opportunities that should be shared amongst the teams, leading to transformational shifts and helping to inform future sprints.
Deciding whether design sprints are right for you should start with an honest evaluation of what you’re trying to accomplish, and what else is ongoing from a design perspective. For small, specific problems, a design sprint might work. But if you want to advance your product beyond incremental fixes, ensure a broader strategic design process is implemented as well.