• 13 min read
• UX, Design, Workflow, Techniques, Development
• Share on Twitter, LinkedIn

Many modern software development best practices draw on influences from the industrial era and concepts like specialization, where individuals with specialized skills worked in an assembly line to mass-produce physical products. These practices from the world of manufacturing have come to influence how things are done when designing and building software products as well.

Lean thinking is one of the latest approaches software development companies have adopted to maximize value and reduce wasted effort and resources. It does so by breaking down an objective into a series of experiments. Each experiment starts with a hypothesis that is tested and validated. The output of each experiment informs the future direction. This is similar to the idea of “sprints” in the agile world, where the overall product roadmap is divided into smaller and meaningful bodies of work.

Designers are by no means immune to these shifts toward a more iterative style of creation. Nowadays, rather than design being something that’s done once at the beginning of an engagement and then never touched again, a product’s design must be flexible and adjust to changing conditions. Approaches like design thinking tend to be lean by nature. There is a huge opportunity, however, to take this notion even further and align design to the new ways digital products are being built and improved on. Let’s look first at the current approach towards design and how it has an impact on the product.

Limitations Of Current Design Approaches

Traditionally, the design process has focused on figuring out the upfront effort to define the big picture and the core design language. This core design language then informs and guides the detailed design for various modules or features. There are two downsides to this:

1. Initial Investment and Timeline Product development is dependent on the initial design direction in traditional software development, which means development has to wait for the initial design work to be completed before it can start.
2. Predicting Future Needs It’s more difficult to change a product once the initial design direction has been set. Making amendments based on market changes, customer feedback, and other new information becomes costlier.

Business leaders and product managers may become reluctant to invest in additional design activities in this scenario. They may trade effort that should be spent on research and testing for more development work in order to accelerate time to market. This can have a negative impact on the quality of the product. Further, the risk-taking ability of the team declines significantly. Once the design is presented it is considered to be final, and it cannot be changed easily, so the team gravitates toward proven models instead of being able to explore innovative new ideas. ## Design Sprints Can Help

The issues mentioned above can be resolved if the process can be modified such that the design direction evolves over a period of time instead of being fully defined up front. Such a process will allow product teams to start developing sooner and allows the design direction to be adjusted based on new learning and ideas.

This is very similar to the way agile software engineering uses sprints to divide the overall product vision into smaller sets of goals. Design, too, can have sprints.

So, what is a design sprint? Very simply these are one to three-week sprints, focused on solving specific design problems.

You will notice that the process is not very different from the regular design process, but it is condensed in a way that it could be done from start to finish in about two weeks.

Team Setup

This process works well when there are multiple team members focusing on a given design problem. Having multiple people benefits in two ways. One, it allows for doing things in parallel. Second, the collaboration leads to more ideas and quick evaluations of those ideas. Let's look at each of the steps in more detail below.

• Preparation During the preparation step the team establishes a common understanding of the problem statement as well as the related data and assumptions. Just like software engineering, design sprints are also based on product priorities and a product roadmap so that they remain aligned to overall business goals. You can use tools like the Business Model Canvas or its modified version – the Lean Canvas – to get to a good understanding of a business very quickly.

Another interesting tool I found recently is Javelin Experiment Board. With this approach, the team brainstorms who the customers are (left side) and then prioritizes (the right side). Similarly, they work on identifying the problems and the riskiest assumptions that need to be tested. All these together lead to the definition of experiments that the team needs to run. The process allows the team to quickly narrow down the goals into very actionable items.

