“Will users like this feature?”
A challenging question to answer, until you actually experiment your ideas with real users—trying to understand them to solve their problem.
Things get more complicated when you need software development to test your ideas: prioritization must be done, resources allocation, coordination.
It takes time and effort that have, at this stage, a high probability of becoming waste as there is still a high degree of uncertainty.
Design Thinking is dedicated to finding the best way to solve a particular problem, that combined with a time-boxed approach, can actually save you months of coding.
Follow the QE Unit for more Quality Engineering from the community.
What are Design Sprints?
In the 1900s, Charles and Ray Eames were practical designers that learned by doing which type of chairs their customers wanted. They were followed by Jean Muir, a dressmaker placing as much emphasis on clothes feeling than look in the 60s.
These designers were the precursors of Design Thinking, focusing first on understanding their users’ needs and applying creative problem-solving.
Design Thinking expanded in the ecosystem in with three important dates:
- 1987: Peter Rowe published Design Thinking for architecture and urban planning
- 1991: IDEO shared their design practices at Stanford, being the first major impulsion
- 2005: Design Thinking became formally teached at Stanford.
Additionally, David Kelley gave a TED Talk on Human-centered design in 2007, reinforcing that the entire process is centered on the final users.
Design Thinking combines the domains of Science, Art and Design with a material and hardware approach that evolved to user experience with the advent of technology.
The deployment of Design Thinking in the software industry accelerated due to its capability to incorporate usability and value testing, critical to accelerate cycles of development that have a high degree of ambiguity, uncertainty and complexity.
There are many frameworks based on the following core iteration process:
- Empathize to understand users problem, emotions, needs
- Define to reframe the problem based on actual experiences
- Ideate with brainstorming, thinking outside of the box
- Prototype the main ideas with speed and low effort
- Test with real users feedback to go further or iterate back again.
Now, you may wonder why talking about Design Sprints.
It’s a question of survival. We all have the images of creative designers taking their time through streets to find the next big idea. But many organizations don’t have geniuses, and that free time is not available.
Companies with the pressure of digital transformation need to reinvent themselves with new revenue streams—quality and speed are must-have requirements where the Lean paradigm streamlines the activities.
Design Sprints creates the necessary pressure with a time-boxed and minimal approach to Design Thinking, effectively constraining the actors to iterate on users’ problems.
Why Using Design Sprints in Quality Engineering?
Design Thinking is only a means to an end; its fundamental ideology asserts that a practical user-centric approach to problem solving can lead to innovation, a must-have requirement for companies searching to remain in the course of the digital transformation.
Quality Engineering is the paradigm acting as the Quality and Speed counterforce along the software lifecycle requiring to perform the minimal activities that contribute to both objectives.
Design Thinking fits very well in the early stages of software development to find Quality in how to solve users’ problems before coding the whole solution. The packaging in Design Sprints is what brings Speed to keep the rhythm of iterations.
Let’s take the concrete example of assessing the value of a new feature for your users.
An instinctive approach would be to start building the entire set of functionalities in the front and back-office, taking weeks, if not months. Even if you find another early stage start-up to connect with, the integration with your system will take time.
The alternative is to perform a Design Sprint in a week performing things like engaging with users, performing A/B tests, building prototypes to assess how the problem is solved.
How Design Sprints contributes to Quality?
Quality in software is subjective: it depends on the stakeholders requirements, quality attributes and perception of value of the software product. Users drive the perception of quality in software, and need quick solutions to their problems.
The human-centered approach of Lean Design Thinking focuses first on the most important stakeholder—the users—to find a qualitative solution to their problem, and then consider implementation constraints from the design domain.
Design Sprints contributes to Quality being:
- Result-oriented emphasizing key deliverables centered on users
- Systematic with a step-by-step process to follow through
- Scalable with a repeatable framework that can be deployed among teams.
How Design Sprints contributes to Speed?
Speed is equally subjective. We can refer to a peak speed in the short-term, or to a cruise speed in the mid-term, both enabling us to achieve specific objectives.
The speed in software is required at various levels: valuable increments must be delivered as soon as possible, while the speed of continuous value delivery has to keep accelerating.
Activities along the software lifecycle must therefore be streamlined to deliver fast what matters, avoiding wasteful activities, and keeping a continuous flow of work.
Design Sprints contributes to Speed with:
- Focus in finding first a solution to the users problem in a week
- Rhythm in defining a repeatable, iterative and time-boxed structure
- Asynchronicity relying on collaborative deliverables that can be shared
- Visibility in sharing the status and design increments among stakeholders.
How To Make Design Sprints in Quality Engineering?
Quality Engineering pushes to maximize Quality and Speed while minimizing the Complexity, forces that are also required for Design Sprints.
The natural tendency of the actors will be to stick to what they know, and try to skip steps in order to “win time” (even if losing 10 times more afterwards).
The following principles will keep your Design Thinking Lean:
- Users are the main and continuous focus
- Collaborate, you are not alone
- Stick to the process (i.e. order, no bypass)
- Focus on action to build and test
- Minimal effort for prototyping
- Show, don’t tell.
Before starting any sprints, preparation is essential. You will need to correctly frame the subject of the sprint, collect data, block an entire week for important stakeholders, and organize the collaborative sessions.
These stakeholders must be part of your Design Sprint:
- Facilitator, ensuring the process, collaboration and timeboxing
- Business decidor, that can be the CEO, CMO or a senior executive
- Customer expert, with strong knowledge and familiarity with users
- Customer service, as having a greatest understanding of users problems
- Design expert, that will support with skills in design and rapid prototyping
- Tech expert, not to build things but to incorporate company’s build constraints
- Financial expert, to find a balance between the solution and company viability.
You are then ready for the week, usually working between 10h-13h and 14h-17h. That enables people to have more focus on deliverables and leaving time for people to handle other tasks before and after the sessions.
Each day of the week is dedicated to a particular objective:
- Monday: Understand
- Tuesday: Explore
- Wednesday: Decide
- Thursday: Prototype
- Friday : Validate.
Monday: Understand.
This day is dedicated to understanding who the users are, their needs, the context, competitors, identify the strategy and also clarify what’s out of scope.
A whole set of methods can be performed at that stage. The preparation done beforehands plus the collaboration will help you select the adequate techniques among this list of most known techniques:
- User Interviews (learning about users)
- User Journey Mapping (how users navigate)
- Assumptions Mapping (what are taking for granted?)
- Experience Mapping (understanding journeys)
- Empathy Mapping (feeling like the users)
- HMW Sharing and Affinity Mapping (“How Might We”)
- Importance/Difficulty Matrix (what are the easier parts)
- Iceberg Canvas (what is behind the surface?)
- Golden Paths (critical functions along user experience)
Tuesday: Explore
The first day used more of the left brain through logical and rational analysis. The second one will rely on these structured foundations to let creativity find imaginative solutions.
The goal is to explore the range of possible solutions in the space, thinking outside of the box, identifying links with other sectors or practices with:
- Solution Sketch (concept materialized in 4 steps)
- Crazy 8’s (sketch eight variations in eight minutes)
- Brainstorming (collaborative ideas generation)
Wednesday: Decide
At the middle of the week, you will have too many ideas you need to refine in order to execute them with quality and speed.
Your goal is to select the best idea to work on, refining it with other ideas, to then storyboard the idea. You will decide better with:
- Art Museum (exposing all sketches together in the same wall)
- Heatmap Voting (with 3 votes available per person)
- Silent Review and Vote
- Decision Matrix
- Action Planning
Thursday: Prototype
It is the last day before showing something concrete to the users. Building something concrete is now the priority.
Prototyping techniques allow you to quickly implement something with minimal commitment and adherences. The focus is solely on the value and usability of the product.
The following prototypes methodologies can be used:
- Storyboards
- Storyboard narrative
- Mockup tools
- Tasks & Kanban for parallelization.
Having multiple and complementary persons in the sprint helps you parallelizing tasks and also preparing the next day:
- Technical people focus on building the prototype.
- Visual people and designers focus on the minimal look and usability
- Customer oriented profiles write text and languages, search for content
- One person can be dedicated to searching specific visuals
- One person should prepare the interview template for the next day.
Friday : Validate
This last day has finally come to show your product to the users to assess how it is solving a problem. There is no validation if you try assessing it by yourself.
Showing the prototype outside of the organization will let you learn what works and what not, decide to implement further or iterate again later.
The Nielsen model suggests that you need five interviews of your identified user segments to get 85% of the feedback. Specific techniques can be used at that stage:
- Usability Study
- Cognitive Walkthroughs
- Users interviews
- Stakeholders, technical interviews
- Interview scoring.
Design Sprints within MAMOS, the QE Framework
The ending of your Design Sprint will be full of learnings, leading you to proceed with implementation, refine your ideas with more or less disruption in future sprints.
Methods are on the five fundamental pillars of Quality Engineering described in MAMOS, the Quality Engineering framework.
While Design Sprints do not always mean success, the systematic use of the methodology guarantees you to speed up the discovery of valuable software with minimal effort.
The various assets produced in the process can be leveraged during implementation like in mapping Customer Journeys, defining user-stories and detailed specifications.
Design Sprints, on top of saving you months of coding, let you gain valuable time to deliver more Quality at Speed software.
When is your next sprint?
References
Jake Knapp (2016), How To Solve Big Problems and Test New Ideas in Just Five Days, Simon & Schuster.
Elliott N. Weiss, Kelly Connors (2021), Design Thinking, Lean and Agile: The 3 I’s. Uva Dardens.
Glorian.lo (2018), What’s a Design Sprint and why is it important? Medium.
Jonny Schneider, Understanding Design Thinking, Lean, and Agile. Thoughtworks.
Peter Rowe, Design Thinking, Harvard.
Sarah Gibbons (2016), Design Thinking 101, nngroup.
Design Sprints, Google Methodology.
Design Sprints, GV.