Communicating Design: Developing Web Site Documentation for Design and

Bibliographic Information

Communicating Design: Developing Web Site Documentation for Design and Planning, Second Edition

Publisher: New Riders
Pub. Date: September 15, 2010
Print ISBN-10: 0-321-71246-3
Print ISBN-13: 978-0-321-71246-2
Web ISBN-10: 0-13-138539-9

Web ISBN-13: 978-0-13-138539-9

Creating Design Artifacts

Since the early days of web design, pictures have been the best way to document the abstractions design teams work with. While the activities that produce the diagram may vary, creating the artifact itself generally follows a similar process. That is, to produce personas, you first need to collect information about the web site’s target audience. The activities for producing wireframes, on the other hand, are very different. In both cases, however, when it comes down to putting those ideas on paper, you can rely on similar processes.

Every chapter dedicated to an artifact includes a “Creating...” section, which describes how you can apply the general process explained below to that specific diagram. Note that the process isn’t so much “first you draw a rectangle,” but more “here are the things to think about before you put pen to paper.” Or pointer to pixel, as the case may be.

Basic Decisions

Taking a few moments to think through the diagram’s purpose, role in the project, and target audience can improve your efficiency in creating the artifact. Establishing the situation provides some focus. The other thing I do is make a list of all the content I want to include in the diagram.
Purpose
Every artifact needs a purpose. Ultimately, it will appear in a deliverable and needs to support the purpose of the document. Individual diagrams, however, need a purpose in and of themselves. This keeps them focused and ensures you’re not just putting effort into busywork. The “Why communicate design” section in the Introduction explores some of the basic reasons why we make design artifacts. Here are some more concrete purposes, explored in greater detail throughout the book:
  • Capturing current state: A description of how the web site (or some other element of the design problem) looks and works today.
  • Establishing the design problem: A statement explaining what the design needs to do. There are lots of ways to express a design problem: in terms of user needs, indicating deficiencies in the current design, showing where key parts of a process are broken.
  • Presenting design ideas: A depiction of a concept, an approach to solving the problem. Different artifacts are stronger at depicting different parts of the solution.
Timing
This book makes certain assumptions about when the design team might create each artifact, and the chapters appear in more or less chronological order. This isn’t to dictate a process or best practice. It simply reflects the way most of my projects operate.
That said, deliverables are the result of activities. Project plans should specify tasks, not deliverables. They should say “design checkout process” not “create wireframes.” Project plans are about what people need to do in order to achieve the project objectives: deliverables are a by-product of those activities.
Determine the appropriate deliverables once you’ve established the tasks required to meet an objective. If you’ve aligned the tasks based on dependencies (such as “we can’t validate requirements without learning more about users”), you can determine the appropriate deliverables and their formats based on those needs.

Audience

Artifacts may require adjustments depending on who you’re talking to. Typically, you might characterize the readers of your deliverables in terms of roles. Developers and engineers, for example, demand different information from other designers, project managers, and business stakeholders.
Great artifacts, however, account for more than just the audience’s role. An intimate understanding of your project team helps you craft artifacts in such a way that will be most meaningful to them. It can help you determine which elements to leave in and which to take out. Here are some of the attributes you might look for. When you think about your team, are they:
  • Detail-oriented or big picture?
  • Abstract thinkers or concrete?
  • Careful planners or impatient to jump in?
  • Focused on text or visuals?
Content
Unfortunately, the book can’t tell you exactly what to put in your diagram. The content depends on the specifics of your project.
Instead, each chapter provides examples of the range of content that might go in a diagram. For example, the site maps chapter discusses that site maps can represent specific pages on the web site (such as “About Us”) or templates (such as “a product template”). But it won’t tell you exactly what pages or templates to describe; that’s up to you and the project team.
The process of determining appropriate content involves:
  • Abstraction: How specific are you going to be about everything on the site?
  • Analysis: What things did you learn by looking closely at the information you have?
  • Agenda: What will best serve the design process in that moment? What do you need to move things further?
It’s difficult to plan a diagram without knowing the exact data points. (Just like it’s difficult to plan a web site without some insight into its content.) Making a list of the kinds of content you want to include is a good start, but expanding that list to describe specific examples of the content is even better.

Tips and Leveling-Up

