What Makes a Good Deliverable
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
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
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.
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
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
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.
Get more on designing for user experiences
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.
Share your thoughts with us
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.