A Storyboard For What Users See & Do
I was recently asked for more detail on a certain user flow, but since it was a secondary use case we hadn’t budgeted for detailed renderings. Good storyboards stand on their own and there just wasn’t time for that.
Instead, I combined Ryan Singer’s see/do technique with a little bit of Interactive Sketching Notation. What the user sees is shown or described on top, and what they do is on the bottom. Their actions obviously affect what happens next and where they navigate.
You can also use this with non-linear flows; I could have drawn out additional frames for package contents and terms and linked to them if they were important enough to see.
No More Cheesy Scenarios
Since anyone can understand a story, designers often use scenarios to explain how a user would complete a task or accomplish a goal in a given system. These short stories can be written in words, and are sometimes paired with quick sketches to make a storyboard.
I happened to be working through a lot of design scenarios recently, and these guidelines from Dan Saffer have proven extremely valuable:
Remove all adverbs
Remove all interior monologue
Remove any adjectives that don’t relate to system feedback
Here’s what happens when you don’t do that:
Susan stayed up late working on her personal newsletter. My subscribers are counting on my insights and links! she fretted.
— Dan Saffer (@odannyboy) April 29, 2014
These elements make the story sound cheesy, which effectively makes it seem less truthful. Your audience will smell the B.S. and your credibility as the storyteller will be undermined. The perceived quality of the design idea also goes down.
Few of us are great writers; I’ve found it surprisingly easy to fall into that familiar rhythm. But unless you want to be lumped in with the ShamWow—which has “sham” right in the name—don’t write a pitch that sounds like a late-night infomercial.
I remember one story that felt dry when I first removed the cheese, but the audience didn’t notice. And even the driest story about a user accomplishing a task will serve you better than something reminiscent of Saved by the Bell.
Once the cheese is gone, run through your story a few times with a colleague to smoke out the “plot holes.” You’ve been focusing on the design idea itself, not the presentation, and there will probably be one or two places where the audience feels like you jumped from Point A to Point C. The practice run is a simple idea, but it has a great bang for your buck.
After you’ve mastered the basics, Dan suggests the following:
Add problems and resolutions
Remove anything that sounds like ad copy
Vary user behavior
This is great advice, though instead of writing more/deeper scenarios, I usually put the time into storyboarding a rock-solid happy path scenario that I’m 100% sure my audience will understand. People can’t get on board with a plan they don’t understand, and you are presenting new ideas they may not “get” right away. Adding visuals is a great way to build understanding, and trading words for pictures makes it less likely you’ll write cheesy copy.
Thanks to Dan Saffer, Kevin Cheng and Dan Roam for improving my stories.