A couple of months back I was conducting a Product Design Workshop for a client of mine and briefing her on the procedure that would be undertaken. She asked me this,
“So, this is basically Design Thinking, right?”
There has been genuine confusion and not everyone in tech works using sprints, but almost all of them will know what they entail. Being a Product Manager for the last few years, I’ve led many initiatives and the most crucial part of their initiation. Having worked for different types of firms, the amount of effort that goes into Brainstorming, Meetings, Research, Resources has always been endless in both the set-ups. When I stumbled upon the Design Sprint concept, it was clear to me that it’s the way to actually get things moving fast. In this article, I will outline some of the basics of what happens in a Design Sprint Workshop — expectations each day, what you’ll learn, and how to have an effective, successful Design Sprint.
For a UX Researcher, Designer, or Product Manager, it’s a popular method that promises to apply the magic of Design Thinking to products and features quicker than the speed of light. So ideally, Design Sprint uses a toolkit from Design Thinking to arrive at a business solution. The two processes are “cousins” to each other, but they have differences. Design Sprint is a sequence of steps while Design Thinking is tools that help us execute those steps. Let’s think about making pasta. In this case, Design Sprint would be the recipe for pasta, and Design Thinking the ingredients that would go into the pasta. Sprinting may seem a bit intimidating at first. But if the business needs to move quickly, it’s worth giving it a go.
First thing First, What is a Design Sprint?
A Design Sprint is a step-by-step process for answering critical business questions, creating new products, or improving existing ones. While it won’t leave us with a finished product, it’s debatably the fastest and cheapest way to validate business strategies or product ideas with real users.
“The sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers”
-Jake Knapp, Author of SPRINT
Google Ventures ‘GV’ calls it the ‘“greatest hits” of business strategy, innovation, behavioral science, design thinking, and more. To know further about the history of Design Sprint read here.
When to use Design Sprints?
Design sprints are useful at many different stages of a product lifecycle. One good reason to run a Design Sprint workshop is when you haven’t talked to your users enough. But, here are some great times to do a sprint:
- Kicking off a new initiative
- Looking for new breakthrough features for a product
- Need to revamp an existing product
Why Should You Run a Design Sprint workshop?
Teamwork spirit or teaming up has always been stressed upon in the corporate world and aligning a team around a shared Vision can be judiciously taken care via Design Sprints.
- Once the Vision is in place the next step is to analyze and answer critical business questions.
- Discovering the essence of a creative challenge or problem.
- Cut through endless internal debate by building a prototype that the customers can give feedback on.
“Most of our ideas are wrongheaded. In fact, 60–90% of ideas do not improve the metric they were intended to improve. You can invest in convincing people why your idea is the best, or you can invest that time in testing it to find out.”
– Barry O’Reilly
What do you get out of a Design Sprint?
- A high fidelity clickable prototype that looks and feels like a real product.
- Usability test results and recordings of actual users.
- Insights and recommendations from usability testing to improve the product.
Why use Design Sprints in Product Development?
- Validate product-market fit faster. Design Sprints are a great way to visualize and prototype ideas quickly, and then test them with your target group before investing in development.
- Move fast without breaking the bank. With Design Sprints, you can explore product ideas fast through rapid prototyping, without writing a single line of code.
- Take product decisions with real data. Design Sprints help you drop the guesswork and test your product with real users to bring out valuable insights and make decisions.
The Exciting part of this long post — A 5-day Design Sprint Guide
This does not imply that the process has to get over in a literal 5 days, this is just a way of dividing the work neatly. This is what you are going to do during the 5 days of the Sprint:
Day 1 |Make a Map of the problem you face. The first day’s activities help you define key questions, your goal, hear from internal experts, and pick an area of focus. Remember Getting started is>>Being Right.
Your Agenda For Day 1 should look something like this:
- Introduction to Design Sprints, Sprint Challenges, Long Term Risks
- Experts’ panel: each one presents his or her vision of the needs. Notes ’’How might we?’’
- Target users, Creation of the “Map” — scenario and User Experience, Choose the most important elements of the experience and which points to solve
At the end of Day 1, you will have a well-defined strategy which will serve as a guideline for the rest of the Design Sprint.
Day 2|Sketch instead of group brainstorming, the process prioritizes individual sketching of solutions. Also called as the Ideation Process, this steps avoids plain brainstorming and brings more interesting solutions on the table.
Your Agenda For Day 2 should look something like this:
- Lightning demos, reference research, benchmarking, etc.
- Idea hunt
- The four steps of Sketching: Notes, Sketch, Crazy 8’s, Solution Sketches
Day 2 would allow you to explore several paths and sometimes bring old ideas that you never really dared talk about but actually may prove to be excellent.
Day 3|Decide and look into the potential solutions and works together to decide on what to storyboard and prototype. This is where the team will make important decisions regarding the rest of the Sprint
Your Agenda For Day 3 should look something like this:
- Presentation of concepts, brainstorming on the feasibility of ideas, impact and effort.
- Supervote on the GO-TO idea which ultimately has to be prototyped.
- Planning the test scripts, test cases and scenarios, content, and structure of prototype.
At the end of Day 3, contents for the prototype is ready from storyboards.
Day 4|Prototype rapidly on the basis of the storyboards in order to have something visual and tangible for the users. Take the prototypes to actual users and see how they’re interacting with what the team has created over the week.
Your Agenda For Day 4 should look something like this:
- Protype creation by the designers/product managers.
- Last minutes modifications prior to testing.
At the end of Day 4, you would have successfuly created a high fidelity prototype ready for testing by real time users. Some of the best tools that can be used for Prototyping are INVISION, FIGMA, ADOBE XD.
Day 5|Test your prototype to five different users in one-on-one interviews to gather feedback and get a gut-check on your possible direction. Try recording each session or go Live-streaming.
A few minutes of testing with a user will reveal most flaws or potential flaws for improvement: remember, the prototype doesn’t have to be perfect, it should above all help you create the real product and avoid the pitfalls inherent to the creation of a digital service.
Now it’s completely normal to exceed the 5 days expectation. Something that we normally call an Itteration Week. The idea is to make the prototype better based on the feedback gathered.
My Two Cents on Design Sprint:
As a Product Manager facilitating a design sprint, I have understood that when you experience it(the Sprint Week)yourself, you understand how powerful and effective those methods are. I can talk endlessly on how design sprint is an effective framework with alternations here and there. Personally, what strikes me the most is that it uses strict timing for each step, prohibits lengthy discussion and favours individual inputs as much as group work — Something we Product Managers always favour.
At the end, it’s about More Happy Users and Less Guesswork!!!