Practicalist

(I’m going to build out the ideas for the talk I’m giving in April here. This post will be incomplete and changing.) (tl;dr: There are many stories in design, first the stories a team tells each other about what they want to make, then the stories describing what to make, then the story an audience or users experience. Stories are best created as brutally simple pieces of of writing. Designers are in a great position to make stories to help a team and audience communicate, and make good things.) Creating an experience is closely tied to telling a good story. The pervasive nature of “experience design” often tends towards an abstract, complex, interconnected plan. But what’s needed instead is really just a compelling, simple story. A story that connects with a few emotional needs can be turned into many things; lunchtime conversation, a book, a product, a system, a service. When a person or a team sets out to build something, staying focused on what’s important is hard. Stories are naturally social, and tend towards simplicity. Keeping a story in mind is a very useful tool for making things good. Sometimes people spend time on exercises for team alignment, like mission/strategy/objectives. Or they come up with a tagline for a product. A story is neither one of these things. It’s not messaging, it is the thing itself. A story can help with other things, but it’s more essential. Many people have done wonderful work on story-telling. It’s an old, durable thing people do. Aristotle nailed it a long time ago when he said that telling a meaningful story is comprised of “events that come upon us by surprise; and the effect is heightened when, at the same time, they follow as cause and effect. The …wonder will then be greater than if they happened of themselves or by accident; for even coincidences are most striking when they have an air of design.” Ernest Hemmingway, writing about writing his stories, says that his work was to set down “the sequence of motion and fact which made the emotion.” Kevin Cheng, who has been working as an interaction designer for many years, fully exploits the abilities of a clear story in his designs. He even wrote a great book about it, See What I Mean. Some other places you’ll find great story techniques:

• Common Craft makes beautiful stories that focus on explaining products
• TED Talks follow a shared structure that tells a personal story about an idea
• Storyboarding is a tool that predates digital design entirely. It focuses on design as preparation, as in films shot classically. But as a technique for quickly capturing a narrative, it works well.
• Storytelling for User Experience (Whitney Quesenbery & Kevin Brooks)
• “Notes on Design Practice: Stories and Prototypes as Catalysts for Communication,” Tom Erickson, in Scenario-Based Design: Envisioning Work and Technology in System Development, edited by John Carroll
• Usability Engineering: Scenario-Based Development of Human Computer Interaction, John Carroll and Mary Beth Rosson
• Software for Use by Larry Constantine & Lucy Lockwood
• User and Task Analysis for Interface Design, JoAnn Hackos and Janice (Ginny) Redish
• AIGA, An Ethnography Primer

So, stories are great. But is story just another deliverable? Another abstraction that designers do and hand over to others? It’s useful in that way, but I would say no. The world is littered with the work of smart and talented designers that doesn’t work to make the end product good. The app development company 37Signals eschews design deliverables of all kinds. They say, for example, “We don’t use personas. We use ourselves.” In an interview about process, Ryan Singer is asked about various UX deliverables, and says that “all that stuff is terrible.” I agree with Ryan, but think he misses the point of these documents. They aren’t there so much to take the place of connecting with the audience/users of a product as they are to help a team have a shared understanding. It’s great that 37Signals has none of these problems (they are a small group that’s used to working together, and they design things for their own use), but their experience is the exception not the rule. Most of us live in a world where we have to communicate and work with other skilled people, and connect what our team does to an audience or users’ needs, and stories are useful for that. The process of building a shared understanding (between people making something, and between them and the rest of the world), is making a story. It is as much about figuring out how to work with a small group as it is designing something. Even when a team is just one person, who that person is and why they make what they make is fundamental (thus my fascination with author photos on books). Why a team comes together, what their roles are, and how committed they are to each other has as much to do with the story of making something as any fancy design. So the first story to work on is the story of the team. Then, that story has to be connected to the story that people (the audience, the users) will see. Designers are in a uniquely good place to tell these stories, and connect them. So what does that actually mean in practice? I think it means doing less deliverable, and more editing. It means writing; short, clear writing, not diagrams or other visuals. Some dictums from a book about screenwriting (Writing in Pictures, Joseph McBride) are helpful:

• “Every story makes a promise for an audience”
• “Don’t tell us what people are thinking or feeling or remembering unless you can show it. Don’t write what we can’t see or hear.”
• “Remove everything you can: ruthlessly focus on clarity.”
• “Write a simple arc. Don’t write an epic.”

All this is to say that stories (whether they are told in an instant-message window, a handwritten note, a sketch on a whiteboard, or an elaborate powerpoint presentation) should be the absolute minimum needed to communicate an idea (but no less). Examples of stories for a team Examples of stories for a piece or product Examples of stories for an audience or users