Continuing on from my previous article on the preparation and first day, this part touches on general tips and key takeaways from Tuesday to Friday. If you haven’t read it, I would recommend starting with the previous post:
Trailblazing Tuesday
After finishing up our many “Ask the Expert” sessions on Monday at around 6 pm, it made no sense to stick around to make key decisions on frazzled brains. We, therefore, started fresh on Tuesday with the voting step. This was also beneficial as one of our key stakeholders was out on Monday, therefore, having him involved in this stage on Tuesday made more sense.
Yes, we broke the rules of the Design Sprint format. It is not dogmatic, it is a guideline, and shit happens.
The demo effect
Wrapping up from the morning votes, we had everyone demo other apps which they were familiar with and loved, looking for ideas and inspirations from those that had come before us. This exercise helped to get the team comfortable talking about features and design and also proved fundamental in aligning the team on what worked and what didn’t. It was a solid way for everyone to form a baseline of standards and expectations.
Set the (drawing) bar
Some tasks during the week are going to be more uncomfortable for some. This is natural. On Tuesday, for example, a lot of time is spent sketching out features from other products and also generating our own ideas.
When running the demo of other apps, the designers would rotate and roughly sketch out the key features of each demo and name them for reference. The sketches were rough and helped to illustrate to the rest of the team what sort of level of fidelity we were going for. The rest of the team could then look on and think: “Well, if a real designer’s sketch can look that basic, maybe I could sketch something…”.
When it came to sketching and doing the “Crazy 8s” everyone jumped in without reserve. It was refreshing to see everyone generating like this — a practice that would not normally be part of their day.
Cumulative concepts
My favorite part of the day was probably watching ideas collectively grow. One person’s sketch or comment would trigger someone to jot down an idea. On seeing that idea it would inform another person’s direction. Seeing this naturally unfold, sketch after sketch, and witnessing the fruits of ideas that were harvested was the most inspiring part of the day.
Tuesday’s takeaway
I would have asked more explicitly up-front for everyone to come prepared with app inspiration. Some were just shown off the cuff, which was fine, but we could have benefited more if everyone had brought products that were more relevant to our profile or to the space in which we wanted to focus on.
Wittle-down Wednesday
Wednesday’s focus was to review the ideas generated on Tuesday, vote on the best ones with regard to the vision, and from there, storyboard a scenario that we would later prototype on Thursday.
With a shared understanding of the core user journey and with all the ideas shared, it was really easy to create the storyboard. We started by setting out milestones on a Post-it and beneath each would write down what we wanted to learn from that stage. This was an important step.
Breaking down the milestones, we placed a slip of paper with a mobile silhouette under each — leaving a map of paper to-dos. To make light work of the task ahead, each member of the sprint team could pick up a blank mobile screen and start sketching out that view in full detail. Once all of the steps were covered, the team was invited to “play” other versions on top of those already existing. This allowed us to drill deeper each time and explore variations as each one was refined that little bit more.
Having the whole team involved again was a great way to ensure that we were not limited to one or two people’s ideas, but we could get explorations from other members of the team.
Wednesday’s takeaway
Keep asking yourself what you want the prototype to test. What hypothesis are you trying to validate? What assumptions are you trying to validate? What risks are you testing out? Check back with the profile you are targeting, and the vision. Does the prototype align with this? Without this scrutiny, Friday’s tests will be less valuable.
Visualizing the storyboard was also a great way for the team to work. Designers could see which screens were ready to be picked up, and when done, could drop them back on the map with a Post-it to say that it was ready for review, before moving onto the next one. This kept the whole room up to date as we all worked at pace throughout the day.
Rock-out Thursday
Throughout the week, we played music in the background to avoid awkward silences and trigger inspiration. As Thursday came around, our mobile Engineers, Froi and Ivan, began talking about a new band that they had been listening to. Upon hearing them, Greta Van Fleet became the backdrop to our prototyping day.
I won’t lie, it was intense — but it was fun. Guillem, one of our Product Designers, and I began rocking out as we picked up sketch after sketch turning them into a clickable prototype.
In tandem Damir, our Product Manager for Mobile, and Nadine, our Product Manager for Trip Support, would check our screens as they were uploaded and stitch them together using MarvelApp. In this way, we could advance quickly, moving through screens and encapsulating feedback. We ended the day with a solid prototype in which we had a clear idea of what needed to be tested.
Thursday takeaway
Start the day with a solid understanding of each step of the storyboard, what the details are for each screen, and what you are testing for. You can then look at the day and chunk up the number of screens into time slots, allowing a buffer for corrections, stitching, and initial testing.
To that end, we had also invited some power travelers from the company to come up around 4 pm to run through what we had. If there were any simple oversights, we would rather catch them internally vs in the hands of our customers. This also got some people in the room comfortable with the devices, the prototype, and asking questions. Kind of like a dry run for the following day.
As a final tip: when creating your prototype you will likely try and optimize for a standard path. I often create a “magic hot spot” somewhere discreet on the prototype that can take you back to a splash screen or to the start, should you need to jump back and check parts of the app. We used this as a hack to jump between our 3 scenarios.
Find-out Friday
This was it. This was the day when we would find out if our ideas would be a success or a flop. Ultimately you want a mix. Too much praise and you learn nothing. Too much criticism and you have missed the mark. I feel like we landed in that sweet spot. The core of the design and the experience matched and exceeded users’ expectations in some ways, but we also managed to capture some highly valuable feedback that will inform the next iteration.
Nadine was in charge of reaching out to our customers ahead of the day, making sure that we had a tight schedule. We had given ourselves 30 mins with each candidate with some time between visits. Some were done on-site with local customers and others were done remotely from our office.
As one person was running the interview another member of the team would take notes using Lookback — which helpfully timestamps each comment so that you can easily jump back and reference that point of the session.
We had three scenarios that we tested to learn from the biggest questions that we had and we were meticulous with our timing to ensure that we could cover each of the scenarios.
Friday takeaways
We were lucky that the day went to plan, but you can never over-prepare for this day. If the internet is slow or you have issues connecting, make sure you have offline versions of your prototype and use something like Quicktime to record the device and the user. It’s also worth rehearsing the format of the interviews with colleagues before speaking with customers, just to get comfortable with timing and flow.
And, finally, try and make your prototype as real as possible. Start with some priming dialog that will put the user in the mindset that will prepare them for what’s to come. In our case, we would ask about their most recent travels and see if we could anchor anything to that as a reference so that it would feel more natural to them. Unfortunately, we ran out of time but another nice touch is trying to use “real” user data in your prototype. Things like having their name, company, or typical travel patterns shown in the prototype will immediately connect them more with what you are showing them. The whole experience will feel more real, which will result in more accurate feedback.
Everyday tips
Lunch
Every day most of the team would lunch together. This was a nice way for conversations to flow in a more informal setting or just allow us to get to know each other personally. It gave us a chance to review how the morning had went and course-correct anything in the afternoon.
Keep asking “how are we doing?”
I would regularly check in with the core team that I was working with throughout the sprint, inviting feedback and making sure that everyone was getting value out of these days. Failing to do this check-in just makes this a very expensive, irrelevant, week-long meeting. It also allows you to address any issues as they arise instead of finding out after the fact that things could have been done better.