These days we’re increasingly recommending Design Sprints to our clients to help develop new or existing products, as we find them hugely effective at getting products off in the right direction whilst building great team dynamics.
So I thought I’d take a moment to outline what a Design Sprint is, why you should embrace them, and how the Outlandish Design Sprint is different from other Sprint flavours out there.
Let’s start at the basics…
What is a Design Sprint?
Design Sprints, first developed by the team at Google Ventures, are all about developing your product idea quickly with real users. They involve:
- zeroing in on the key problem you’re trying to solve
- fleshing out a concept solution
- creating a target user journey
- building a prototype that feels like a real product
- and getting it front of real people to test.
And you do all of this in a crazy short period of time.
For good reason too; your aim in a Design Sprint is to learn as much as possible, as fast as possible, about how to make a product that can solve your users’ biggest challenges.
Wait, what exactly do you mean by ‘prototype’?
You’re not working towards producing a proposal, a pitch deck, or even some initial designs. In a Design Sprint you create a smoke-and-mirrors product that, if you showed it to users, would feel like it almost ready to launch.
For example, if it’s an app or website, the prototype is something that they can click around and interact with.
Typically, nothing works at the back-end, sure (for example, there’s no data being manipulated or stored), but still users can understand how this resource might work, and they can indicate back to you whether it will solve their main problem.
And as the product owner you get a real answer to the question: would this product deliver enough value for my users?
Here’s an example of a prototype that we built and tested for Moodle in our 5 day Sprint. Built in Adobe XD, it looks and feels like a real product, but in reality there is no back end, hosting, content management system or anything else – it’s just a collection of interfaces and screens which the user can navigate between.
You can read more about the Moodle Design Sprint here.
Why do you need a Design Sprint?
1) They save you time and money
For the fraction of the cost of developing a full product (or even a good beta), after a Design Sprint you are either ready to build for real, incorporating your user testing learnings.
Or, if the user testing really threw you some curve-balls, you are ready to iterate on your prototype and head in a more successful direction.
2) They move you away from discussion and hypotheses, to something everyone can see and interact with
They cut waste! They cut discussion! They are the embodiment of Lean: every activity within a Design Sprint moves toward decision making and action.
3) They challenge your assumptions and expose you to new ways of thinking about your users
If you’re considering a new product – or even if you have one already launched that you want to develop further – you can’t help but make assumptions about your future users. How they behave; what their priorities are; the wheres, whens, hows and whys of their problems and more.
What’s worse: you are often to blind to these assumptions.
Design Sprints are built on empathy for your users and understanding their point of view. You will immerse yourself in the lives of your users. You will bring in outside experts who speak on behalf of your users, who challenge your ideas, and who will point out the hardest parts to get right within your product solution.
This process helps you focus on the most difficult parts of the user problem that truly need solving, not the easiest.
4) They get buy-in from stakeholders
Tangible things beat ideas for support and investment from your bosses and budget holders. It’s easier for them to get excited about something that they can hold and interact with, than something that they are asked to read about and imagine.
5) They build a team dynamic and investment in a product
During a Design Sprint the entire team come together, agree a shared vision and work collectively to see it come to life. We can’t emphasise enough how important this is for a product!
Sold on a Design Sprint yet? Let me tell you about the Outlandish way we run them…
What is the Outlandish Design Sprint?
We run 1, 3 and 5 day Design Sprints based on Outlandish’s user-centric design practice. Key members of a client team work with Outlandish’s UX designers, business analysts and subject-specific experts to develop and user-test the interactive prototype
Our Sprints also incorporate our principles of consent-based decision making, in contrast with the Google Ventures role-based approach. Therefore the week includes a brief introduction to sociocratic decision-making which we have found makes a profound difference to ongoing projects and team dynamics.
A Design Sprint that’s unique to you
There are a number of approaches to Design Sprints that Outlandish offer. The determining factors include:
- The current state of the concept clients want to take into the Sprint (e.g. developing out the first product in high level idea; taking an existing product and increasing its offering etc)
- The skillset of the client team
Two example scenarios are illustrated below:
| Scenario 1: Initial concept You have identified a problem that needs solving. You have an initial concept, but not yet a launched product. Your team is light on digital UX or online experience. | Scenario 2: established product & team You have a product that is already launched with a user base. You have data and research that shows how they’re interacting with your product and what they think of it. You also have a product team that includes user-experience designers. | |
| Pre-sprint | – | Data gathering and research |
| Day 1 | Defining the problem | Analysis and personae creation |
| Day 2 | Research & Idea generation | Idea generation |
| Day 3 | Decision making | Prototyping |
| Day 4 | Prototyping | User testing |
| Day 5 | User testing | Prototype iteration |
The asynchronous Design Sprint
We also recognise that clients are time short, and taking a team out of the office for 5 days to work on developing a product isn’t always possible. With this in mind, we also offer asynchronous sprints.
Here we collectively pause after the mid-week storyboarding session. The Outlandish Senior Designer then works uninterrupted to produce an expansive, as-fully-realised as possible prototype. After a week we reconvene with the client to review and amend the prototype, prior to taking it into user testing.
Added technical proof of concept
Lastly, one of our many optional Design Sprint bolt-ons sees Outlandish’s Senior Developer producing a working mashup to demonstrate that the idea is technically achievable, along with input on codebase, approach for build and technical feasibility.
Sounds good. Where do I sign up?
If you’re interested in finding out more about Design Sprints, how they can help your product, and all the options we have for structuring them, then get in touch!
