In terms of design processes, there are two that have proven to be integral parts to building a project: the Discovery Phase and the Design Sprint. Both provide vital information and guidance in the pursuit of bringing an idea to fruition. However there are occasions when it can be difficult to decide which to employ. Do you need one or the other? Do you need both?
First, we need to remind ourselves of the definition and purpose of each process and better educate clients on the two.
What are they?
In essence a Discovery Phase is an interval of time in which a team focuses on exploring the ins and outs of an existing product and identifying its impact on a client’s bottom line. We use Discovery Phases to discover untapped value. This is done by executing an array of exercises ranging from stakeholder interviews to user interviews, from personas to journey maps. At its end, a client is provided opportunistic suggestions on how to improve on an existing product in ways that add value to their company and/or their customers.
In regards to a Discovery Phase, it’s important to recognize that while this process’ deliverable might take many forms, its purpose is primarily to audit and recommend, not necessarily to build and implement. Instead, part of the deliverable might be specific options for designing, building and implementing the recommendations.
While a Discovery Phase is focused on review of existing products, a Design Sprint is intended to be utilized when there is a need for something new – new products, features, services, etc. It is a methodology of agile product design that revolves most heavily around end users. We design, prototype and test ideas with users to validate or invalidate new products, features and services whose value is solving business questions. At its end, a client is witness to a new idea come to life and put in front of their users in the hopes of rapid validation or invalidation. This product, feature or service is intended to show value quickly or otherwise fail quickly, saving time and resources that otherwise might have been spent on a more robust build.
In regards to a Design Sprint, it’s important to recognize that its purpose is to allow for rapid validation or failure of a product (or feature, service, etc.) which requires user involvement and feedback.
While there are some similarities in how the two processes are carried out, their intent is quite different. This difference becomes especially clear when we look at the staples of a design project lifecycle: the time it takes, what’s being produced and the people involved.
With a better understanding of the two, we can better dictate with our clients whether to conduct a Discovery Phase or a Design Sprint (and when not to).
Differentiating the Two
Length (time)
Discovery Phases and Design Sprints are often drastically different in terms of the amount of time needed to complete each. While a Design Sprint is modeled within one week’s time, a Discovery Phase can take as little as 1 week or up to 8 weeks to complete depending on the project size, complexity, familiarity and goals. Sprints can be repeated, but they follow the same routine and still focus on validating or invalidating a narrowed idea or question.
Structure (time)
A Discovery Phase might call for very mild quantitative research or it might require a plethora of user research methods to be carried out. Because of the variability from project to project, the organization and scheduling of a Discovery Phase often requires a much more custom approach than the Design Sprint. A Design Sprint, due to the nature of its deliverable, generally follows a similar structure each and every time. A Discovery Phase has us discover, research, assess, report and recommend ideas via an array of design research methods. A Design Sprint has us map, sketch, storyboard, prototype and user test in the same or similar structured approach each time.
Completion (deliverable)
A Discovery Phase can generally be considered complete when the variables surrounding the existing challenge, and the way forward for the product, are defined. What are the goals? Have we identified not just what’s wanted but what’s needed? What’s the scope of the challenges uncovered and the solutions proposed? How are the outcomes of these solutions going to be measured?
A Design Sprint can generally be considered complete when users have validated or invalidated the product, feature or service to be built via testing prototypes. Was this product, feature, service, etc. desired by users? Did users achieve their goals? What patterns surfaced from interviews and tests? What can we do better? What have we learned?
Expertise (team)
In both a Discovery Phase and a Design Sprint it’s important to bring the right team together. In a Discovery Phase we want stakeholders such as owners, designers, developers, business analysts, service reps, etc. who can identify problems to be solved. Yes, in a Design Sprint we might involve these entities as well, but we need to involve users who can validate solutions to the challenges we’re trying to solve.
Understanding the general differences between a Discovery Phase and a Design Sprint will help in deciphering which one is needed and when, as well as when and to whom to sell these processes. What are some things to look for when determining if you should pursue a Discovery Phase or a Design Sprint?
Deciding Between the Two
Generally, the broader the scope of the challenge the less likely a team is in a position to do a Design Sprint. Instead, one might consider engaging in a Discovery Phase to narrow a problem area first. Then, consider Design Sprints to prototype and test primary solutions to a target facet of that narrowed problem. For example, asking to “reinvent the way in which we communicate” might be a tall order for a week long Design Sprint, and more so a discussion suited for Discovery.
The value of a Discovery Phase to a business owner its ability to provide a crystal-clear understanding of what their company, product or service needs in order to advance and increase value moving forward. It’s a hands-on experience that will give everyone involved the tools and insight they need to make informed decisions about the future of their product or service.
In order to focus in on a Design Sprint there generally needs to be a significant amount of input to draw from. This would mean design research data should already exist, particularly in regards to users. Interviews, personas, journeymaps, ethnography, etc. should be considered prior to a Design Sprint, often within Discovery. However if these already exist, one might consider using a Sprint.
The value of a Design Sprint to a business owner is it’s ability to bring an idea to life and then validate or invalidate it quickly. This is because its structure allows for failure to happen without wasting resources, therefore quickly invalidating ideas. Yet it provides a rapid and solid foundation for beginning development on validated ideas. The time and effort spent on validation or invalidation is significantly less, therefore potentially saving business owners large amounts of money when chasing prospective innovation.
