This book, in a word, is about documentation. Sounds boring, doesn’t it?
Documentation—the collection of documents prepared over the course of a
project—is, in many ways, the underbelly of web design. After all, documents
usually appear on paper and end up sitting on a shelf where no one reads them.
How cool could that be?
But anyone who has worked to design a web site knows that documentation
can make or break the project, that it moves the process along by capturing the
design concept and helps project team members communicate with each other.
Web design documents—or “deliverables,” as they’re sometimes called—also
serve as milestones, marking progress in an otherwise seemingly interminable
process. They’re historical, allowing people who come to a project later to get
up to speed on the decisions made by earlier project teams.
In short, a document captures an idea. Perhaps this is a little existential for the
web design business but, getting down to brass tacks, if we can’t communicate
an idea effectively, how can we hope to create a web site around it?
The value of good documentation is indisputable, but there’s very little discus-
sion about it in the web design canon. This isn’t to say that deliverables have
never been addressed. Stumble onto the blog of any designer or information
architect and you’re bound to see at least one article on effective wireframing,
or a set of shapes to use in a ﬂow chart. But on a larger scale, there has never
been a careful look at what makes design documentation effective.
On the surface, this book will help you improve your documentation, provid-
ing advice on how to plan your deliverables and use them effectively in meet-
ings and on projects. In the course of doing so, it will also attempt to uncover
what makes a document good, and help you recognize the difference between a
bad document and a bad idea.
It doesn’t cover every deliverable. This book discusses ten of the most
common web design deliverables—the ones you won’t be able to avoid if
you spend any time at all in this business. These are user experience deliver-
ables, so if you’re looking for advice on creating entity relationship diagrams
or uniﬁed modeling language diagrams, you might want to go elsewhere.
There are countless documents for user experience work that this book
could have addressed, but many are not common, or they’re proprietary, or
they’ve been discussed in elsewhere. Check out the book’s companion web
site, www.communicatingdesign.com, for more information about all kinds
of web design documents.
It doesn’t care what methodology you use. Methods come and go,
but documents appear to remain more or less consistent. One of the central
assumptions of this book is that anyone should be able to use it, regardless
of the methodology they use. That being said, it’s difﬁcult to write about
documentation without any sense of timing or dependency, so I will make a
few methodological assumptions; they’re detailed below. These assumptions
provide structure for the book, but they won’t render it useless if you’re using
a different method.
It’s a how-to book, but not a software book. This book will help you
make better deliverables. It will help you present those deliverables better
to your clients and team members. It will even help you anticipate risks in
creating and sharing deliverables. But it will not tell you how to use soft-
ware applications to make those deliverables. Different people prefer differ-
ent tools, but the choice of tool should have little impact on the message and
purpose of your documentation.
It’s a cookbook. Each chapter in this book is a recipe for working with
a different kind of document, and you’ll have your own ideas about what
makes a dish work and what doesn’t. Feel free to add notes in the margin.
You may even ﬁnd that a technique described for one kind of document
works well for a different kind of document. Although the book tries to
make each chapter self-contained, you may ﬁnd inspiration for one kind of
deliverable in other chapters.