Published: Dec 07, 2010
This article is an excerpt from a chapter in Dan's Book, Communicating Design Web Site Documentation for Design and Planning.
The things that make for a powerful diagram—legibility, relevance, actionability—are the same things that make for a good deliverable. Like diagrams, simplicity in deliverables is paramount.
A good deliverable tells a story, and telling a good story is hard. (Seriously, turn on your television in prime time any night of the week and you're more likely to hit bad story-telling than good.) So, let's take a good look at what this means in the context of a design project.
Good stories have a theme, an essence, a "what this story's about." It is, in short, a concept that ties ideas together and gives them meaning. Theme has been, well, a major theme in the earlier chapters in this book because it's a useful mechanism for keeping a diagram, artifact, or conversation focused. Themes provide direction for design, a basis for making design decisions. Can design projects proceed successfully without a theme? Potentially, but experience shows that having a single unifying idea can keep design activities focused.
The design project may have an overall theme, but it's useful to devise such a focus for the deliverable itself. This is more than just the purpose of the deliverable (to communicate the latest design ideas or to solicit feedback or to facilitate decision-making). A theme for the deliverable constitutes the primary takeaway, the one thing that readers get from reading the document. Some examples:
Stating them this explicitly as a planning exercise is good. Stating them this bluntly in the document may challenge team dynamics.
A deliverable that tells a story acknowledges what came before. This reference is more than just a mechanism to remind the project team what they just did. References to prior work lend credibility to the current work, normalize the underlying assumptions shared by the project team, and, ultimately, drive the design.
One way to position the most recent work is in contrast to what immediately came before: Version 2 improves upon version 1 in this way. A version history, as such, not only helps people follow the trail of the design process but know what to focus on. With the increasing complexity of projects (in terms of requirements, technical capabilities, quantity of stakeholders, and depth of reach into the organization), a "previously on our show" message reminds people what's important.
Recent work may also lead into the next set of design activities: A site map sets up wireframing, personas provide context for up flowcharting. The "end" of a deliverable is not just the design punch line, but also how it sets up the next steps.
When denied a viewing of the latest commercial flick due to the potential fear factor, my son often asks us, "Why are there scary parts in movies?" At an early age, he learned about drama—it's what makes stories interesting. In the hopelessly nonfiction, unanimated, explosion-free world of design documentation, we can still use conflict to make an impression on project participants. (And I'm not talking about 3D PowerPoint animations.)
In this case, conflict comes from contrast and comparison. The project plan provides one way to draw comparisons: time. We can compare between the state of the design today and the one previously; between the current design activities and the ones to come. But there are other kinds of contrast a deliverable can use as the basis for a story:
Tension draws people in. The more you can use these conflicts inherent in the design process as a framework for the document, the more you will engage the project team to participate.
Stories have characters, the seemingly autonomous actors who, with the right amount of depth and empathy make readers care about them and interested in the story. The stories I'm most attracted to are those whose characters I care about long after the show or movie or book is over. It isn't the plot lines that linger in my imagination: It's the definition of the characters—who they are and the decisions they made.
It can be easy to default to thinking of personas (or even project team members) as the characters in your story, but this approach does a disservice to the deliverable.
Can you treat design artifacts as characters? At the simplest level, I've seen good art directors name their design concepts. Some of the best names are abstract, evoking the concept without necessarily being an accurate, objective description. (Think "Blizzard" for a design concept in cool colors rather than "Gray and Teal with Rounded Corners.")
As the artifacts emerge, think of them as distinct personalities, each relating to the theme (the overall design concept) in a different way. Independently, they can't describe the theme fully: They need each other to explore the theme and overarching concept fully. As their author, you need to ensure that they are believably part of the same universe, making use of the same visual language, resting on the same assumptions, and working toward the same objectives.
Therefore, after reading a deliverable, someone who hasn't been along for the ride should be able to describe:
Make sure you incorporate content in your deliverable that accomplishes these objectives.
By the way, did you know we've teamed up with Dan's company, EightShapes, to bring you a fabulous series of virtual seminars this winter. The first one, 5 Simple Principles to Improve Your Information Architecture, is next week and I'm really looking forward to it. Dan's packed some great wisdom into it -- stuff you shouldn't miss. Read all the details.
How have you integrated story elements into your deliverables? We'd love to hear what's worked and what hasn't. Leave your thoughts at the UIE Brain Sparks blog.
Read related articles: