paint-brush
How to run a successful Design Sprintby@g.krasadakis
756 reads
756 reads

How to run a successful Design Sprint

by George KrasadakisSeptember 25th, 2018
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

<strong>Consider this situation</strong>: your company needs to solve a major real-world problem — you need a novel solution, better than any other offering available in the market; you could be aiming for a <em>product</em>, <em>a component</em>, <em>a system</em>, <em>a service</em> or a&nbsp;<em>process</em>.

Company Mentioned

Mention Thumbnail

Coin Mentioned

Mention Thumbnail
featured image - How to run a successful Design Sprint
George Krasadakis HackerNoon profile picture

D_esign Sprints_ can generate remarkable output for your company — such as a backlog of impactful ideas, functional prototypes, learnings and key insights from customers along with real business opportunities.

Consider this situation: your company needs to solve a major real-world problem — you need a novel solution, better than any other offering available in the market; you could be aiming for a product, a component, a system, a service or a process.

In an ideal scenario, before making any investments, you would need the set of candidate solutions, prototyped and exposed to a controlled set of real users. This would enable enough signals and insights to make informed decisions and setup a better product development strategy.

To get there — from a problem to functional prototypes enriched with customer feedback — you can follow standard paths, for example you can consult the experts in your organization, assign work-streams to different teams, coordinate the work, schedule brainstorming meetings, and wait in the queue to get UI designs and then to develop prototypes — a lengthy process with several drawbacks, dependencies, issues and risks. Or, you can setup a powerful multidisciplinary team and ‘lock’ it in a room for a few days, with a clear goal: a shortlist of inexpensive, realistic prototypes of selected high-potential concepts, each enriched with feedback from real users.

A rapid innovation process outputting potential solutions to your problem and evidence from real users on how effective they are.

This intense ideation and prototyping process comes in several forms and variations — a popular one being the ‘Design Sprint’, which promises ‘Solutions to big problems in just five days’. It uses ‘design thinking’ principles and introduces several techniques, tools and rules.

The success factors

To get real value from a Design Sprint, you must emphasize on the right setup, preparation and readiness — or you may end up hosting an expensive multi-day brainstorming session outputting just noise. Having joined a large number of ‘ideation and prototyping’ sessions along with 10’s of formal ‘Design Sprints’, I would summarize the critical aspects and success factors in the following.

1. Define the problem statement

Don’t let the problem statement become your real problem! Most of the unsuccessful Design Sprints and prototyping sessions I have experienced so far, share this specific single point of failure: a poorly defined problem statement, which triggers time-consuming discussions, iterations and unnecessary regression — setting the entire process at risk. In contrast, the Design Sprints that started with clarity on the problem to be solved, moved on rapidly towards impressive solutions and prototypes.

The Design Sprints that started with clarity on the problem to be solved, moved on rapidly towards impressive solutions and prototypes.

Although the first day of the Design Sprint is usually about framing and re-framing the problem statement, I am convinced that having a good problem definition upfront is key for a successful outcome. You can always revise it and reset it as necessary during the first day, but a solid basis can make the difference. In any case, the team needs to be open to understand the problem and ready to consider different angles and unconventional approaches.

There are several templates and methods to help you construct a valid problem statement — in general you need to describe the current situation vs the ideal state and the related implications for the involved users.

2. Set up the right team

The synthesis of the team sets the foundation for the entire Design Sprint — you need diversity of thought, skills and perspectives along with expertise and creativeness — all combined in a small multidisciplinary team with the right culture: a team willing to share, collaborate, challenge assumptions, think big but also be pragmatic and purpose-driven.

The wrong dynamics in the team (for instance, members do not express their ideas, in fear of getting criticized by more senior members in the team) or a large team (add more than 6–7 people and you’ll get additional problems to solve) or the wrong mindset (people tend to protect ideas versus sharing, or believe that they know the right solution, upfront) could introduce serious risks to the process.

The members of the team must ‘forget’ about seniority, hierarchy and authority; they need to be open to new ideas, new perspectives and different views; they need to be ready to influence and get influenced; to minimize the impact of bias and work together towards a shared mission — a great solution to a challenging problem.

Physical space is also very important to allow the team to focus, express random thoughts and ideas, collaborate and quickly visualize concepts. You need a room with enough space, the right equipment and office supplies– such as writable walls, whiteboards and well, plenty of sticky notes.

3. Make sure the team is well-prepared

