Testing may precede requirements as a way to see what works (or doesnt work)
with the current site, or with related sites. Testing may also occur throughout
the design process, a way to constantly evaluate and refine your work.
There’s no direct relationship between these activities and the kinds of docu-
ments described in this book. The design documents, for example, do not
necessarily correspond to the design activity. As youll see in the chapters them-
selves, these deliverables—though mostly used for design—can also be used as
tools for gathering requirements and testing.
Beyond methodology, project teams maintain an unwritten set of rules for
working together. This is the project culturean understanding of the value
each team member brings to the table, of how communications happen between
team members, and the role of documentation in the organization.
This book assumes, perhaps naively, that a good project team should be built on
collaboration and consensus. Most projects fare better when they operate under
the assumption that everyone wants to make a worthwhile and meaningful con-
tribution and that people should feel some ownership for their work. Such an
approach comes with potential risks: the project becomes more about soothing
egos than doing what’s right, decision making takes longer, innovation doesnt
happen in groups. But a group (and again, this is perhaps naive, but not without
its merit) committed to a successful project will take steps to mitigate those risks.
Many of the documents described in this book use diagrams, visual representa-
tions of ideas or concepts. Since the early days of web design, these pictures
have proved to be the best way to document some of the abstractions design
teams have to work with. Although each of the documents in this book relies
on a different process to create it, there is a general method you can follow
when creating a diagram. (This is more or less the process I use. Your mileage
may vary.)
Do a situation analysis. Three things will shape your approach to
diagramming an idea: the purpose of the drawing, where it fits into the
process, and the audience. These factors are discussed in detail for each
Make a list of all the pieces of information you want to capture.
Again, this technique is described in detail in each of the chapters. The
pieces of information are called “elements” or “dimensions” or “data
points.” They represent a small part of the story, and the purpose of the
diagram is to tie all these pieces of information together.
Plan the drawing on paper, capturing as many elements as possible.
The sketch should provide a good plan for how youre going to accommo-
date all your information.
Transfer the paper sketch to a drawing application, like Adobe
Illustrator, Microsoft Visio, or OmniGroup’s OmniGraffle. Usually,
it’s best to start in black and white and just focus on layout.
Figure out how you want to use color and start experimenting
with it. With flowcharts, for example, color is good for grouping related
steps or paths, or calling attention to certain elements. One approach is to
go back to your list of elements and identify one or two that can be best
represented through color.
Refine your visual language. The visual language is the set of shapes
and conventions you’ve applied to the list of elements. At this point, youll
have a sense of where your visual language is working and where it’s not
working. Specifically, diagrams may appear too busy to be readable, or
may not have a coherent story. When you refine the visual language, youre
looking for opportunities to make sure the main messages are clear. Youre
also looking to strip away excess information—visual noise that doesnt
hold much meaning or contribute to the story.
Write your copy. Start labeling the elements of your drawing before you
forget what they mean, and add additional blocks of copy.
Identify the weak points. Send the drawing to your printer and mark it
up. Youll want to refer back to your situation analysis at this point for the
sanity check. By now youre so engrossed in the drawing, you need to take
a step back. Ask yourself whether the drawing answers the basic questions
about flowcharts: Where does the user start and end? What are the major
steps in the process?

Get Communicating Design: Developing Web Site Documentation for Design and Planning now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.