Over five years of experience and numerous projects have taught us that in today’s world, a good product idea and execution aren’t enough. To succeed, you’ll have to answer critical business questions by keeping the user in the center, through research, design, prototyping, and testing. And so, we brought in Product Design Sprints, a series of workshops based on Google Design Sprints. It’s a battle-tested process any team can use, packaged into a one-five day workshop of structured brainstorming to answer these critical questions.
This Product Design Sprint, a 5-phase exercise, uses design thinking to reduce the inherent risks in successfully bringing products to market. With this technique, you will be able to quickly design, prototype, and test the viability of an idea, product, or feature. Working as a team in a sprint is a shortcut to the endless debate cycle and a way to compress months of work into a single week. The design sprint consists of 5 phases over typically, five days, starting with design thinking and ending with a user-tested prototype. The sprint gives you the ability to fast-forward into the future and see what your end product and customer reactions are going to be like, before making any expensive commitments.
Is it for you?
Product teams are being asked to work as a startup and decrease time to market, to remain competitive. The UI/UX teams are increasingly feeling pressured to simultaneously improve user experience while integrating better with Agile development processes. If any of this rings a bell, a Product Design Sprint may be the solution to the challenges you’re facing.
When kicking off new products, workflows, features, and businesses, this process is a useful starting point. They also work for solving problems with an existing product feature or service. These five days will involve sketching, collaborating, discussions, debate, critiquing, voting, fun, team bonding and a few tears, most often during user testing. Your team will come out with a clear sense of accomplishment and actionable results.
Phase 1: Understand
Ensure that before you look through the new information and define the problem, you review existing knowledge and expose the assumptions. Your first day will go in gathering all existing information on the business, the user, the challenge and exposing assumptions and knowledge gaps. Further, prioritize and plan to fill the riskiest knowledge gaps and validate or invalidate the most dangerous assumptions. Throughout, keep asking relevant questions while gathering and reviewing information. What situations will the users be likely to use the product or feature in? What are the motivations behind using it? What are the external motivators affecting their use? The whole team should ask themselves what product success looks like and what success looks like for just the sprint. Additionally, the team should cover existing research done before the sprint and review analysis of competitive products. By the end of this sprint, the team should have captured the critical problem.
Phase 2: Diverge
Aim to explore as many possibilities as possible, regardless of how realistic, feasible or viable they may or may not be. Make each team member sketch quick eight potential solutions in 5 minutes. The purpose of this activity is to generate many ways of solving the challenge, realistic or not. Often, we end going with the first solution that comes to mind. Of course, sometimes this could be the best solution, but not always. Make each team member sketch quick eight potential solutions in 5 minutes. The purpose of this activity is to generate many ways of solving the challenge, realistic or not. This opportunity will give rise to insights made while taking into account the implications of radically different perspectives and approaches to solving a problem. These insights become valuable differentiating forces and the source of unique solutions. Also, once you start to eliminate as many of these options as possible, you grow more confident in the possibilities you do move forward with.
Beginner's Guide To Product Design Sprint
Phase 3: Decide
Settle on the right path. In this phase, take all of the possibilities discussed over the past two days and hone in on a single version of the prototype all of you can build tomorrow. Throughout, the team should be giving thought to the more prominent assumptions, most important to test. This will lead to a discussion about what type of prototype will do the best job of validating or invalidating it. Activities like the Final Storyboard should help the team engage in this conversation. But how can we choose one idea to prototype? Use the “Risk vs. Reward” scale. Take each of the popular solutions and position it according to various risks vs. the value. It will help reveal the easiest option and what’s essential for users so that you can decide which one to prototype.
Phase 4: Prototype
During this phase, you will put together a quick prototype. Since you have just a day to build the prototype, make it as low-fi as possible and still get away with, while Testing. In this phase, roles will shift. The ones building the prototype, are usually the Designers, while Product Owners end up in charge of getting realistic data, information, and copy into the prototype. Make everybody’s role clear before the phase starts.
Phase 5: Test
In this phase of the Product Design Sprint, you test the assumptions and take in the user reactions to the prototype. While going into each test, you should have a clear plan of what you are testing and a way to judge if it is successful or not. Usability testing is the most used form of testing. Bring in a few potential users and show them the prototype you made. Pay close attention to problems they have and be sure to follow a script to cover the assumptions you are testing. You can record these, With their permission, but it's best to see them as they happen.
If all goes as planned, you now have substantial evidence and justification to petition for funding or move your design directly into the development phase. If there are still questions left unanswered, iteration is key. The beauty of a design sprint is, as soon as you get the team together again, you can quickly jump back into the sprint. And your team won't have to start from the beginning again. Depending on the extent of the questions, you can jump back in at the Diverge, Decide or Prototype phase. Now, if the idea needs massive rethinking or is just not worth pursuing, then this too is a worthy find. Recognize that concluding that the design is not useful to the users, too complicated, or just plain wrong, is a reason to celebrate. The effort and money wasted would’ve only been far more if this product went any further along in the development process.
Sprint Design is a shortcut to gaining insights without having to build and launch. However, you can’t “design think” or “product sprint” your way out of every problem. A Product Design Sprint is meant to fill a gap allowing clients to get actionable results, while still working in a state of informed intuition. Additionally, if it’s not possible to schedule the entire sprint within a five consecutive day window, spread it across two or three weeks. But, by doing this, you risk losing momentum and focus. By the end of this process, you'll have a clickable prototype you can show to potential users, investors and a stronger conviction on how to take your idea forward.
Some organizations consider the democratic approach of the Design Sprint, a threat, but they shouldn’t. The joint effort cuts through the organizational bureaucracy for a change and gives each participant the feeling that his opinion counts, contributing to a better chemistry and greater synergy in the company. Above all, by putting the users needs upfront while positioning the user experience as a problem solver, this process gives us useful techniques to increase creativity and generate new ideas.