A product designer’s tips to be effective and insightful in a Design Sprint! (2/2)

Monday: "Understanding

This is the day with the heaviest mental load – there is a lot of information to process that we will later use throughout the Sprint.

At SQLI, we hold a problem-framing workshop a few days ahead of the Sprint. This first meeting is an opportunity for sprinters to share any information we have ahead of time and to write up a first draft of the problem at hand. This is when the designer clears the fog they have just walked into!

Asking questions to understand the background and the key issue

When we are unfamiliar with the topic, we have a very short timeframe to understand the context, surrounding issues and especially the terminology. We should not hesitate to ask any questions we may have and ask for terms to be explained so we can ask the relevant questions during the workshops and offer appropriate solutions down the road.

Picking up on keywords

A good portion of the first day is spent conducting interviews of experts who are not participating in the Sprint, but who we believe have information they can give the sprinters that will help them better understand users’ needs, business stakes and the scope of possibility (legislation, technical constraints, etc.), which will give the sprinters food for thought and make them more likely to offer relevant solutions as they execute their mission.

All of the sprinters must take notes during these interviews. It is not a good idea to trust your short-term memory in this context because of the sheer volume of information we have to process on Monday. I recommend that you take note of words that frequently come up in conversations with experts that use what you feel like are keywords to you. They will be useful to build the “How might we?” and the “Jobs to be done” challenges.

HMW: “How might we?” questions reframe problems as opportunities in order to foster ideation.

JTBD, or “Jobs to be done”, is a theory that aims at drafting a clear statement of the intrinsic motivations of users (on an emotional, social or functional level), the expected results (job) and the difficulties they are encountering when trying to reach them^[1]. Jake Knapp does not use this theory at all, but at SQLI we have built it into our process, because we agree with Clay when he says that “Innovation becomes much more predictable – and far more profitable – when it begins with a deep understanding of the job the customer is trying to get done.”^[2]

Remember that the interface to design must, of course, be ergonomic

The terms “ergonomic”, “fluid” and “pleasant” only yield cookie-cutter formulations that could apply to any design project.

Example: “HMW imagine a more fluid experience?” “HMW design an ergonomic interface?” “HMW make users have a pleasant experience?”

To avoid generating irrelevant HMWs, do not hesitate to remind your sprint team that the designer’s fundamental role is to design an ergonomic, fluid and pleasant experience! You can simply suggest to the facilitator to add an instruction to forbid the use of these words when writing HMWs. This will also encourage participants to be more specific in writing challenge statements and to provide much more inspiring HMWs.

Example: “How might we help teachers more effectively prepare their lectures?” “How might we reassure users on matters of hygiene and safety?” “How might we reassure users about the use of their personal data?”

Tuesday: "sketching"

Tuesday is the busiest day in terms of individual work. Each sprinter must imagine and draw their solution based on all of the information they have collected thus far. As a designer, this is the time to bring all the rich experience we have acquired in past projects and intelligence to the table to help the team and the sprint, and sometimes even to rescue the ideation phase.

Generate suggestions based on different references 

Sprinters sometimes have trouble moving away from their usual work tools and getting out of their comfort zone to do an interesting benchmark. I recommend that you offer visual references from outside of the field of the product being showcased, this will stimulate the team’ s creativity and, with a bit of luck, help them imagine more varied and innovative solutions when sketching in the afternoon!

Preparing an intelligence file ahead of time

If you have trouble remembering everything you saw in the tools, you can prepare a file before your sprint with screenshots of the various tools. This way, during benchmarking, you can go through them and only suggest the most relevant ones for the specific context. You can lean on services you use on a daily basis for the benchmark – design, video streaming, Google services, online stores, social media, task managers, banks, music, health, booking services and instant messaging. You will always find an idea that can be repurposed as a solution in the sprint!

Wednesday: "decisions/stroyboard"

This is the day where your team will converge on a solution and start to flesh it out.

 

Bringing the group together

You will need to work with the facilitator to focus the group on designing the storyboard in order to avoid changing the concept and the test journey that has been chosen. It will be very tempting to change a lot of aspects of it, but you need to keep the spirit of the sprint in mind – it does not have to be flawless!

Storyboard on MIRO

When working remotely, Miro or Mural can be used for the collaborative workshops in your Design Sprint. The sprinters can quickly discuss and iterate surrounding the storyboard, directly in the window in their web browser. This gives everyone a global view of the content that has been defined and the workload.

As soon as the concept and the test journey have been agreed upon, I work on creating a brief summary of the chosen storyboard on Miro, using the items from the “wireframe library”. This gives us a clean, comfortable foundation for discussions with the other sprinters. Personally, I try to spend less than an hour on this. For more agility, I get the components I will need out ahead of time. You can always practice before the sprint to become familiar with the tool you will choose.

