Why we kick off any new project with a Design Sprint

“Fail fast” is probably the most abused claim in startups: learning from mistakes and iterate would increase the chance of a business to succeed. But putting this into practice it’s trickier than it sounds, especially when it comes to get your hands dirty with digital product design: there are plenty of methodologies, theories and frameworks out there.

In this article we explain why, so far, the Design Sprint has proven to be the most effective way.

Who we are, where we come from

We are an Italian studio of designers and developers working both with digital product companies in their startup stage (as happened with Wanderio—a travel platform) and with premium brands in need of affirming their web presence (as with LocalEyes—a global internationalization consultancy).

In our professional growth we felt more and more of a desire to help our clients in defining what comes before kicking off a project: the WHYs (what problems you’re solving) and HOWs (how you are addressing them).

In our experience a true impact on a product experience can be created when there is a close connection and collaboration between business, designersand developers working as a unified team.

This change in mindset led us to test various tools and techniques, from User Story Mapping to Lean Service Design.

The best one in the toolbox so far has been a short, quick and intense design method called Product Design Sprint (also known as Design Sprint, or just Sprint).

Design Sprint: a process that leads a inter-disciplinary team into understanding the problem, exploring possible solutions, prototyping and testing a new idea—in just five days.

MVP is probably too late

When building an MVP (Minimum Viable Product) it is very hard to build something really “valuable” in less than 2 or 3 months of development.

So the commonly–accepted mantra says:

• have an idea.
• build an MVP.
• put it in front of real people.
• measure, learn and iterate.

Waiting 2 or 3 months in the making of an MVP means taking on all the assumptions and bias that come in the early design phase.

Why the heck wait so long?

The risk of building an MVP before getting enough feedback in the early stage is to fail, at the end, to address the real problems waiting to be solved — and could be solved much earlier.

The Design Sprint: how it really works

The great change came with the idea of building a prototype and test it soon with real people in a short time frame (five days of work). The method is called “Design Sprint” and comes from GV (formerly Google Ventures) as a way to understand the true potentials of the projects they were investing on.

“It’s true that every great entrepreneur is first and foremost a designer.”

— Peter Thiel. Zero to one: Notes on startups, or how to build the future.

A big change in mindset

First of all everyone works as a team, focused in workshops.And all of our devices can take a break. In our situation that meant working side by side for 5 days with our client and our team, doing what “design thinking” is meant to do:

In Design Sprint everyone acts and thinks as a designer, in a journey where each day represents a process phase.

• Day 1: start with the understanding of the problem.
• Day 2: explore the possible solutions.
• Day 3: decide what to build.
• Day 4: build a prototype (a façade).
• Day 5: learn from showing the prototype to real people.

What we’ve learned from applying the Design Sprint

We have been lucky enough to put in practice the method of the Design Sprint in several digital projects so far, for entrepreneurs and companies operating in different industries and with different goals.

These are some of the lessons learned.

1. Why just 5 days

One week is the right time frame to explore and choose one single design concept to prototype.

Less of it and you won’t have the time to completely understand the problem you’re solving, or you won’t have enough time to explore divergent solutions, or you won’t be able to build a realistic prototype and test it with real people.

More than that and you could fall in the trap of converging too many ideas into a solution or worse, change your minds again and again.

2. Why just one day to prototype an idea

Sometimes we were asked “why just one day to build the prototype? it can’t be enough for a prototype”.

While building a proper working prototype might require a lot more of a work day, the goal of building a prototype in the Design Sprint is to create a fakeproduct.

The prototype should be good enough to be realistic to the eyes of people and get their spontaneous reactions.

This, in our experience, could be usually done (in the case of a website or an app) with high-fidelity (realistic) layouts and a tool like InVision to create animations and interactions.

3. Why testing with real people is important

The major risk of not doing any validation at an early stage of a design concept is to take with you all the team’s inevitable assumptions, related more in detail to how people perceive the problem you’re trying to solve, and if they understand the very specific way you’re trying to solve it (metaphors and mental models).

