Design Sprints

The Apadmi Design Sprint is an intensive design activity intended to address a big or complex challenge, and propose, prototype and test a solution – all within four days.

It’s used to solve a specific problem or test out new ideas, and shows us how users really feel about the proposed approach before going through a full design and all the associated expense of building the actual product.

At Apadmi, we often do a design sprint as part of a larger project, where it can be helpful to focus on something specific – but it can also be offered as a standalone service, to help your team jump-start a product or address a particular challenge.

The Design Sprint team

For the design sprint to work, it’s vital to get the right people in the room to work with our team, and get them to clear their calendars to focus on the sprint. We understand this is a big commitment, but it’s worthwhile – it allows us to address a big business challenge and provide clarity on what to do next. 

The team needs to include any relevant domain or technical experts, a customer expert and crucially, a decision maker – the person that’s ultimately responsible for the product, and gets to make the tough calls if there are competing objectives. The good news though is that the decision maker can just attend the first two days if time is tight, as long as they can appoint a deputy who can attend for the whole sprint.

The anatomy of a design sprint

Together with Apadmi’s design and technical experts, the Design Sprint team will work on the problem following a set structure:

The first step is to get a shared understanding of the challenge we face, and this is done by discussing any user research and interviewing experts inside and outside the sprint team, looking at the problem from their different perspectives. Problems to solve are documented and prioritised, to identify the most important issues, which can be used to define a goal. We then map out the process and identify an area to focus on.

The next step is to produce some candidate solution concepts, which are whittled down to one or two to move forward. These ideas are fleshed out into a user flow that defines what to prototype and test with users.

Afterwards, we can easily see what worked and what didn’t – and we can easily update the prototype and re-test without going through a whole design sprint again.