• Kick-off and Research The kick-off and research step is where having a larger team becomes really useful. Each member of the team can have a thirty-minute talk with three people. With four people doing this in parallel, the team can complete twelve interviews in ninety minutes. Counting some extra time between the interviews and the fact that it’s quite unlikely that all interviews will happen in parallel, I schedule half a day for this activity.
  By doing only three interviews or observations per person and keeping each as just thirty minutes, it reduces the need for remembering or documenting. In my experience the thirty-minute interview is long enough that I can find patterns across multiple interviews. Longer conversations can bring more insight, but remember you can do that in future sprints, equipped with even more knowledge that will be gained between now and the next sprint.
  The research sessions make use of tools like empathy maps to capture the insights. Empathy maps provide a simple but very effective structure to capture research findings. The researchers record what the users said and did, and from that they try to figure out what the users were thinking and feeling. These are the “Say,” “Do,” Think,” and “Feel” sections below. From these the team extracts key insights and further details the problem statement.

Empathy maps are just one example. The specific research technique to apply depends on the goal and the problem. A great place to start for techniques is the IDEO Method Cards App.

• Analysis Soon after the research step, get the team together for an analysis of what they found. The longer the time in between, the greater the chance of forgetting some information and the more you’ll have to rely on documentation. During this analysis section, each person presents his or her research findings. The team discussionn helps achieve a common understanding of the research findings and priorities of the problem statements.
• Ideation So now we have a prioritized list of problem statements, and a better understanding of the users, the team can focus on generating solution ideas. At the same time, ideation cannot be a one-time activity, so over the next three days keep a loop of ideation and some detail design. Overall, within the three days the team should be able to come up with clear design direction. This could be rough sketches or high-level wireframes.
  You can use techniques like Crazy 8s to quickly come up with a lot of ideas. The technique requires each team member to sketch eight ideas in five minutes. Only use thick markers, to avoid focusing on too many details. This is a simple and fun exercise.

You can then use dot-voting to quickly identify the good ideas that the team sees most value in. Dot-voting is a simple process where each team member is given a certain number of votes (represented by paper dots), and they go through and vote on the design ideas. They may put all their dots on one idea or spread them out as they desire. After this, the team looks at the most popular ideas and works its way down to least popular ideas to identify key trends that seem promising.

• Prototyping The next three days in the sprint are dedicated to detailing out the design to a level that can help validate the design direction. Think of prototypes as a visual way to ask questions. Think of the questions you want to ask, and optimize the prototype for those questions. This means some areas of prototypes would be more detailed than the other, and that’s OK as you want to spend time on more value-added activities.
• Validation The last step is validation. Just the way we did research with multiple people in parallel, multiple team members can also do the testing with several users. This allows for testing to be completed in as little as one day.

Notice a few things that should be present in any design sprint:

• Collaboration The idea is to bring creative energy and diversity together to focus on the problems. Activities like filling a Business Model Canvas, or Crazy 8s ideation with dot-voting allows the team to actively collaborate and work towards a single direction. This leads to new and innovative solutions that are relevant to the problem at hand.
• Reduced Handover Friction Through more collaboration, we reduce the requirement for documentation. For example, the team does small thirty-minute interviews during the research step and then comes together and discusses soon after, instead of going off and documenting the research in a black box.
• Focus The team moves from one activity to the next within the same problem statement, each time moving closer to the solution. With little time lag between, it keeps everyone tightly focused on solving the right problems.

This is just one of the ways to apply it. Outfits like Google Ventures also use this concept successfully for their portfolio companies. They do a one-week sprint, but it excludes all research and initial information gathering. Their process looks like the following:

Jake Knapp wrote an excellent post on Google Ventures’ design sprint process for anyone interested in reading more about the approach they have tailored specifically for startups.

Another real-world example of design sprints in action comes to us from the Nordstorm Innovation Lab. A few years ago they did an experiment where they went into a Nordstrom’s and set up a complete design and development operation right there. They took a product idea/problem area to solve and ran through the entire process in the store, rapidly prototyping and validating an iPad application over the course of the week. See the video embedded below for more.

As you can see, the core idea remains the same, but there is flexibility to change it as needed. Each sprint may include all or only some parts of the design process – research, ideation, and prototype to validation.

It's initially a difficult concept to enact but it’s a powerful one when implemented correctly. And the difficulty is less in applying it but more in internalizing and adopting that mindset.

