Hacking the Design Sprint

  • 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.
  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.
  • 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).
  • 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

The 3 Phases 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
  • 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.
  • 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.

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!




Indie Campers Director of Product & Tech/ Web addict

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Alexandre Carvalho

Alexandre Carvalho

Indie Campers Director of Product & Tech/ Web addict

More from Medium

Prepare & run your product development: User Stories Backlog

Design Sprints and Agile Scrum

Enterprise UX — Shred #25

Service design for smarter planning — The importance of putting the user first