Blog Posts

3/12/19 3/12/19

Minimize risk and increase collaboration with design sprints, Part 2

As a product manager, you want to enable your team to create successful digital products. To help your team achieve that you need to reduce the risk of failure for your projects.

In the first post of this two-part series, we discussed what design sprints are, how they help execute design thinking, and what benefits you can realize with design sprints.

Now it’s time to get into how to run a design sprint. And what better way to show that than seeing how we here at Mendix run them.

Recently at Mendix, we ran an abridged design sprint to figure out ways to improve repeating time entries on one of our internal applications that tracked time with our clients.

Timeboxing

Timeboxing is a key component of running a design sprint. Like any meeting, it’s easy for things to get derailed if you don’t stay on top of it. Keeping track of time helps keep everyone focused and on task. We had a set time for each of the exercises we did over the course of the sprint. If you are leading the sprint, have a way to keep track of time and give warnings as time draws near to closing. Sometimes you’ll see people use a timer and place it where everyone can see.

To start us off, we had a member of the team discuss the pain point they wanted to address to give everyone context. After listening to them discuss the issue, we took a few minutes to research relevant examples from other services to see if there are other products tackling similar problems and how they approach the problem. People looked at other time tracking and recording systems to see how they approached this or similar problems.

From there we did Crazy 8s, an activity that lets you quickly ideate solutions for a problem. We folded a sheet of paper into eight spaces. The goal is in eight minutes to sketch different possible solutions, spending a minute on each idea. The idea at this point is to stick to a high-level idea or approach.

Voting

After those eight minutes, everyone pinned up their sketches and introduced their concepts. Each person has three minutes to talk through their ideas and answer any questions. Once everyone presented, we took a few minutes to vote on ideas to delve into further. Rather than an open discussion to vote, everyone had three votes. To vote for an idea, they used a set of three sticker dots. In five minutes, everyone indicates the most compelling ideas by voting on specific sketches, not the entire paper.

They could use those dots any way they wished: on three different ideas, on one of their own, all for one idea, etc. Sometimes louder voices in a group can drown out others, or people are less willing to voice their opinion if there is someone of a higher rank participating. Voting this way helps keep groupthink out of the voting process.

*Plotting future ideas on a matrix based on user value and technical. IMG credit: Mendix, Inc.*

Following voting, we took the most voted ideas and for the next half hour went deeper into those ideas, mapping out what they could be. After, everyone presented their ideas and used dots to vote again to decide which features to focus more on. Once we established key features through voting, we plotted them on a matrix according to their technical complexity versus their value.

Once you map features onto the matrix, remove any low-impact ideas (whether low or high effort). What counts as a low-impact idea? That depends on the team and how they evaluate ideas based on difficulty and value. If you have a lot of ideas, you can vote again to help narrow them down and prioritize better. You can always capture the ideas in a document and incorporate them at a later date.

*Sketching a storyboard on a whiteboard. IMG credit: Mendix, Inc.*

Storyboarding

Focusing on the top features from our matrix, we storyboarded how those interactions would flow. We sketched on paper the different steps someone would take using the proposed features. Ideally, an interactive prototype would be made from the storyboards, but we chose to test with our sketched storyboards due to our this condensed time frame. With our storyboards ready, we discussed how we wanted to present the storyboards and any questions we wanted to ask when we tested them with people who currently use the time tracking tool.

Testing

No matter the length of your design sprint, two of the most important phases are prototyping and testing. Testing is important to validate your design with the people who would be using it. Because we were running such an abbreviated sprint, we used our storyboards as our testable prototype. Make sure to record people’s feedback, reactions, and thoughts. You can use that information to see if an idea is worth pursuing, how to revise it, and to decide which features to build first.

When you test, have one team member lead the session and another take notes. This is an opportunity to bring in stakeholders or other team members into testing by having them observe and takes notes on reactions. Taking advantage of an all-hands-on-deck company event, we went around during lunch and reviewed our storyboard with people.

Want to learn more about design sprints?

These sources are a great start if you want to learn more design sprints and how they can be used effectively.

Jake Knapp, Google Ventures (literally wrote the book)
AJ+Smart (revised the book)
Fresh Tilled Soil (wrote the other book)
DesignBetter Enterprise Design Sprints (Fresh Tilled Soil with Invision)

If you discover items that need more research and thought before you can implement a solution, using the structure of a design sprint is a great way to approach it. When you do find an approach over the course of your sprint that you want to test, Mendix makes it easy to create an interactive prototype to test with. Design Sprints are a welcome tool to help us bring more successful products and services to market.

Originally posted on the Mendix blog

Also posted on DZone

Minimize risk and increase collaboration with design sprints, Part 1

As a product manager, you want to enable your team to create successful digital products. To help your team achieve that you need to reduce the risk of failure for your projects.

Design sprints help answer critical business questions through design, prototyping and testing ideas with people who will use your product. Participating in a design sprint orients your team and stakeholders. Design sprints also help teams establish and reach clearly defined goals. They serve as useful starting points when kicking off a new feature, workflow, product, business or solving problems with an existing product.

In part 1 of this two-part series, we’ll be looking at what a design sprint is and the benefits you realize when you integrate them into the product development process.

