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

Purpose

• 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

Audience

• Detail-oriented or big picture?
• Abstract thinkers or concrete?
• Careful planners or impatient to jump in?
• Focused on text or visuals?

Content

• 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?

Tips and Leveling-Up

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?”

• 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

• 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

Web User Experience

Project Planning

Design

Comics

Presentations

Prototyping

Users, Personas, Usability Testing

Making Diagrams