Design Sprint Benefits

So what are some key benefits, or the value of designing via design sprints?

1. Momentum.
   You can quickly move from one problem to the next in these sprints. You will see the momentum building.
2. Minimized waste.
   Reducing documentation and increasing collaboration, this process minimizes the activities that do not directly contribute to product development.
3. Enhances design thinking.
   By working on smaller problems, one is able to explore many different ideas and apply design thinking in a more thorough manner.
4. Encourages innovation.
   Design sprints allow for exploration and risk-taking not otherwise seen in the product development space.

It’s important to note that the structure of the design sprint does not have to remain the same throughout the product life cycle. As the product design moves along, the structure should be modified to align with the changing needs. For example, the need for generative research may go down after a large enough body of knowledge has been created. Usability testing also may not be relevant for some sprints, if the design is based on previously validated ideas. The goal of design sprints is not to build a rigid design structure, but to define an approach that allows the entire design process to be more adaptable.

Bringing It All Together

You might be wondering about the overall design direction. Won't focusing on a few small problems at a time lead to an inconsistent design? This is where what we call the product mindset becomes very critical. The product mindset requires you to take a long-term perspective of the overall product life cycle and the business value. In the short term, small inconsistencies and inefficiencies in design can and will likely crop up, but in the long run they would be ironed out.

This is something to keep an eye on as sprints are being planned and the design progresses. Software engineering sprints have a concept of code refactoring, where the engineers, after every few sprints, revisit the code and refactor it to improve the quality of the code, reduce duplication, increase encapsulation, etc. Similarly, a design refactoring exercise should be undertaken on a regular basis. It is important that everybody on the team, especially the product owner, understands this and that this is included in the product planning. During refactoring, the inconsistencies are reduced and the design direction is realigned.

How To Get Started

If you have never explored applying lean or agile practices to design, the core challenge is in adopting a different mindset. Instead of focusing on finding a perfect solution up front that would just scale to any future requirement, take a longer-term perspective that the perfect design will evolve over a period of time, with regular learning and iterations. The mindset will strengthen as you apply these concepts and see the value. To start with, just take this is an experiment that you are running to test the idea.

Identify a project where you think design sprints may be able to help. This could be a project where:

• Complexity is very high
• There are a lot of unknown requirements
• Time is limited and you need to show results fast

Talk to your team about the idea of design sprints and the value it can potentially deliver. It is important that the entire team supports the initiative. Establish the team’s role in the process, especially emphasizing greater collaboration and reduced documentation.

The next step is to define the scope and goal for your first design sprint. To do this, look at the product backlog or equivalent of that in your organization, and work with the product manager or business stakeholders to identify the highest priority goals. Identify something that you feel can be addressed within one week. The reason for keeping it to one week is to keep the effort short enough that you can run the experiment without a lot of investment.

With the priority identified, set up a working session with your team. Start by explaining the new process, then talk about the identified priorities and the rationale behind selecting them. Set up the plan for the remaining week.

If this works, then repeat it. If something doesn’t work, then tweak it to your requirements and then try again.

These concepts are new, and change can be difficult. But as product designers, our role is to build value for our products and the people using those products. The tool we use is design. As the development landscape changes, we also need to adapt our methodologies to more closely align to the changing landscape and to continually deliver that value effectively.

Reference Links

• "Dave McClure of 500 Startups on Lean VC," CoCoon HK YouTube channel
• Nordstorm Innovation Lab (website)
• IDEO Method Cards, iTunes preview
• Business Model Canvas (website)
• "Lean Canvas," Page Business Model
• Google Ventures Design team (website)
• Javelin Experiment Board

Further Reading

• How To Build An Agile UX Team: Integration
• How We Started Releasing Features Twice As Fast
• Fitting Big-Picture UX Into Agile Development
• Hybrid Mobile Apps: Providing A Native Experience With Web Technologies