What is design thinking?

“Design thinking is a human-centered approach to innovation that draws from the designer’s toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success.”

— Tim Brown, IDEO

Before we look at design sprints, let’s first talk about design thinking. Design thinking is shorthand for a collection of cognitive, strategic, and practical processes combined to form an approach that’s iterative and human-centered. It utilizes empathy and experimentation to break down complex problems and arrive at innovative solutions.

The goal of using design thinking is to make decisions based on what people want or need and reduce making risky bets based on instinct instead of evidence. Like Agile, it’s a collaborative and iterative process, but design thinking helps you make sure you’re solving the right problem. Agile alone is no guarantee that your teams will consistently deliver truly engaging, impactful solutions. Design thinking brings a strong user focus — ensuring user needs are kept front and center throughout the entire design and development process — while Agile is an excellent way to incrementally deliver solutions.

What is a design sprint?

If you have been looking for a way to incorporate design thinking into your process, design sprints are a valuable way to do so. They provide a structure to design thinking practices to produce actionable results. Design sprints have their strength in sharing insights, ideation, prototyping, and testing concepts in a short timeframe. Because of that short timeframe, design sprints help focus on a part of the solution. Despite that, they are an excellent way to quickly learn if you are on the right track and allow you to easily pivot.

Design sprints are a tool that the Expert Services team at Mendix has started using for internal projects and client engagements.

Design sprints draw on the strengths of design thinking and Agile to minimize risk and increase collaboration by bringing team members, stakeholders, and your audience together. Like Mendix, design sprints encourage collaboration through making. Think of a design sprint as a way to learn without actually launching a product. During a design sprint, teams prototype, test and validate ideas with people who are actually using them, before the solutions are built or launched. The team learns from user testing feedback and then iterates in a short time frame.

*The sprint gives teams a shortcut to learning without building and launching. IMG Credit: The Design Sprint, Google Venture*

Design sprints are a process made popular by Jake Knapp and the Google Ventures team in their book Sprint. As described by Knapp and the team at AJ&Smart, a design sprint can be a four- to five-day process used to solve big problems and test ideas. A dedicated team discusses a challenge, designs potential solutions, and tests with real people. You start with something vague and finish with real feedback and something tangible.

The six phases of a design sprint, from Understand to Validate. IMG Credit: The Design Sprint, Google Venture

Over the course of a design sprint you go through six phases:

Understand
Define
Diverge
Decide
Prototype
Validate

The four- to five-day timeframe is not rigid and you can adapt it to the specific needs of the problem. Some phases may need more than a full day and others may need less; although it is still important to go through all of them. The phases mirror the idea of diverging and converging from design thinking.

By taking a pause to explore a problem, you save time and resources in the long run, helping you avoid pursuing solutions that don’t work or focusing on the wrong part of a problem.

What are the benefits of a design sprint?

“The most common estimate is that it’s 100 times cheaper to make a change before any code has been written than it is to wait until after the implementation is complete.”

— Jakob Nielsen, Nielsen Norman Group

One challenge with organizing a design sprint is getting the right people in the room. Following design thinking practices, a big part of organizing a design sprint is having a diverse group of people, skills, and perspectives. Another major part is at the end of the sprint, you’re testing your solutions with actual people. By including the people who will use your product to get feedback, you can quickly learn how they respond to ideas. It also allows your users to be an important component of your development process.

*Team members sketching ideas during a design sprint. IMG Credit: Mendix, Inc.*

Teams should include members of your design and development teams, stakeholders, and product managers. By including them, design sprints can give team members a sense of ownership once you do get to a solution. Involving stakeholders in creating the solution makes them less likely to reject it later, and more likely to defend it. That sense of ownership improves the chances of the solution getting built. Design sprints break the mystery of design, helping stakeholders and developers understand the process. This, in turn, helps build trust and focus the attention of everyone involved.

In short, design sprints help you:

Get an immediate result
Incorporate stakeholders and get buy-in
Test the potential of your concept without investing in code
Limit the risk level and be able to pivot your project if needed
Boost your creativity and keep the good ideas
Maximize your return on investment

Is it time for a design sprint?

Not all problems should be approached by using a design sprint. If you have a well-defined problem to solve and access to the right stakeholders, a design sprint can prove invaluable. They are best for solving product challenges of medium- to high-impact, not routine work. Design sprints can be helpful for getting everyone on the same page and working toward the same goal.

When is it good to run a Design Sprint?

At the start of a new project to define your product or create a shared vision
When time is critical to inject speed into your development or decision-making process image placeholder
At an impasse, roadblock or fork when your product or team needs to get unstuck
After uncovering new insights to leverage new findings, data or research

When shouldn’t you run a Design Sprint?

If you don’t have user research or a strong understanding of
your customer base
If you have clear product direction and just need dedicated
design time
If you don’t have leadership buy-in

In the Mendix agile process, we’ve started to use design sprints as a way to structure spikes — tasks aimed at answering a question or gathering information — when we come across a problem or a topic on which we don’t have a clear path forward. You’ll learn more about how we use design sprints in part 2 of this series. Stay tuned!