Then, with the sprinters and the facilitator, we get into the nitty-gritty of the storyboard to define the type of content that will be added to the screens. By “type of content”, I mean for instance “Date” or “Name of transportation” – it will then be up to the sprinters to decide whether to use 03/16/2021 or 03/17/2021 depending on the test scenarios. It’s also possible to take a wider view, such as “in this inset, we need customer information” – it will then be up to the sprinters to define what information is relevant and should be displayed for the user.

 

Be careful with test scenarios

Once the test journey has been decided on, test scenarios need to be defined. It can take some time for sprinters to agree on which scenarios should be tested and lose sight of how much work it will take to design it down the road.

Add sticky notes for the copy to provide

Do not hesitate to add sticky notes in every location where copy needs to be written in order to get a ballpark of how much content needs to be produced. This will help sprinters divide it among themselves (with help from the facilitator) in order to make progress effectively. The designer should not waste any time thinking about content on Thursday – they need to be able to count on the other sprinters to provide the content.

Define the best tool to prototype

Only once we have assessed what kind of prototype needs to be made based on the constraints we will go over can we select the tool for the job. Whatever the case may be, it’s important to pick a tool that we master: this is not a good time to try out a new tool!

Create a first draft prototype

At the end of the day, I start quickly creating the storyboard in my prototyping software. This is because, even if we may feel like we left no question unanswered after storyboarding, when we start actually building the prototype, new questions will be raised that would have been hard to predict earlier on in the process. These questions can quickly be resolved with the team on Thursday morning.

Thursday: "prototyping"

Thursday is the designer’s time to shine! By getting ready for this day with a few tricks of the trade, you can avoid falling into common traps of prototyping.

Progress reports/communication process

Ahead of time, define with the facilitator what the communication process will be for the day in order to avoid needless interruptions. The designer must have optimal working conditions – their concentration and productivity must be protected. Over the course of the day, 2 or 3 short meetings can be held to give a progress report on the design to the teams and make note of any changes needed.

Personally, when working remotely, I essentially base my work on the board, which is continually refreshed with content from the sprinters and remain fully focused on my own. If I am missing anything, I write it on a sticky note on the Miro board, and if it’s urgent, I can ask the sprinters through videoconferencing.

Focus on UX

This is probably the most important thing to keep top of mind. Your goal is to create a medium to test the value proposition. This is not a good time to reinvent the wheel. It is not possible to deliver a “pixel-perfect” project or to rework something you aren’t entirely pleased with multiple times. The UI is only there to serve UX.

Prioritize screens

Discuss with the facilitator and the decision maker to define which screens are “mandatory” and which are “nice to have”. Your goal is to focus the team’s work on the right aspect of the project and to ensure the sprint will be completed.

Turn down large changes

Some sprinters might want to go back and change aspects of prototyping. It’s important to know how to assess cost/value/risk for each of these requests and to say no to avoid compromising the prototype and the sprint itself! One good way of deciding whether it is worth it is to ask yourself: “Do we need to test this feature to answer the Sprint Questions?” If the answer is “no”, you will easily be able to explain that this can be done after the Sprint, if needed.

Take breaks

This one seems obvious, but in the heat of action on Thursday, it can be easy to forget to take a break. When the brain gets overheated, it is harder to make progress and mistakes are more likely to happen.

Use different-colored sticky notes for content

I color code my sticky notes for copy to supply in order to have and provide a global view of progress and what is still missing.

Keep the User Researcher in mind

At SQLI, the senior user researcher works on Thursday to ensure objectivity is maintained and that the exercise remains under control. They will need to become familiar with the topic of the sprint and the prototype in order to prepare the interview guide and evaluation grid by Friday morning. I try to quickly have a first draft of all of the prototype’s screens so that the user researcher has material to work with:

Friday: "test day"

Share any needed improvements with the entire team

At the end of the sprint, after user tests, we like to take some time for everyone to give their impressions, to summarize the main discoveries and identify the high-priority actions after the sprint.  As designers, we can see things that other participants may not have noticed, and we should not refrain from sharing our observations. This way, we all complete the sprint with the same information.

Every design sprint is an enriching, worthwhile adventure. I personally love being challenged and learning new things – this makes design sprints the perfect playground! I hope these tips will help you get ready to take part in a Design Sprint – or even encourage you to do one in the first place! If you have any questions, don’t hesitate to ask them in the comments section.

 

^[1] Theory espoused by Tony Ulwic (inventor of Outcome Driven Innovation)

^[2] Book: Competing against luck. To learn more about JTBDs, watch this excellent video by Clay Christensen: https://www.youtube.com/watch?v=kGuSM3yUxik