Posted on: 14 September 2024
Design Sprints as an approach to tackling design challenges has seen some adoption in design teams. And the reasons why are pretty compelling: it is a well-defined process with hands-on and collaborative activities plus it can lead to concrete results in relatively very little time.
The learning out of a sprint can be eye-opening to the team and other stakeholders. And from a design process perspective, it follows the three key ingredients of a successful human-centred design process:
All this can happen without committing to a solution outright. You don’t have to build anything concrete just yet, and you can find out after launch if it works in the hands of users. The business case is also quite clear, with the application of Design Sprints, the team benefits clearly in product design and saves time and investment.
Many design teams have seen the benefits of design sprints and adopted the approach in their projects. Teams test the limits of the process and find that there are great fits, good fits, and not-so-good situations to use a Design Sprint.
One limitation of the approach is obvious: you can’t solve ‘everything’ in 1 to 5 days. Yes, you can dive deep into a wicked problem and learn a ton, but you can’t design a whole ecosystem, family of products, services, or large systems in that amount of time. There is too much to do to fit it all in. This could cause issues with teams who have projects that take many months to complete, and require large amounts of design work.
Another limitation is that Sprints are less suited if you need to address short-term burning issues immediately. Designing for incremental changes can be addressed through other design approaches. Typically, Sprints work well when you need to test out new ideas. And you’d decide early on if the new ideas should be a Step, Jump or a Leap forward. If you are doing a Step forward, i.e. incremental changes, the Design Sprint is often not as good a fit.
There are many other best practices and reasons to apply Sprints, which I will not go into here, but the above two reasons made us think if there was a way to address the real-life needs:
This resulted in an extension to the conventional Design Sprint approach. We call them Design Tracks; let’s cover this next.
In thinking of how to augment the Sprint engagements, we talked about making the Sprints longer, shorter and we explored how to make the Sprints cover different aspects of design, not ‘only’ exploring a design idea that is the focus of a Design Sprint at the moment (I know, there is more to it).
We defined 2-day, 1-week, 4-week, and 12-week Tracks that cover a specific design phase (Discover, Design, Test) that can happen pre-code sprints (sprint 0, planning) and between code sprints or in parallel to code sprints (if that makes sense in the specific team product context).
The first and shortest engagement type we called the Step.
Even though the Design Sprint can be flexible in length, teams often gravitate to thinking Sprints are 4 to 5 days. So to differentiate between that and shorter 1-2 day sprints we introduced the term Design Step.
The goal is to start and create the initial Design Step that allows the team to explore an immediate design challenge or break open a stalled design conversation. Sometimes that needs Design, but other times it needs a quick Test by a new pair of eyes or a quick step back to Strategy at a more strategic level.
The Discovery Step allows product owners, and product managers to step back and revisit assumptions and product direction. A level setting of where we are going.
The Design Step provides a focused effort in breaking through ‘design stalls’, tackling a burning issue to allow for limited exploration and a time to reflect and solution a way forward.
The Test Step helps to move forward with a design, teams stay heads down too long and need to allow a bit of time to look around, look at the market out there, competitors, similar experiences to learn from and validate the design direction.
The Step team is small and nimble, 2-4 people max.
This type of approach is where it all started, here we have the well-defined, almost traditional by now, 4-5-day Design Sprint, but added to this. We have now Discover Sprints and Test Sprints to augment the type of activities in a Design Sprint.
The Discover Sprint can be done either after one or more Steps or as a first activity. The goal is to help answer UX foundational questions as ‘who is my user/customer?’, ‘what do they do with the product/service experience?’, ‘where do they interact with the product/service experience?’. The output is user and customer personas, and journey mapping. It sets the stage for subsequent Design Sprints.
The Design Sprint tackles specific business questions through design and quick testing with customers/users. This approach was initially developed at Google Ventures.
The Test Sprint is a fast way to gather end user feedback on a (concept) design. This is a larger version of the testing activity that happens during a Design Sprint and can be done independently from a Design Sprint.
The Sprint team is still small, 3-5 people max. plus client team partners (1-3 usually).
Both the Steps and Sprints are meant as initial or starting activities and work well if a product team explores new ideas or needs a different take on a design direction. But what about the detailed designs and incremental, ongoing design with larger scopes? This work usually doesn’t fit well in a 1-week approach.
This is where the Run comes in, a combination of regular Sprints plus, in places, a 3 to 4 week ‘extended Sprint’ that will cover much more of the product experience, sometimes even completely.
A Run is usually part of a larger project milestone. Something that needs a dedicated block of time to add a product feature to an in-market product, create a deep understanding of the user stories, user requirements, test a business-critical aspect of the experience with end users or revamp a poorly designed existing feature or area in a UX design.
The Discover Run starts with a Discover Sprint to identify or confirm the current state understanding of users/customers and their journeys. This is followed by an Extended Discover Sprint that will have deeper user and customer research in the form of interviews, observations, survey or for example card sorting research to guide the information design direction.
The Design Run takes a number of Sprints in an iterative design approach that often builds on the insights from a Discover Sprint into a first Design Sprint, extend that into a more in-depth Detailed Design Sprint 2, then a Test Sprint and expanding the experience into a third Detailed Design Sprint to cover more of the user experience that was created in Sprint 2. It provides an approach that allows both big idea exploration and address concrete design challenges.
The Test Run is scaling up the user feedback to include more end users in the UX testing phase, allowing for an increasingly de-risked design that are usually more complex and carry a higher business impact if sub optimally designed.
The Run team is mid size: 5-7 people max. plus client team partners (3-5 usually).
But even a Run cannot always cover the scope and complexity of the design challenge at hand. We found that in many projects, because of their size, the Relay duration of 12 weeks works well in an agile product environment and is often needed to deliver to the project needs; covering critical customer and user journeys, expanding in design areas of contention, and aligning all design stakeholders to deliver intentional experiences for your MVP or incremental product releases.
The Design Relay is a combination of 3 to 4 Design Runs. Pretty straightforward you’d say. It is and we found that doing three in a 12-week cadence hits the sweet spot of getting things done, keeping a clear focus on the end results and allow for a realigned where needed after the 12 weeks. And it fits well with many Agile development environments that also use the 12-week intervals.
The Relay team is 6-8 people max. plus client team partners (5-7 usually).
If you are still with me at this point you might want to know now where to start, what is the right order and number of Steps, Sprints, etc. The answer to that turned over time into a framework we developed and now use for these types of projects: Design on Track.
What worked most effectively is having an experienced UX manager run a planning session with the client (either internal stakeholders or a whole product team). Explore the scope, timelines and what needs to be done followed by an interactive session (or two) to flesh out the approach in more detail, to see the impact of using a Sprint vs. a Run or even a Relay to the overall project design goals.
The planning tool allows us to explore different scenarios of how many workshop, interviews and other user research techniques we’d apply in the Discover Steps and Sprints, then to how many wireframes, visual design needs to be created, if the design system is in place, what the impact is of that is to the overall timeline and finally how the testing is conducted, how many participants, on what devices, remote, in person, etc.
With Design on Track build into the DoT planning, it made it much more insightful for teams and stakeholders to see what would happen when elements were moved, changed, deleted and over time we found that the questioning why something needed to happen in an activity (e.g., doing a test with end users) was much less questioned as it was integrated into the overall approach from the start.
The planning sessions allowed also for a much richer conversation around what it takes to create great experiences. The awareness building is ongoing, and every interaction helps in having meaningful conversations around how to get the most out of the available time and budget.
Our Design on Track continues to improve with updates and refinement of the detailed approaches. And it will always evolve. Our clear alignment and shared agile approach with product teams have enhanced many projects to date.
Let us help you with yours!
Comments
Related Articles
Don't miss an article! We'll notify you of each new post.