Story-centered design: hacking your brain to think like a user
When I first started designing interactive products, it was a struggle. Small projects were fine. But when the interactions got more complex, I noticed that tools, team communication, and even my own thinking started breaking down. I see many startups facing these same problems today. So I wanted to share some of the ways that I’ve changed my design process over the years to handle the complexity of large products.
I used to design screens
Back in college, we were mostly designing posters, book covers, homepages, and lots of other single-screens. We used Adobe Illustrator or Photoshop, which both worked great for designing a single screen of content. Peer critiques were incredibly helpful because the critique itself was so similar to actually using the product: a general audience walked up to something they hadn’t seen before and looked at it for a few minutes. Seeing a poster in a design studio is a lot like seeing the same poster on the street.
When I moved to San Francisco and started designing apps, I kept working the same way: I designed a screen, or maybe a set of screens, and showed that set to the team. I call this way of working screen-centered design.
Screen-centered design doesn’t work for apps
Once you’re dealing with an app that has a dozen screens and hundreds of states, you can’t hold the whole product in your head like a poster. I noticed that our team was emailing around individual screens, talking about individual screens, and naming all the screens just to keep track. But we weren’t paying any attention to how the screens and features fit together.
We were thinking of the product as a set of screens. But there’s a problem with working this way: it’s not at all how people experience the product in real life. People use products in little flows that last anywhere from 30 seconds to a few minutes.
A user might first notice your product in a search result, browse around the product for a minute, and then leave. They might come back, sign up, and then leave again. They might open an email from the product, come back, make a purchase, and leave. Each of these little stories is a way that people actually experience your product.
A product is not a set of screens — it’s the stories those screens enable.
If your team is not paying attention to these stories, if you’re thinking about each screen individually, then your minds will be in a completely different place than the people who are actually using your product.
Story-centered design
Once I realized that the stories were the things we were actually designing, everything got easier. But I still had trouble staying focused on the stories — I kept finding myself thinking about individual screens! Argh.
So I began hacking my design process in different ways. I changed tools, deliverables, and how I worked with my team. Here are four of the best ways I’ve found to keep my mind focused on stories.
Hack 1: Storyboard before you sketch
I start designing by thinking of a story that’s critical to the product’s success. There are probably a dozen or so stories that make up the core of any product, but I just pick one to start. Then I build a storyboard — a lot like a comic strip. If I already have wireframes in mind, each frame of the storyboard can be a screen in the interface. Sometimes I get more abstract and each frame is a tiny chunk of interaction: anything the user reads or clicks on.
Okay, it’s not rocket science. But this discipline helps in a bunch of ways:
- Storyboards help me focus equally on all the screens we need to design — some of which can even be search engine snippets or emails.
- Storyboards force me to think about user goals because they show how work gets done in the product.
- Once we agree which stories are most important to the company, they can help prioritize all the features on a given screen.
- And storyboards really help me focus on the transitions between screens. A button has to make sense in the context of the screen it’s on, but it also needs to set up the user for understanding what they’ll see in the next screen.
But the best part is that I can reuse the same story over and over again, so it speeds up the rest of my work dramatically. When I’m showing UI designs to the team, I’ll need to show them a story. When it’s time for a user study, we can use the same story as the set of screens we show to users. And if we’re creating a press demo, or producing a product intro video — you guessed it — we’ll need a story.
Hack 2: Render full stories with Fireworks
I know most designers use Photoshop or Illustrator. And for visual design, there’s nothing better. But if we’re truly designing stories, we should be looking at high-fidelity comps of each screen the user will see. Those stories can get to be 20–30 screens long, and building those in Photoshop is tough — so most designers don’t bother, and we’re back to designing individual screens again. Luckily, Fireworks has some neat features that make it possible to stay story-centered:
- Built-in pages: You can build an entire story in a single file. The page-up/down keys make it easy to flip through the story and see exactly what the user will see.
- Symbols: If a header or icon appears on many pages, you can make it a symbol. Then if you need to change an icon right before a user test, you don’t have to modify 20 files individually.
- Find-and-replace: Did the team change the name of a feature halfway through the design process? No problem.
- High-fidelity: You can move from rough wireframes to good-looking comps in the same tool. Once the story is solid, you can bounce to Photoshop for the fine details.
Hack 3: Review stories on paper
When it’s time to review designs with the team, I almost never show individual screens. Instead, I’ll print out all the screens in a story, and lay them out on a long conference table or tape them to a wall.
This works so well because the team can get up close and see a single screen in full detail. They can take one step back, see the adjacent screens, and think about the transitions between screens. And they can step back even more to see the entire story, which helps keep everyone in agreement about the user goals and tasks that the screens need to support.
When I show work to other designers, I’ll skip the paper and just flip through screens on a computer — they’ll get it. But I find that the printing approach is incredibly helpful for working with engineers and PMs who don’t spend all day nerding out about interaction design like I do. Oh, and with paper you can draw notes directly on the designs and take them back to your desk to work on the next iteration.
Hack 4: Don’t send mockups. Record a screencast.
This is both the strangest and most helpful design deliverable that I’ve learned to make. I used to try explaining detailed interactions over email. I would attach a set of screens, and then struggle to explain how they all fit together. It was painful to write, and even less fun to read.
So I started recording videos of stories with ScreenFlow. Since each screen was already built in Fireworks, I’d just pretend to click where the user would click, flip to the next screen, and describe to the camera what’s happening. The first video I recorded took me a long time, but with practice I got over my stage fright, and it soon became quicker to record a video than write an email.
I am constantly amazed at how real the product can feel in one of these videos. And because they’re such a good simulation of what it’ll be like to use the finished product, it makes them a great tool for gathering feedback — it’s almost like critiquing a simple poster again.
These are just some of the ways that I’ve changed the way I work to keep myself and my teams focused on stories. I’m curious if other people have noticed the difference between screen-centered and story-centered design? What ways have you learned to keep the design process focused on the stories?
