Design Sprint, day three. Today we decide on what to prototype, and ultimately test. We’ve spent the previous days assembling a collage of features, ideas, sketches and assumptions. We now need to convert it into a storyboard for tomorrow.
For me this is one of the most daunting parts of the whole week. ‘Where do we start?’, ‘Do we have time?’, ‘How do we turn all this stuff into a storyboard?’ Here are some techniques I’ve used in the past, that might help conquer those fears.
Start at the end
Sometimes, after explaining the goal, you are met with silence. Despite working towards this task for days, it can be tough to know where to begin. The first screen is an obvious choice, but might not be best place to start. The first thing a user sees is super important; this adds extra pressure on us to sketch it out, potentially leading to a very cautious team.
If everyone is super stuck, try starting at the end. Thinking about the very last step first, the final thing the user will see – The goal – can sometimes start a conversation and get that first screen sketched out. Once that’s out of the way try asking: “Well, how did we get to this screen?”, get that ball rolling. You might find the pace picks up after that.
Use what you’ve got
Our first instinct may be to start sketching out steps from scratch. Before trying that, take a look at all the resources you have built up over the past three days. You’ll probably find you already have everything you need! Often you’ll have three-step-sketches and ideas that are so universally liked you can simply recycle them with a bit of modification.
Combine several artefacts together, tear, fold and join sticky notes and sheets into something resembling a storyboard screen. It might be a Frankensteins monster, but remember that the storyboard doesn’t need to be super neat, it only serves as a guide for tomorrow. As long as the team understands it, there is no need for a hand-drawn masterpiece. Any time saved by getting steps for ‘free’ allows the team to think harder about the rest of the storyboard.
Build it smart
Save yourself some time, start with a discussion about the elements that will likely appear on every page. Examples include nav bars, tab bars, and menus. Come to a consensus on the content, appearance, and format of these components – then sketch them on a separate sticky note. You can then declare that this component will be on every page. This requires a small amount of imagination, but will save time redrawing the same components constantly. Again, we’re creating a plan for tomorrow, not eye candy.
Bonus, this is great for non-technical team members. This may help them start thinking in a new way, one we would expect during the product build. Easy to digest chunks, that make great jobs to be done and user stories.
Hopefully these ideas and techniques help those struggling with design sprint storyboarding. As always get in touch with us if you need help setting up a sprint. In the meantime, Here are some other resources worth reading:
