Hacking the Design Sprint

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:

• Not enough detail was surfacing from the discussion phase, mostly due to lack of structure;
• A lot of iterations were needed in the high fidelity mockup phase even before putting the mockups in front of the users, this was mostly a consequence of the previous point;
• The knowledge gathered in the process wasn't spreading far enough inside the team, although almost everyone participated in the discussion or at least read through it, after that, all of the iteration was closed between the members of the team directly working on the features.

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:

1. Understand - In this phase the objective is to learn the most possible about the problem we are trying to find solutions for, clearing out knowledge gaps or wrong assumptions;
2. Diverge - in the Diverge phase we aim to find possible solutions for the problems at hand, trying to discuss as many different solutions as possible;
3. Converge - As the name implies, the objective here is to start from the divergent solutions and finish with the single best solution;
4. Prototype - In the prototype step, the team will make user testable prototypes of the solution we got from the converge phase;
5. Validate - Test the solution with potential users using the prototypes made.

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:

• We are a 14 member engineering team and a 2 member product team… that is a lot of people to have on a design sprint;
• We were going to tackle a pretty big project and splitting it in 5 days design sprints would make it pass our wished release date;
• Our target user base is really specific and has a couple of attributes that make user testing really challenging:
  - They have limited available time, this limits the number of iterations we can have with each one;
  -They are not tech savvy, making it extremely hard to test using low fidelity prototypes;
  -They are in a different continent (we are based in Portugal and our target market is the USA).

So we tweaked the design sprint a bit:

• We limited each Design Sprint to five people: 2 designers; 2 developers and the product owner (one of the product management team members);
• We removed the validation phase;
• We crunch everything else from 4 days to 1,5 days…

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.

1. Understand- we kept the understand phase while aiming to reduce it from one day to half a day in duration. We tried to do this by trying to invest a bit more in sprint preparation and eliminating some of the activities.
   Our understand phase schedule looks like this:
   - Intro (30 min);
   - Problem Statement (15 min);
   - Pitch Practice (5 min);
   - Who, What, When Where (30 min);
   - Open Card Sorting (25 min);
   - Needs, Must Haves, Desires (30 min);
   - Critical Path (15 min).
2. Diverge- As in the previous phase we reduced the length from a full day to half a day.
   The diverge phase starts from the critical path of the understand, for each step in the path this is our activities schedule:
   - Mind mapping (10 min);
   - Crazy Eight (5 min);
   - Storyboard (20 min);
   - Silent Critique (5 min);
   - Group Critique (15 min)
3. Converge- One more time we aimed to reduce the converge from one full day to half a day in length. This is our activity schedule:
   - Review Assumptions (30 min);
   - Review Back Burner (15 min);
   - Identify storyboard conflicts (30 min — for each critical path step)
   - Compose the final storyboard (30 min — for each critical path step)

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:

• The speed at which we are now producing testable high fidelity mockups (the first step after ending a design sprint) is unbelievable.
  We believe this is mostly due to the improved context we are now able to pass to the designers, in the form of the storyboards and in the form of the information they gather being present trough the design sprint.
• There is no need for internal iteration on the mockups before going to the user tests.
  The mockups are reviewed by the product team before being tested and before they almost everytime needed some type of corrections. This need just vanished.

So, we produce more and with better quality.

Negative:

• The 1,5 days target is almost impossible.
  This is mostly due to the converge phase we almost never manage to keep it under a day. Building storyboards for each step and discussing them takes time…
• Rotating the team members between design sprints brings an overhead for each sprint. As most of the sprints use knowledge collected in the previous ones, this knowledge needs to be passed to the new team members and that takes a big chunk of the Understand phase.

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

• Invision (http://www.invisionapp.com/)
  Using Invison, tightly integrated with the tool of choice for our design team, Sketch, the engineering team has a near real time view of the mockups evolution while they are being worked on.
• Lookback (https://lookback.io/)
  With lookback we are able to do remote user testing sharing the invision prototypes and recording audio, screen and video of the user while testing.
  It’s still in beta but is awesome!

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