Each artifact chapter also includes sections on tips for creating the specific diagram and ways to avoid its common traps. Here are some general ideas on the process I follow when putting any diagram together, and should serve as a starting point for any of the artifacts described in this book. The tips and skills sections in the artifacts chapters assume you’re using some version of this process.

Example: Planning for personas

After conducting some user research, you have a stack of data about the site’s target audience. You know everything from their favorite weekend activities to their favorite flavor of ice cream. You have a good sense of how internet usage factors into their daily lives, and have an inventory of what personal technology they use (phones, computers, mobile devices, set-top boxes, and so on).
  • Abstraction: Highly abstract personas are a collection of behavioral characteristics without much humanity. At the other extreme, concrete personas are indistinguishable from actual people. You decide on something in the middle: what can you say about your user groups based on the different roles they play relative to the site you’re designing?
  • Analysis: Close examination of the data collected yields four different roles people play and gives you about a dozen insights for each role. The data also imply possible ways to contrast the different roles with each other.
  • Agenda: Since the purpose of these personas is to “establish the design problem,” you want to position them in terms of requirements to help designers focus, prioritize, and validate their concepts. You could have described them using open questions to highlight the need for further research, but you’ll save that content for another time.
A rough process for diagramming
  1. Make a list: Make a list of all the pieces of information you want to capture. You can start with a general category of information (like “page types”) and then list out the specifics (like “product page, gallery page, product discussion page, product specifications page”).
  2. Sketch first: Create some pen-and-paper sketches first, capturing as many elements as possible. Your objective with the sketch is not to get all the details, but to give yourself a reasonable framework as a starting point.
  3. Share early: Show the sketches to colleagues to get some feedback. Backseat your ego for these conversations. Good colleagues can offer a critique without getting personal, and their feedback is useful for your process: You need another set of eyes to help you determine if your approach communicates clear messages.
  4. Iterate: One sketch is not enough. If you think you’re ready to translate your sketch to a diagramming application, sketch it out one more time just to make sure you didn’t miss anything.
  5. Explore a different approach: I almost always build time into my process to explore a different way of presenting the information. After taking my initial concept through a few iterations to get it solid, I force myself to put it aside and look at the problem differently. One way to do this is to turn your initial assumptions on their head. For example, in describing a site’s target audience I might focus on two attributes. To take a different approach, I may select two different attributes, or I may create a different set of relationships (like lifecycle) between the user segments. Your alternate approach may not be better (if it is, go with it!), but it may shed some light on your first one, giving you a chance to flesh it out or add some detail.
  6. Move stuff around: Once it’s in vector form in my drawing application of choice, I move the elements of the diagram around. This is especially useful for flowcharts, site maps, and concept models—any node-and-link type diagram—where the change in perspective can yield new insights.
  7. Color sparingly: Some of the chapters offer ideas on how to apply color to the diagrams. Color is a dramatic way of highlighting differences: The contrast between a red thing and a blue thing draws the reader’s eye almost immediately. It’s a “heavy” technique for making distinctions and should be applied with the utmost care. When in doubt, stick with varying shades of gray.
  8. Use conventions: 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, you’ll have a sense of where your visual language is working and where it’s not working. Specifically, diagrams may be too busy to be readable, or may not convey a coherent story. When you refine the visual language, you’re looking for opportunities to make sure the main messages are clear. You’re also looking to strip away excess information—visual noise that doesn’t hold much meaning or contribute to the story.
  9. Revisit inputs: Check your work. Make sure you’ve got all the details expected by the others on the project, especially if the team expects the work to build on previous documentation (like requirements or user research reports). Comparing your diagram to those inputs can ensure you haven’t missed any crucial elements. Earlier documentation can be a proxy for other members of the team; their questions and feedback will be drawn from their understanding of the project, which is presumably captured in these earlier deliverables.
  10. Label, label, label: Never assume that elements of the diagram stand on their own. Better to over-label, especially in early drafts of the picture, than to assume your readers see things in the same way you do. Whereas color and line weight can be overdone, you can never have too much labeling. I look back on concept models that are less than two years old where I neglected to label the links between the concepts and I wonder, “Why did I link these two?”
Tip: Soliciting feedback on rough drafts
Your colleagues may be stumped as to the kind of feedback you need on a rough draft. You can draw from these questions to stimulate the conversation:
  • What are the main messages you get from this diagram so far?
  • What information do you think is missing?
  • If you were making this diagram, what would you do differently?
  • I was thinking about incorporating X (another data point or type of content). Do you think that makes sense? How would you do it?
  • (If they know the client) How do you think Jane will react? What do you think she’ll want to see?