Design Sprints are demanding — fast and intense. The key to success, is to have a well-prepared team. Even if your dream team consists of domain experts and senior business leaders, they all have to put some extra effort to get prepared — so they fully understand the problem and its wider context, the technology, the competition and the relevant global trends. Make sure that you clearly communicate to the team, not only the context and the problem to be solved, but also the rules and the need to get prepared.

4. Focus on ideation

Assuming that a solid problem statement and the right preparation is there, the next most important element is ideation. While the Design Sprint process provides some tools to empower ideation, I would strongly recommend to [a] increase the time allocated to idea generation, sketching and pitching and [b] capture the ideas in digital format — with more detailed descriptions.

A backlog of ideas is a great asset — one of the most important outputs of the sprint and the key input to the prototyping phase. Ideas should not be left on sticky notes — even the non-selected ones could prove to be relevant and valuable in the future.

This is why you need to feed the ideas generated in the Sprint into a centralized ideation system and make them discoverable by the right audiences.

5. Get ready for ‘rapid prototyping’

Delivering realistic prototypes is a critical part of this process — since they will be used to capture user/ customer feedback. You don’t want your great concept to receive negative feedback due to a poor prototype implementation — that could mislead related decisions and undermine the overall value of the Design Sprint. Your team must be capable of real rapid prototyping — able to build realistic user experiences in just a couple of days or less.

Rapid Prototyping requires the right resources in the team along with a general technological readiness. For instance, to speed up the process you need to leverage any reusable software components you have, standardized datasets, artificial/ static data, UI elements, APIs, models and services. You will also need systems, tools and processes — for instance wireframing, software development environments and DevOps capabilities.

Availability of special equipment might be important, for example, if physical prototyping is involved a 3D printer might be of real value; or if you expect Augmented Reality prototypes, you will need access to related devices — along with any templates, APIs and documentation.

6. Find a great Facilitator

This is a key role — in fact, I see the facilitator as the real protagonist of the Design Sprint. The facilitator must maintain the right pace, direction, energy levels and interaction patterns, to lead the team towards a clear, shared goal: define and prototype a great, novel concept solving the problem for real users.

It is a difficult profile to find — you need somebody mastering the process itself, but also having deep understanding of the problem and the particular business context. The facilitator must be capable of ‘reading’ the characters in the room and take necessary action to make sure that all voices are heard and considered.

7. Capture everything

Design Sprints are typically very ‘noisy’ with tons of sticky notes, ideas and stories on the walls — all these, in-between discussions, arguments, decisions and random thoughts. And yes, this ‘controlled chaos’ is exciting, but unless you have a dedicated person responsible for taking (digital) notes, you will end up frustrated, trying to decode colorful sticky notes and ‘reverse-engineer’ random drawings. To make the most of the thoughts and ideas, you need to capture them in a modern way — so they are discoverable and potentially usable.

8. Find a Leader, not just a ‘decider’

I find the proposed decision-making process — with the super voting concept and the sticky votes on the sketches — oversimplified and very sensitive to team dynamics and the overall state of the team. Moreover, given the extra power, the decider must demonstrate deep understanding of the concepts, the ability to think strategically and communicate with clarity. You need a real leader there not — an ‘authority’ or ‘political’ person.

The facilitator and the team should feel free to challenge whatever decisions made by the decider, by asking for justification — the business or technical reasoning.

9. Measure Success

A design sprint is an expensive process — consider the associated direct and indirect costs of having x members full-time for z days. Thus, measuring the success of the Design Sprint itself is important. In the case of an ‘isolated’ sprint, success can be measured by processing direct feedback, outputs and mid-term outcomes — for example business opportunities and success stories linked with the deliverables of the Sprint.

If you are running successive Design Sprints, you need a framework to capture and quantify Sprint outputs and impact — a flow towards a centralized ideas and knowledge repository. This data store, should enable full tracking of the real business opportunities and financial gains associated with each of your Design Sprints — while specialized KPIs allow tracking the success of the overall innovation programme. The key question in this case is regarding the baseline to compare this ‘quantified innovation output’ against — to be covered in a forthcoming article.

D_esign Sprints_ can generate remarkable output for your company — such as a backlog of impactful ideas (also with IP opportunities), functional prototypes, learnings and key insights from customers along with real business opportunities. At the same time, assuming proper and frequent execution, Design Sprints can lead to significant cultural improvements towards the ‘innovation mode’.

Check also: How to lead innovation and drive change in engineering teams

Photo by Will H McMahan on Unsplash