Just like any intense exercise, the sprint also requires some warm-up before starting. We recommend doing the following before the sprint:
Before we choose the right problems and start hunting for exciting solutions, it’s important that the team understands the problem space, the competition that exists within that space and the customers for whom we want to find solutions.
Solving the right problems needs the right set of people in the right roles. A team of 6-8 people with clearly defined roles and responsibilities can make a huge difference to the outcome of the sprint.
It’s best to be prepared with a list of users who can participate in the user study on the final day of the sprint.
To make a mentally taxing exercise like the sprint enjoyable, it’s a good idea to invest some time in procuring the right space and materials for it. Try to get a large room with plenty of natural light and space for white-boarding. Get lots of whiteboard markers, post-its, papers, sharpies, sketch pens, masking tape etc.
Solutions are meaningful only when they solve very well thought out problems. On day 1 we narrow down on the most pressing business problems worth solving.
The pitch brings everyone in the team on the same page. In 2 minute or less, the product owner defines the 3-5 year vision for the product. Who is it for? What does it solve? What is the business opportunity?
In the next 20 minutes, the product owner then defines all foreseeable problems in the next 6 months, to ensure the team is on the right path to accomplish the mission.
Next, we create a journey map with a focus on the touch-points where the user might come in contact with the product or service. We define key stages of interaction in the journey along with activities performed by the user in each stage. Additional actors or service layers that contribute to the activities are also mapped out. A graph reflecting the emotions of the user at every touchpoint is also baked in to the map.
For the pitch to become a reality, it’s likely that a lot of problems will have to be addressed. In the next hour, every member of the team reviews the shared research and records all the problems they can think of in the form of “How Might We” questions. A good “How Might We” question should neither be too broad nor too narrow. The idea, is to sharply articulate specific problems without hinting at potential solutions.
After going through the existing research, the team calls in experts (think people from sales, marketing, customer support etc) and interviews them, while the team continues to jot down more “How Might We” questions.
The team captures all relevant problems in one single board by going through a series of simple steps.
Cluster and reframe: The team clusters similar “How Might We” questions under a few themes, removes duplicates and improves their articulation. This exercise should not only reduce the number of questions, but also improve their quality.
Define success criteria: For each reframed “How Might We” question, the team defines a success criterion. For example, the success of the solution for - “How might we make the user interested in the product description?” can be measured by tracking the time she spends on the product details page during the user study. Questions that might lead to unmeasurable solutions should be dropped at this stage.
Pick winners: The team decides on the number of problems they want to tackle in the sprint and cast their individual votes accordingly. The top 2-3 problems which receive the maximum number of votes are selected. These are the problems that the team tries solving in the next 4 days.
At the end of the day’s work, everyone is asked to come prepared the next day with a few examples of solutions that address the chosen problems. It’s a good idea to look for inspiration outside the direct problem space and see how other industries have solved similar problems.
Building a detailed solution requires a ton of ideas to work with. On day 2 we use divergent thinking to create tens (think 60-80) ideas that go on to define our solution.
Day 2 starts with a presentation of the home work from Day 1. Everyone gets 5 minutes to present their favourite solutions, while others capture what they like about those solutions on post-its. By the end of lightning demos, you should have a wall full of inspiring ideas to help you through the next steps.
For the next 20 minutes, everyone goes around the room individually, making notes of everything that might help them come up with ideas to solve the selected problems.
Next, everyone takes 20 minutes to privately jot down some rough ideas and then circle the most promising ones.
Crazy 8s is a great exercise for creative muscles. It helps you ideate rapidly without worrying too much about the quality of your ideas. Everyone folds a sheet of paper into 8 frames and tries to come up with 8 solutions for a problem in 8 minutes. It’s a good idea to repeat this exercise for all your selected problems, but limit it to a maximum of 4 rounds so that you can finish in about half an hour.
After you have a brain dump of all your ideas in front of you, take the next hour to individually pick your best ideas and stitch them together in the form of a complete solution. It’s ok to skip obvious parts of the service and focus only on the juicy bits. You need not put a ton of effort in making your sketch beautiful, but try to ensure it’s legible so that it can make a case for itself without any verbal explanation.
To build a realistic prototype, you need a very solid detailed solution sketch on paper. On day 3 we select our best ideas and stitch them into one single narrative.
We start day 3 by putting up everyone’s solution sketches on the wall. After a few minutes of going around and observing each sketch, everyone puts a dot sticker next to their favourite ideas. Each individual gets to cast 5-7 votes overall. This should give you a heat map of the team’s favourite ideas.
Next, everyone takes a minute to explain their votes, and a minute seconds to raise objections if any. After a round robin of critiques, the artist of the voted idea takes a minute to talk about anything that was misunderstood or needs further explanation.
Next, the team members cast one or two votes (depending on the number of ideas) to pick their absolute favourites. These are the ideas that might make it to the final prototype after some refinement.
If the final votes were cast on ideas that are very similar, we cluster them together. If the votes were casted on ideas that conflict with each other, the decider chooses the most promising solution.
It’s now time to take the winning ideas and stitch them into a storyboard. Find a whiteboard, and divide it into 16-20 frames. Start with an opening scene and draw out how the user discovers your product in the first frame. Continue drawing in the next steps one frame at a time till you reach the final step of the selected part of your user journey.
To test our solution with real users, we need a prototype that looks and feels real. We spend all of day 4 on building a high fidelity interactive prototype in which information flows seamlessly from one screen to another, just like it would in real software.
To build a high fidelity prototype that functions like real software, no single tool is perfect. It’s good practice to use a combination of different tools instead. As of this writing, we recommend:
Sketch: For making static screens
Invision/Marvel: For quickly connecting a large number of static screens into a click through prototype
Framer: For building prototypes with animations and live data
Building a prototype isn’t a one-man job. To make it as real as possible in just a day, you will have to work together as a team with clear roles and responsibilities. You will need:
A writer: Responsible for all the copy for the prototype
An asset collector: Responsible for collecting all the assets that go into the prototype
A designer: Responsible for taking the content, designing screens and stitching them together
An interviewer: Responsible for writing a script for the user study and conducting it.
After you’ve built the prototype, leave room for a dry run before the actual user test. The interviewer uses the prototype to conduct a mock user test with a team member. The mock test is likely to surface some issues with the prototype or the script. Fix those issues and get ready for judgement day!
During the entire sprint, we work towards a whole day of tests which get us feedback on our solution from real users. This happens on day 5 - the final day of the sprint.
A good user study requires a good setup. You will need 2 rooms – one for the actual interviews, and another for the team to watch a livestream of the interviews. Make sure to also save a recording of the screen and audio for synthesis later on.
It’s time for the moment for which you’ve been working your butts off the whole week. Begin every interview by welcoming the interviewee and easing them into a light conversation and then slowly transition into questions about the product or service you are about to test. Next, introduce the user to the prototype and explain how it might have limited functionality. Don’t forget to add that the designer of the prototype is not present, and ask the user to think out loud without fear of hurting any feelings. Finally, take the user through the prototype by asking her to do a series of tasks and carefully observe the points of friction. It’s ok to deviate a bit from the script, but don’t do it too often and be careful of asking leading questions. Close the interview with a quick debrief that gives the user a chance to voice her final thoughts about the prototype.
In the observation room, find a whiteboard (or a shared spreadsheet) and divide it into 3 columns with titles:
What worked very well and needs little or no improvement?
What worked reasonably well and needs more work?
What did not work and might need a lot of work?
Alongside each interview, everyone takes notes and at the end of the interview adds them to the relevant column. Continue this exercise for all the 5 interviews, and then clean up the notes by removing duplicates.