A design sprint is a framework that facilitates rapid idea creation and solution testing. It's called a sprint since the whole process takes place in just a week. The idea is that you can test an idea at little expense before committing to a long and expensive development process. At the end of the week a prototype or two are tested on real people to get quick feedback.

During the week a whole cross-functional team will get together to create a solution. The teams typically consist of a facilitator, a designer, a developer, customer relations, marketing, a cost manager and a decision maker such as a C-suite exec or senior manager. What makes sprints successful is that they bring teams with differing agendas, and matching individual experience and insights, together to solve issues.

How should the five-day sprint break down?

Day 1 – Understand: Explore the problem, business goals, technological restraints and user needs. At the end of the day, map out how the flows might work

Day 2 – Diverge: Everyone should individually explore solutions to the problem using pen and paper

Day 3 – Decide: Review all ideas and vote on the best one

Day 4 – Prototype: Work up the chosen idea, focus on the usability and not the aesthetics

Day 5 – Validate: Test the prototype on real people, observe and learn from how they use it. If it completely fails, start the whole process again

The core strength of a sprint is that it saves time and money since tests happen so early in the process. Valuable data is received from people in order to make informed decisions. The process also means there is a better chance of creating successful and innovative solutions. It also gets the whole cross-functional team motivated and invested in the outcome. Another benefit is that it replaces the traditional conversational project kick off with a more detailed business understanding.

As useful as design sprints seem, they will not work for every situation. Avoid them if:

• There is no data to start with and you have to start with assumptions
• You already know the answer to the problem
• The problem is too small or too big to tackle in a week
• The team is too small, it needs to be between four and eight people
• It’s too expensive to put a team together for a whole week

Use a sprint when the project is at the very beginning to devise a solution with a shared vision, as well when you need to inject speed into the process, or the creative process has hit a roadblock. Sprints are not guaranteed to work, the week of work might need repeating if the users don't receive the solution well. However, the cost would be far greater if this realisation happened at the end of a traditional project that relies on validating a design when it is too costly or time-consuming to fix.