One of the most interesting answers we want to hear from people testing our prototypes is how they would describe the product to a friend.

It is surprising how often people don’t understand things you took for granted while instead they don’t pay attention to things you gave fundamental importance to.

4. Why five days are never enough

Five days are enough to get to know more about your product idea or the problem you’re solving. But the party won’t get over with the last user interview and the collection of all the feedback from users. What happens next?

• Need of another iteration: if the chosen design concept did not prove to be effective in addressing people problems during the interview, or if people didn’t get the value proposition of our idea, the right thing to do is to perform another (probably smaller) Design Sprint to adapt and rapidly test the improved concept.
• Start building: if we got the information we were looking for and the overall product direction seems correct (or we know where to improve), it’s time to plan a high-level project roadmap with an estimated time (number of iterations) needed to complete the project.

5. Why doing homework matters

Design Sprints don’t appear from just anywhere. They start from what GV calls, in their book, a challenge: something specific you would like the sprint to focus on.

Some examples:

• Existing product or company: explain and sell a new product on our existing website.
• New product: build a new service for people looking for a pet sitter while they’re on vacation.

In our experience before starting a sprint it is essential that the decider (the entrepreneur, or the Product Manager) comes up with a deep understanding of the problem to solve, of the market and existing alternatives / competitors and the business opportunity—often even an early draft of the Business Model Canvas helps a lot as a starting point.

6. Why everyone can join

“Big Data Design Thinking is like teenage sex: everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are doing it… ”

— Ancient quote, reinterpreted.

Design Sprints are a pragmatic way to practice what the current trend calls Design Thinking. It is a way to put everyone on the team to think and act as a designer.

It is a change in mindset before anything else. A Marketing Manager or Engineer needs to think as a designer in order to pursue the goal of getting more information on the problem we’re solving and on the way we’re planning to solve it.

This, in a consultancy business, evolves from the traditionally flawed client–vendor relationship where the Expert wearing the designer–hat gives compelling answers to the Client / Boss trying to please him, not to make him successful.

Instead, in a Design Sprint, everyone explores and as a team pursues the best solution for the most important piece of the project: the people we’re building for.

7. Why no two Design Sprints are the same

In our experience so far no two Design Sprints were the same. The approach to work changes a lot, depending on which challenge you’re facing.

Understanding how to explain on your website what your companies does (mostly using textual communication) will require a very different approach and mental energy than creating new design concepts for a raw product idea (mostly finding new metaphors and unexplored system models).

Creating the right mix of skills in the team will help in making the process effective.

8. Why still very few people work this way

Everybody knows today how valuable it is to do user testing, despite the fact that I still talk with a lot of colleagues in my industry who don’t do it. Sometimes I’ve heard them say “Yes, it’s crucial to listen to users, but for our organization it would be impossible; we’d rather build an MVP and then collect reactions”.

In these scenarios I try to explain how much we learn when we show an early concept before doing any building; but I know how hard it is to move from theory (we should test) to action (let’s arrange 5 user interview sessions).

Why? I think mostly because if you don’t adopt a process you don’t know where to begin; also, recruiting users is a pain and let’s be honest: asking strangers about their habits at first sounds a little awkward. In our direct experience we benefit a lot from staying in a co-working network (Talent Garden) full of people willing to help.

Early–testing has been of enormous value and of amazing help into better understanding the problems people have, how they face them and how our solution would eventually fit into this.

The triage

What we learned in all these years of work is that doing software the right way is hard. It is very easy, in the early design phase, to fall in trap of all the assumptions we normally bring with us.

The Design Sprint is the most effective tool we experienced so far. While it’s still a relatively young approach, it has demonstrated to be a valuable way to be more aware of the possible trap of a design solution.

The N°1 requirement, though, it is to form a unique team where business, design and technology are all well represented and willing to understand each other.

To us, as designers and technologists, working with our clients on Design Sprints had been a chance to discover we had a knack for getting our hands dirty on the comprehension of their business.

This means committing first in making our clients successful rather than chasing just a fancy design.