Summary: Design Sprints miss out on a critical data point that can make-or-break the value generated from the effort. By spiking your first day with actual user research gathered before the sprint, you can help ground conversations with an Outside-In design approach. Using a vital ROI hack will improve your Design Sprint method by mitigating against conjecture, which the Sprint seeks to eliminate from the UX design process.
All about Design Sprints- new Lean UX techniques
A ‘Design Sprint’ is a technique first developed and practiced inside Google’s user experience group by Jake Knapp. Knapp moved into a VC role and combined forces with Google Ventures colleagues to operationalize and refine the design sprint method with hundreds of start-ups (read: it’s well road-tested).
The method takes you through a 5-day (or 3-day later as needed) regular method (not a one-off!), for bringing dev and product teams together to ideate UX design. The book Sprint documents this method is very well. This is also well-sign-posted online with tools, videos, and handy checklists (How it works- Design Sprints). In other words, there’s no reason to miss this if you’re serious about Lean UX.
UX teams commonly use the Design Sprint process. From our experience, the process works well with large or small teams (8-25 people). At the end of the week, you develop a unified business approach, a prioritized wireframe, and a reality check from users (Agile user testing is performed on day 5).
What’s to love about Design Sprints
Design Sprints are a nice Agile-friendly process that marries UX and Agile. This is done through close collaboration, shared ownership of UX, and tangible results. The process speeds up decision-making, saving dozens of meetings normally experienced by product and service delivery teams.
One of the things we love about Design Sprints is that they collapse the User-Centered Design process into just one week. Design sprints also provide a great way to socialize design and business priorities without pulling you into unconscious bias.
Deficits in the Design Sprint model and what to do about it
Practicing the Design Sprint method, we’ve identified some weak spots in Design Sprints. The biggest one that gets only a brief mention online or in the appendix of the book Sprint is the absence of bringing in field research to inform important Day 1 decisions. Instead, the focus is on “Ask the Experts” (Day 1 activity) and having a Decider (“C” level or senior executive) assume a make-or-break stance on conflicting or key decisions.
To be clear, this is not a critique of the Design Sprint method. However, decades of experience have informed us that those approaches lead to Inside-Out design, whether in a workshop or a regular design meeting. This is the crazy-making part Alan Cooper alluded to in The Inmates are Running the Asylum book). Truly balanced and enlightened decision-making in UX is done by bringing in and being influenced by real user stories. This is the real data from problem-solving in your customer’s lives. In short, adopting Outside-In Design organizational habits. The Design Sprint is the logical place to leverage this ROI-enhancer, so this means bringing user research to Day 1’s review of personas, journeys and business priorities.
Spike your Design Sprints with Rapid User Research
Bringing user research to your Design Sprint will help re-direct internally biased decisions. This is especially important in organizations that don’t get out to visit with users much. When we refer to Rapid User Research, we mean 2-3 weeks before the Sprint, conduct user interviews, observations, and needs analysis discovery. You’re all set if you have already done this before you start your Sprint. Just bring personas and journey maps to your Design Sprint.
A word about user research
In the Design Sprint method, “user research” is framed chiefly as user testing. While user research is important, it is only half of the UX enlightenment equation. Field studies are the data source from which personas and journey maps come from, so it makes sense that you don’t “make up” personas or journeys in your Design Sprint. Keep your data real, and your conversations will be more fact-based.
User involvement
A further hack we have found to be helpful regarding user involvement in the Design Sprint process is to pre-recruit users ahead of the Sprint. If you do some user interviews (even phone interviews can suffice, especially for B2B applications), you can schedule users for Day 5 user testing. This is when the team attending the Sprint observes the fruits of their rapid prototyping in action with actual users. Design Sprints have you recruit your users on Day 2. This might work for consumer applications or where you know users or have them on speed dial. For B2B or for even difficult-to-reach consumers, this adds crazy amounts of unnecessary stress. Instead, be efficient and do your user recruiting for Day 5 Agile user testing in advance. You could even do this with the same users you interviewed in the field study if their schedule permits.
Have you conducted or attended a Design Sprint? Share your experience in comments below.
