Minimize risk and increase collaboration with design sprints, Part 2
Minimize risk and increase collaboration with design sprints, Part 2 by Nicholas Di Stefano
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 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.
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.
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.
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.
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.