Zach Baker

Storytelling for Programmers

So let's say you're a programmer trying to tell someone why the application you've made, or want to make, or your company made, is great.  So you come up with a simple one-line description.  But nobody really understands what's so great about it.   You try again, and come up with a list of the great features it has.  People appreciate that but still don't really see the whole picture.  What people really want is a story.

Creating a story really confuses lots of programmers. Either they have bad memories of creative writing or just have no clue how to do it well. But being able to tell someone a story about a product is an incredibly valuable way to communicate.  I have been fascinated by story structure but only came up with this particular perspective at Blizzard when I discovered that I would need to make regular and effective demos. So here's a practical perspective to telling a story in a demo or pitch for an app.

Start Simple

Creating a story is really more like finding one. It's a graph search problem. And just like graph problems, you're probably wasting your time if you start depth-first — like by coming up with fictional characters with motivations, family history, etc. This is not only brute force, but the deeper you go the farther away you get from what matters.  Don't start like this.

Instead, you want to find a starting point in the most essential use of the app.  Make a list and select the most fundamental task the app helps with if it's not totally obvious.

Create a Basic Structure

Here's an easy structure to start with:

• The Backstory: A general scenario, with basic insights and status quo
• The Need: A relatable need or interest users have
• Old and Busted: The "old" way of doing it and why it sucks (optional)
• New Hotness: The defining characteristics of your app's approach
• Slaying the Dragon: The essential use of the app you decided on already.
• The Secret Elixir: Give a peek behind the "magic" so the audience understands better
• The New User: How the user's new ability gives them more options or improves their life

This is what we're going to start with.  How do we flesh this out?

 Explore the story space with lists

You explore the solution space for your story by creating lists of options.  Again, resist the temptation to go depth-first in order to fully explore the options.  Brainstorm a list for each of these things first and don't restrain wild or humorous ideas because they can often provide flavor later on.

Evaluate Your Options

Now you pick out the stuff from those lists that best fit together. This is a pathfinding task - you're looking for a route through these options that gives the best overall story. You want to try to hit the highest-value pieces of information, interest or distinctiveness while keeping things coherent. If you have a lot of options, try to go for minimalism and just look for a couple of the best little bits to string together.

Expand Your Outline

Now you have an outline.  It needs to be expanded into something that you can actually walk through or demo.  What's missing is the details of the story.  You need to focus on three things - raising questions, sustaining momentum and providing insight. I certainly can't explain it as well as Ira Glass did in his legendary video, so go watch that.

Raising questions is a very basic and powerful thing.  Even if you can't come up with any "mysteries", you can take advantage of this.  Just pose things as questions. If you have data to present, say "But does it work? It turns out that..." Or start a description of something by saying "Other apps do this..." and raise the question of how you could possibly do things differently.

Sustaining momentum is a matter of not losing your listener and having things flow from one step to another.  If you have a demo, you should be constantly directing your user's attention from one thing to another, never opening the parenthesis for long before closing it again and moving on.  But in particular, don't stop and describe part of another story (i.e. what happens on another computer). Keep your audience's focus.

And finally, provide some insight - tell people what they're seeing, call out little details, and throw in some commentary.  Again, make a list at every stage of what you could note, pick the best things and don't get wrapped up in them for too long.

Iterations and Variations

Once you have the basic story, starting with the app's most essential use, then you can add some extra details.  This is basically following a path from one detail to another, touching on key features in a way that ties together narratively.

Start by making a list of things to add at the end, of extra options or features that make your users happy.  Then find a way to branch those off of the main demo. For most apps, this will still be a mostly breadth-first path through the app. There will be dependencies, places you can't go to first, and so you need to make those steps have interest as well. You can even mention other possibilities even if you don't take them: something like, "Now that I've uploaded my photos I can email the album to my group, I can tag faces or I can create a slideshow. Let's create a slideshow..."

You can also start over.  After you explain the basic use case, you can pull all the way back to look at another aspect.  Or you can even introduce smaller stories inside of your main structure.  Don't blow the audience's stack frames, though — they're smaller than you think when you're sitting in front of an outline.

Flavor

Now, if you do want to tell a longer story, like a screencast, you could have one or more pieces of storyline conflict, what screenwriters called "reversals." Have a story where your user:

• Sees something in the app and remembers there's something else they need to do first
• Makes a humorous mistake and the app is clever enough to point it out
• Finishes a task, then does something else the app suggests
• Sees something that changes their goal entirely and switches to that goal

Anything else which shows that your app is exerting some control of the storyline is a good thing, because it shows that the app is actively affecting the user's experience.

Then you can add some entertaining details.  Find some ways to adapt the funny, clever and cool ideas you've had to the presentation. You did keep all your funny ideas, right?

The Goal

Stories are fascinating because they embody knowledge, involve the listener in the search for knowledge, and teach knowledge.  You want to be excellent in all three of these areas, but the one that's best is teaching.  A great story is a model for knowledge in a way that nothing else is.  Use the power of story wisely.

Some Examples

Here are a pair of classic storytelling app demo/pitches from opposing camps. Check out their structure and see what you notice.