What Makes a Good Deliverable

by Dan Brown

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.

Good Deliverables Tell Stories

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.

Theme

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:

The swim against the tide: “This project is fraught with external challenges. Here’s what we’ve been able to accomplish within the established constraints, but here’s why they’re not optimal.”
The fresh eyes: “This design challenge is very complex, and would benefit from a new perspective. Here’s a new way of thinking about this problem and what insights it yielded.”
The refactored challenge: “This approach to the design challenge doesn’t accommodate all the requirements, but it does address user needs as described in user research.”

Stating them this explicitly as a planning exercise is good. Stating them this bluntly in the document may challenge team dynamics.

Beginning, Middle, and End

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.

Conflict, Contrast, and Comparison

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:

Different approaches: In short, the deliverable presents two different ways to solve a design problem. It lines up the options side-by-side to highlight the tension between them and make it easy to pick one over the other.
Conflicting priorities: Even the simplest design problems come with inherent conflicts. With all the different people working on the project, all the different objectives, all the insights from user research, the design team is bound to encounter requirements that conflict. Conflicting requirements call for two different design approaches, or one solution that successfully mediates between the two. There are multiple ways of addressing such conflicts, but regardless of which direction you choose, the document can tee up your approach by illuminating the distinction.
Ambiguity in requirements: Another kind of conflict is between reality (what you have) and the ideal (what you’d like to have). Positioning the starting point against the ideal can help stakeholders understand the gaps in knowledge. Perhaps you’re trying to fill these gaps through research or brainstorming, or perhaps the gaps in knowledge help explain the state of your design direction or the approach you took to get there.

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.

Characters

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.

Storytelling in design documentation

Therefore, after reading a deliverable, someone who hasn’t been along for the ride should be able to describe:

What the current state of the project is.
How the current design decisions relate to previous activities and how they set up the next set of activities.
What the overall theme of the design project is.
What the most important design decisions are, and how they relate to the overall theme.
What the major issues facing the design project are.

Make sure you incorporate content in your deliverable that accomplishes these objectives.

Published here on December 7, 2010.