Common diagramming traps
The “Creating Personas” and similar sections of each chapter end with some ideas on how to “level up” your skills for that diagram. These skills address risks specific to each diagram, but they are all drawn from the following:
  • Lack of planning: Without spending some time considering the “basic decisions” described earlier, your diagram can spin out of control. A plan—even if you spend only five minutes on it—can establish focus and help you make design decisions about the diagram. A plan establishes a purpose, a timeline for creating the diagram, and a target audience. It can help you decide which content to include and which to leave out. It can help you decide what elements to prioritize visually and which to let recede into the background. It can help you decide when it’s a good time to share the diagram and who can provide good insight into your early drafts.
  • No narrative: This is a polite way of saying “hubris.” Without any narrative, you expect your diagram to stand on its own. Consider delivering a diagram outside the context of a document a very special, very extreme case. Every diagram should be embedded in a document that can provide context, further description, and a rationale for the decisions reflected therein.
  • Too much information: Without whittling down the amount of information you intend to include in the diagram, the visual language of the picture can overwhelm the message. Too much color, too many line weights, too many styles of type are all symptoms of trying to say too much with the diagram. If you can’t communicate your message with less, consider removing some of the key points to help preserve focus.

Books to Read

Classics

These books have been on my shelf for a long time. I keep coming back to them. They were both instrumental in my thinking about design.
Kristof, Ray and Amy Satran. Interactivity by Design. Mountain View: Adobe Press, 1995.
Raskin, Jef. The Humane Interface. Reading, MA: Addison-Wesley, 2000.

Web User Experience

Curtis, Nathan. Modular Web Design. Berkeley: New Riders, 2009.
Halvorson, Kristina. Content Strategy for the Web. Berkeley: New Riders, 2010.
Kalbach, James. Designing Web Navigation. Cambridge: O’Reilly, 2007.
Morville, Peter and Louis Rosenfeld. Information Architecture for the World Wide Web (3rd Edition). Cambridge: O’Reilly, 2006.
Saffer, Dan. Designing for Interaction. Berkeley: New Riders, 2007.
Tidwell, Jenifer. Designing Interfaces. Cambridge: O’Reilly, 2006.
Wodtke, Christina and Austin Govella. Information Architecture: Blueprints for the Web (2nd Edition). Berkeley: New Riders, 2009.
Wroblewski, Luke. Web Form Design. Brooklyn: Rosenfeld Media, 2009.

Project Planning

Unger, Russ and Carolyn Chandler. A Project Guide to UX Design. Berkeley: New Riders, 2009.

Design

Lidwell, William and Kritina Holden and Jill Butler. Universal Principles of Design. Beverly, MA: Rockport Publishers, 2003.

Comics

Abel, Jessica and Matt Madden. Drawing Words & Writing Pictures. New York: First Second, 2008.
McCloud, Scott. Making Comics. New York: Harper Paperbacks, 2006.

Presentations

Duarte, Nancy. slide:ology. Cambridge: O’Reilly Media, 2008.
Reynolds, Garr. Presentation Zen. Berkeley: New Riders, 2008.

Prototyping

Zaki Warfel, Todd. Prototyping. Brooklyn: Rosenfeld Media, 2009.

Users, Personas, Usability Testing

Beyer, Hugh and Karen Holtzblatt. Contextual Design. San Francisco: Morgan Kaufmann Publishers, 1998.
Krug, Steve. Don’t Make Me Think. Berkeley: New Riders, 2005.
Mulder, Steve and Ziv Yarr. The User Is Always Right. Berkeley: New Riders, 2006.
Pruitt, John and Tamara Adlin. The Persona Lifecycle. New York: Morgan Kaufmann, 2006.
Rubin, Jeffrey and Dana Chisnell. Handbook of Usability Testing. Indianapolis: Wiley Publishing, 2008.
Young, Indi. Mental Models. Brooklyn: Rosenfeld Media, 2008.

Making Diagrams

Buxton, Bill. Sketching User Experiences. Boston: Morgan Kaufmann, 2007.
Roam, Dan. The Back of the Napkin. New York, Penguin, 2008.
Tufte, Edward R. Envisioning Information. Cheshire, CT: Graphics Press, 1998.