Deliver quickly, iterate fast, keep the user in the center of the process. This is what we aim when using an agile methodology as SCRUM.

Figure out the “Job to be done” and go from there up to the point when you can test something with the user, starting the feedback loop. Test, improve, test, improve, test, improve… deploy.

This process doesn’t seem that hard, does it?

At linkedcare as I explained in a previous post, we start by discussing the job to be done, include all the interested engineering team members in the discussion and letting the Product Management team moderate the discussion. From there we started designing the mockups (high fidelity), we tested them with the users and moved on up to the implementation.

It worked fine but fine wasn’t enough, we wanted better. We found that this process was lacking in a couple of ways:

While realising this shortcomings, we came across Google Ventures Design Sprint and at the same time we were on the verge of starting a new mega project inside our team, all the stars seemed to align…

The Design Sprint is a methodology that splits the process of going from a Job to be done up to user tested solutions in five steps during five days:

In each one of the phases there are suggested activities that should help you obtain clear goals.
(Thoughtbot put together an awesome repository with really detailed information on the design sprint, including suggested activities and their description, here)

While this structure seemed convincing, we struggled a bit to adopt it. There were a couple of problems we identified with this approach:

So we tweaked the design sprint a bit:

Team composition

With the main objective of reaching a feasible solution while starting with a rich enough diverge phase, we decided that a 5 member team was the right size.
Enough to diverge while keeping the discussions manageable.
Having different skill-sets hopefully would also help on the diverge phase.

The 3 Phases design Sprint

Due to the nature of our target audience we decided that high fidelity prototypes were needed, so we decided to remove the user testing phase from the design sprint.

an example storyboard at the end of the Converge phase

We have been using this process for a couple of months now. These are the first set of conclusions:

Positive:

So, we produce more and with better quality.

Negative:

As for the duration we just have to accommodate the fact that we need the 2 days minimum. The need to get the results across to all team members can be addressed by sharing the results of each sprint, in the form of the produced storyboards and by selecting tools that expose the mockups and testing results as they are being produced or collected.

Tools helping us implement the design sprint results

In general the design sprint works great for us and we advise it to everyone developing a product.

Are you using the design sprint?
Have experiences to share?
Feel free to reach me on twitter @alexmc

Indie Campers Director of Product & Tech/ Web addict

Indie Campers Director of Product & Tech/ Web addict