Founders of UX Series
History of Design Sprints.
1. Understand – identify your problem
2. Diverge – brainstorm ideas
3. Decide – prioritize and plan
4. Prototype – make something real quickly
5. Validate – test with people
Design Sprints were popularized in the book “Sprint: How to Solve Big Problems” – which can be grabbed on Amazon: https://amzn.to/3tTPVIG.
Design Sprints can be applied to any project or problem, however, they are commonly used to solve business strategy problems for startups or established companies.
Practical User Experience
When are Design Sprints commonly used?
Design Sprints are used in the startup world as a way to make sure the company is headed in the right direction before time and resources are invested.
This method can also be used by established companies who need to solve big problems, such as what products to introduce or what new features should be focused on.
Are there any rules to consider when conducting Design Sprints?
Design Sprints are incredibly versatile and can be used for solving a number of different kinds of problems. Teams should consider whether Design Sprints best suit the problem they’re looking to solve or if another process would be more appropriate:
Keep the following in mind when thinking about when conducting your next Design Sprint:
1. Work best when they focus on specific, time-bound tasks.
2. Work best when Design Sprint teams include a variety of perspectives and skill sets.
3. Should be designed in a way that encourages collaboration.
4. Teams must set goals and prioritize activities before beginning.
5. Can produce either concrete or fuzzy solutions depending on the amount of time spent up front.
6. Require designers to ensure that any solutions or prototypes are clear and concise – both in terms of layout and messaging.
7. Require that teams allot enough time before the demo for revisions.
8. Can run for either one-week or two-weeks.
9. Work best when teams are encouraged to explore blue-sky thinking followed by rapid prototyping.
A wide variety of people can be included in Design Sprint teams, but there is no set rule on how many people should be involved. These are some recommended team roles you may want to consider including:
Content Strategists – understand customer needs and goals through analytics and user testing data.
Copywriters – wording that accurately communicates what customers need to know.
Graphic Designers – layout/messaging to ensure customers understand value of a product/feature.
Marketers – identifying customers and defining the right message for each.
Solutions Architects – understanding system requirements and technical limitations.
UI Designers/Developers – prototyping user interfaces and interactions to solve customer problems.
UX Designers/Researchers – important for helping teams consider key UX design principles.
If you’re using Design Sprints as part of your UX Design process, it is helpful if they are by someone who has some form of Design experience.
UI/UX How To Series
What is the process behind Design Sprints?
The Design Sprint process begins with a kickoff meeting where participants typically include Design Sprints facilitators and key stakeholders from business or marketing teams.
The Design Sprint team will work together to set the problem context and identify what solutions are wanted for the particular issue.
Participants should be encouraged to discuss as a group various ideas about problems that need solving, including both current issues needing immediate attention, as well as potential future issues that might become more important over time.
The second phase of Design Sprints takes place over 2-3 days and is used for idea generation by working in small cross-functional teams – usually 5-7 people including at least one representative from each of these roles: Designers, Developers, Content Strategists, Usability Experts and Product Managers.
In this phase, teams are asked to think big and draw upon extensive internal knowledge about the company’s history and culture. Design Sprints should be designed in a way that encourages collaboration among these different roles in order to generate a variety of ideas from different perspectives.
Design Sprints work best when there is ample time spent up front for diverging in order to uncover a diverse range of ideas before moving into narrowing down or selecting specific concepts.
Based on the types of problems being addressed by Design Sprints it’s important to set goals prior to beginning this phase. If you’re looking for concrete solutions or narrowing ideas, Design Sprints work best when tasks are limited to a few days. For example:
- What is the one product feature we will focus on for the next 30 days?
- Design a completely new page/feature in a website with 5-7 screens
Design Sprints can also be used for ‘fuzzier’ problems where teams are tasked to brainstorm activities that might take longer than one day to develop an answer.
In those scenarios it’s important to prioritize those activities based on their potential impact and set expectations as appropriate – help your team figure out which problem areas will benefit most from time spent.
This is where Design Sprints really stand out from other problem solving processes. Teams will use the Design Sprint process to prototype an idea, product, or feature.
Prototyping can occur through sketches or wireframes using pre-compiled smart templates on Paper, or via digital mockups using software like Adobe Photoshop, XD, Illustrator or InDesign etc.
Low-fidelity interactive prototypes built with SaaS tools like InvisionApp and UXPin, higher fidelity interactive prototypes built with tools like FramerJS and Pixate, or even real interfaces that are coded into working products.
Designers provide input on best practices for prototyping based on your current team’s workflows depending on the type of design deliverable you need for this phase.
The Design Sprint process ends with a demo/presentation to the client, team members and other stakeholders. Designers will work together with teams to ensure that any design solutions or prototypes are clear and concise – both in terms of layout and messaging.
Designers share best practices for demos that mirror their UX Design process but recognize the importance of working closely with facilitators to allocate enough time before the demo for final changes to be made if necessary.
Why do UI/UX designers love Design Sprints?
Design Sprints are often described as being fast, effective ways to solve problems.
Designers conducting Design Sprints need to ensure that they have support from key decision makers. Once that box is checked UI/UX designers find Design Sprints tend to promote amazing collaboration between teams. This pays dividends later when designers may be required to navigate roadblocks within the company as UX Design work is being conducted.
Other reasons UI/UX designers love design sprints include:
- Design Sprints provide Designers the opportunity to conduct research and also prototype their designs with customers before any work begins.
- Design Sprints tend to break down large Design projects into smaller chunks so Design can be more manageable.
- Design Sprints allow Designers to test their assumptions and think critically about the problem they’re solving.
- Design Sprints help Designers understand Design best practices by following tried and tested UX, UI and Interaction Design frameworks (e.g., Google Ventures’ GSIX framework).
Are Design Sprints an expensive exercise?
On average Design Sprints can cost companies anywhere upwards of ~$3,000 per day for allocating team members, but the costs obviously vary depending on the Design resources required and structure allocated.
Designers should also factor in travel and other expenses as well as time needed to prepare Design Sprint materials (agendas, Design Sprint manual if working via a process such as Google Ventures’ GSIX framework).
Design Sprints may not be useful for every situation or teams encounter. Be sure to consider any barriers that may prevent your company from conducting Design Sprints before moving forward with this exercise.