Working on a time-constrained Google Ventures project in 2010 brought first-hand expertise to him where he had to complete the entire project within a week in a confined space.
This design process he called, in his Sprint Book, the design sprint framework— a process that would go on to rapidly progress, at first through Jake’s design sprint masterclasses and later through widespread practice.
From a first glance, a design sprint is what you get when you put together the definitions “design” and “sprint”. However, this ignores the nuances that distinguish it from all other processes.
More concisely, a design sprint is a five-day design process that captures all the five stages of the design thinking procedure, from empathising and defining to user testing.
Before discussing the individual entities that make up a design sprint framework, it’s important to fully grasp what precedes an ideal design sprint.
The presprint process entails all the necessities that must herald a successful sprint week.
What kick-starts a typical presprint process is the assembly of the sprint team. The relatively small team is primarily inclusive of, but not limited to:
The facilitator assembles the most qualified team he can find and briefs them on the project at hand. A particular week is afterward earmarked for the design sprint workshop.
Next, market research is conducted to grant insight to the design team regarding data such as current and potential competitors, product acceptance and prospects, current market trends, competing solutions, etc.
The tools and extra services needed such as photography materials, recording tools, a conducive and inspiring environment, post-it notes, and other stationeries are subsequently made available. Finally, a kick-off meeting is held among the design team, ideally three or four days before the sprint begins.
The structure of the workshop team can vary depending on the type of product. The most crucial is to involve key people for important areas of product development.
It should be recalled that a design sprint takes five days to complete. It’s also worthy of note that while design sprints conventionally commence on a Monday, there are no laid-down rules that oblige any product organization to begin on a Monday.
Arguably, Monday may not be the ideal day to start the design sprint, but that’s by the way.
In a step-by-step process, we highlight what governs each day of the five-day intensive sprint design, using Monday as the get-go.
The first day of the sprint week is considered extremely important as this is when the team asks the sprint questions, discusses the sprint’s clearly defined goals, and decides on one (the decider makes the final call here). Afterward, the sprint goal sets the theme of the rest of the week and presents critical business questions that must be answered.
With the goal identified, the entire team is now tasked with recognizing the target users’ pain points using the outcome of the market research and expert interviews that have been conducted.
In the end, there will be a harvest of numerous pain points that must now be narrowed down to effectively write a comprehensive problem statement. To manage this well, the team may adopt the following:
The day culminates in selecting a target problem that needs to be addressed by the end of the sprint week. This decision, which must be made by the decider, ushers in the subsequent day.
The target problem and how it affects the customer journey have been identified, and now the team focuses on how to solve it. The day is split into whatever number of segments the facilitator finds most suitable for the design sprint, ideally two: Morning for lightning demos and afternoon for solution sketches.
The sketches are filtered and shortlisted for deliberation the next day.
The sketches are reviewed, critiqued, and deliberated upon. The best solutions are put forward for dot voting— a method in design sprint used to ensure fairness and consensus about choices that’ll help push the sprint closer to its end goal(s). The winning concepts are then combined with the user flow diagrams developed on Day 1 onto a storyboard.
The entire day is dedicated to prototyping and testing ideas on the storyboard and combining them with tools such as Keynote and Figma to build a realistic prototype (high fidelity in this case) that may not be perfect yet, but is real enough to the user and can be tested and judged by them.
The high-fidelity prototype is tested among the team, reviewed, and tested again until everyone is convinced that the tested solution can proceed.
Now that the sprint team has certified the prototype so that it can be tested, at least five target customers are invited to use the prototype. Besides the verbal and consensual feedback from the customers, their reactions are studied using behavior science. The team makes revisions based on the feedback received during Friday’s test.
The design sprint phases are focused on providing the maximum amount of information about the product’s potential based on concrete workshop results.
If you’re considering running a design sprint for your new features or new big idea, the following are important pointers to help your decision.
Commencing a design sprint when all you have are assumptions can be quite frustrating. You will find design sprints worthy of your time and effort only if you’ve done enough customer research and you have a solid business strategy.
To get the best out of a sprint week, the team you assemble must be aware of the temporal, spatial, and mental commitment that they must have, be on the same page, and be ready to last the week against all odds.
Design sprints are used to solve one problem at a time. Some problems, however, are so big that they need to be split into smaller units of problems that must be solved independently or so small that a sprint isn’t necessary for a solution. In such cases, a design sprint methodology might not be an ideal approach.
Sometimes having to assemble a team for a design process as intense as a design sprint costs more than the usual expenditure because of extra staff remuneration, etc. If this is going to harm the long-term goal of the sprint, it’s not worth considering using a design sprint.
You’re sometimes required to achieve a product goal in as little a period as possible. In this situation, adopting a design sprint might be the best way to go.
In certain cases, what your design thinking process needs is not a long stretch of analytical moments but a brief and intense period of intuitive ideas from diverse minds working together.
Weekly Design Sprint workshops are often the best way to quickly validate an idea. The cases of our clients show that it’s best to consult product assumptions at the very beginning. Thanks to that, major changes in the project don’t cause additional costs and the product can be better fitted to the users and market requirements. COO, ASPER BROTHERS Let's Talk
When you decide to solve complex problems with design sprints, you and your team stand to gain the following:
Design sprint gives you, in five days, what you’d have otherwise achieved in a long time.
At the end of a design sprint, feedback is obtained from actual users. As a result, the company/organization is privileged to know whether to continue with the current prototype or improve/discard it without spending as much as it would have were it the conventional design methodology.
In a 2019 study reported by Global Human Capital Trends, 31% of leaders reported that most, if not all, of the work done in the organisation was by cross-functional teams.
Unlike the conventional design methodology, where teams working together in a single space is optional, design sprints prohibit teams from being in separate rooms. This fosters a healthy working environment and synergy among people with a shared vision.
Design Sprints are a great opportunity to mix organizational structures and work in teams that can inspire each other.
If you could launch a tested solution within a week, imagine how much you could churn out in a year with consistency in team effort and design sprint budget.
With design sprints, you won’t have to deploy so much time and material resources to implement a prototype that could end up being wrong or incompatible. At the same time, investors and customers are more likely to invest in your product early on if it’s been user-tested and has proven to be of quality.
While a design sprint is only suitable for specific goal-oriented problems and can barely accommodate multiple long-term goals, it still is, as discussed earlier in this post, the go-to option in several fitting situations.
Yes, it’s intense and effort-consuming!
Still, when you consider the risk of not having innovation at the heart of your product or the risk of building the wrong prototype after so much time, money, and effort invested, you will come to appreciate how beneficial it is to run sprints despite their few shortcomings.
Product Design is way more than static pictures these days. The ability to create interactive prototypes is now less complicated and...
It takes a lot to bring a business idea to life and conducting sufficient and comprehensive market research beforehand is one...
What is the Proof of Concept in Software Development? Let’s start from scratch; that is from the definition. Merriam...
Hi to every body, it’s my first pay a visit of this weblog; this
web site consists of amazing and genuinely fine information in favor of readers.