Get a Sprint On! Agile Design — Bringing your idea to real users fast

What’s a design sprint, what do they involve and how can they help you see into the future of your great new idea?

I’ve been involved in a couple of Design Sprints in the last 12 months, they’ve proved to be incredibly useful to move things along when teams have been stuck or to test new ideas that normally would take weeks and months to test.

You can cut out the endless cycle of debate, meetings and time whilst bringing a service prototype to the table speedily. Then you can gain feedback and real time data on whether the idea is actually any good or not saving the hassle of implementing something that may not solve the problem.

The Design Sprint model is simple, 5 days and the right team, focussing on a service that is needed.

Before you start you need to know the problem that you’re trying to solve or the big idea you want to test. You also need to decide on your team. You’ll need a strong facilitator, someone in charge, a user researcher and designer. The rest of the team should be a range of people from around the organisation. The team should be kept small to allow pace.

So what actually happens during the Design Sprint?

Day 1: It’s all about talking.

Why we’re here, what we already know about our users, the big problem that needs solving or idea we’re here to look at. Practically it’s time to map the user journey as is and be honest about what are the potential blockers to delivering any new service — The reasons why we might fail are vital, they are problems we need to solve.

Day 2: It’s time to look around you.

Spending time looking at how other companies and organisations have gone about solving a similar problem or implementing an idea.

In the afternoon using the knowledge from the last day and a half it’s is time to sketch, this normally from my experience scares people but don’t worry, I can’t draw but have managed to produce understandable drawings in a number of sprints. Boxes, stick figures and words are all good visuals to use.

Day 3: Half way there and your pressure on time is building.

Time to decide on what ideas from the sketching have proved to be the best to start prototyping. This is where the ‘someone in charge’ really comes into there own, it’s time to make tough decisions and focus on what you’re going to prototype. After that get the paper back out because you’re going to storyboard a paper prototype of what’s going to be built.

Day 4: Turning it into code..or not.

A lot of Design Sprints are based around producing a prototype through coding and today is when that will get done but it’s not just about producing code, it’s also about looking at the user journey and the non digital aspects.

How does someone access your service, will it need some kind of marketing or awareness campaign? Then the team can pull together a prototype for that as well. In the afternoon, a run through of all the prototypes is needed to make sure they fit together.

Day 5: What real people think.

During the week your user researcher will be in and out of conversations making sure you’ve got real people coming to test out your prototype and building a discussion guide so they know what they’re talking to them about.

This is the best day of all, seeing real potential users interact with the things you have put together. During each session the team will be making notes of behaviours and quotes. At the end of the day you’ll need to pull together everything you’ve seen into insights and feedback to wider stakeholders.

Finally, decide what you should do next.

Questions to ask include:

• Did the prototype work?
• Did we really understand the problem we were trying to solve?
• Did it give you enough reassurance what you were doing is right?
• If it didn’t and you need to look at a different type of service what might that look like based on the feedback?

Summary

Design Sprints are a great process for moving things along or testing big ideas in your business quickly.

They are challenging to execute and require a disciplined committed team but if you get them right they are a great skill to have in your toolset. Whatever the outcome of a Design Sprint I can guarantee you will learn a lot about your users, the problem you’re trying to solve and the potential service.

Like anything new you can only learn with practice and I would recommend trying one when you’re next stuck or have something big to test.

For more information on Design Sprints you can read the book “Sprint — How to solve big problems and test new ideas in just five days” from the people that invented the process at Google Ventures.