Visual Methods of Communicating Structure, Relationship, and Flow
Published: November 16, 2009
Many of us are more comfortable communicating in words than in pictures. For example, user assistance writers are by nature and training writers, so they understand words and are adept at using word processing and publishing tools. Writers use lexicentric tools not only for creating and delivering content, but also as cognitive tools—that is, tools that help them think more clearly and efficiently. Thus, a user assistance writer might create a user-task matrix or take advantage of a word processor’s outline view when creating or evaluating a document’s structure.
However, we could also use a number of visual techniques and tools—not only for generating content, but also as cognitive and analysis tools. Unfortunately, these visual methods and their respective tools do not get much attention, and many writers don’t use them with the same comfort level they do tools that let them manipulate words. As Figure 1 shows, some writers hold onto their lexicentric world view, sometimes to their detriment.
Figure 1—The age-old debate
This column looks at a few of the more useful visual analysis and communication methods that user assistance writers and others can use to help them understand and communicate structure, relationship, and flow. For people who want to move beyond thinking and communicating in words, I’ll examine the following visual methods of communication:
- block diagrams
- use case diagrams
- cross-functional diagrams, or swim lanes
- mind maps
Block diagrams show structure and relationships. For example, site maps are block diagrams that Web designers can use to both plan a Web site and communicate its structure to users. Block diagrams can explain complex systems and show relationships among their components. The block diagram in Figure 2—which I created in Visio using the Block Diagram | Basic Blocks stencil—shows the configuration of a system’s components across three servers. The arrows show relationships, in this case which components exchange command data and in what direction.
Figure 2—System configuration block diagram
Block diagrams most effectively communicate the answer to the question What are the parts of a system and how do they interconnect?
Flowcharts show sequences and branch logic within a process or procedure. They can also designate actors—who does what. The boxes in a flow chart typically represent steps in a procedure or procedures within a process; the arrows show sequence, or flow. In a flowchart, a decision diamond represents each logical branch, usually stated as a question, with exit paths representing different conditions. Figure 3—which I created in Visio using the Flowchart | Basic Flowchart Shapes stencil—illustrates a segment of a flowchart that shows the sequence of tasks performed by Information Developers (IDs), Information Architects (IAs), and an Editor.
Figure 3—Information development process flowchart
Flowcharts are the best means of communication when the questions are What happens first, then next, and what determines branches in the flow? They can also designate who does what, in what sequence.
Use Case Diagrams
Use case diagrams show actors, tasks, and the relationships of tasks to each other. Typical relationships include extend—when a task describes a special instance or exception to a task it extends—and uses—when a task calls on a subtask. Figure 4—which I created in Visio using the Software | UML Use Case stencil—shows a use case diagram for a reporting module.
Figure 4—Reporting module use case diagram
Use case diagrams are most useful at the start of a user or task analysis phase, when the high-level question is Who does what with the system?
Cross-Functional Diagrams, or Swim Lanes
Cross-functional diagrams show complex flows and logic that cross over functional boundaries. People often call them swim lanes, because they look like the lanes in a pool that’s set up for a swimming meet. Essentially, they are parallel flowcharts that show how the work flow and artifacts pass among different groups. Figure 5—which I created in Visio using the Flowchart | Cross Functional Flowchart stencil—illustrates a set of procedures that different groups perform.
Figure 5—Segment of a swim lanes diagram
Use a swim lanes diagram when a process or work flow extends across multiple groups or actors—especially when there are interdependencies, for example when one group must finish a task before another can begin their work.
Mind maps are a visual way of categorizing concepts and showing relationships. I resisted them for a long time thinking they were too abstract for my liking. But then I used one to analyze a large set of data from some focus groups my company had conducted, and I’ve been a believer ever since. I was working on an online bill-payment product, and I needed to understand what information users needed when they paid bills online. First, I went through all of the transcripts and highlighted any mention of information—such as due date or biller address. Then, I typed this data into a mind-mapping tool and created categories that grouped the individual data points. In the end, we used the information to design a user assistance intervention that presented critical bill and biller information in a popup overlay when a user pointed to a specific bill in a list. Figure 6—which I created in Visio using the Brainstorming stencil—shows a segment of the mind map I created.
Figure 6—Segment of bill-payment mind map
I recently tried a mind-mapping tool called PersonalBrain, using it to summarize and categorize the data from stakeholder interviews and better understand the problem space for a project I was just starting work on. PersonalBrain’s data presentation is very dynamic—stretching and bouncing data to create a bit of a Wow! reaction. Figure 7 shows the high-level mind map I created. The nodes SELMS Deployment and Early Acceptance Curve have attached graphics that open in popups.
Figure 7—Mind map of data from stakeholder interviews
In Figure 8, you can see this mind map with the Cost savings ideas node expanded.
Figure 8—Expanded section of mind map
Pointing to the Endpoint records node in the mind map displays a Notes tab, on which I had captured the quotations from the interviews supporting that node—see Figure 9. I really like the ability notes gave me to tie the nodes in my model back to the source data.
Figure 9—Notes for Endpoint records
Mind maps are useful when you want to answer this question: Is there a pattern or logical set of categories in a large set of verbal or conceptual data?
Wireframes are blueprints that show how you’ll lay out a user interface (UI). Typically, they communicate the elements of a user interface and how users can interact with them. Low-fidelity wireframes are particularly useful for early design and analysis, because they don’t take a lot of time to create or distract team members with nonproductive pixel pushing. Realistic, high-fidelity mockups can engender a lot of debate about things like just how big a button should be or what its exact coordinates should be, when the better discussion would be whether it should be a button or a link and whether it should be at the top or the bottom of the page.
Figures 10 and 11 show the same design concept—as a high-fidelity wireframe and a low-fidelity wireframe, respectively. If the design issue is adding a context-sensitive Help link to a window, the team could easily get distracted by the high-fidelity wireframe shown in Figure 10—which I created in Visio with the Software | Windows and Dialogs stencil—because they might want to wordsmith the UI text and the spacing of the buttons. With the low-fidelity wireframe shown in Figure 11—which I created using Balsamiq Mockup—it is much easier to focus on the current design issue—that is, Where should a context-sensitive link go and what should it say?
Figure 10—High-fidelity wireframe
Figure 11—Low-fidelity wireframe
Use low-fidelity wireframes when exploring design concepts for user interfaces. Use high-fidelity wireframes to communicate the layouts of your final designs.
Comics represent a visual chronology and can communicate processes, as well as explain complex concepts and relationships. While we don’t think of comics as a traditional technical communication tool, lately I have been seeing more instances of them crop up. Google’s technical overview of its Chrome browser technology by Scott McCloud is a recent example—see an excerpt in Figure 12. Not only is this an innovative way of communicating technical concepts visually, it can provide an excellent means of analysis as well. Joe Welinske interviewed Scott McCloud at the WritersUA 2009 conference in Seattle. I was impressed by the process behind the comics and how the need to distill complex concepts down to a few panels helped people understand them and resulted in a more concise communication of the concepts.
Figure 12—Excerpt from Google Chrome’s Googlebook
I have found that comics can also help lighten up internal communications, so I have started creating them for a particular project’s wiki page as part of my weekly project summary. I create my comics using Make Beliefs Comix, a free, online tool that can overcome anyone’s lack of inherent cartooning skills. This Web application provides a portfolio of characters with an array of emotional poses, dialog boxes, and simple manipulations such as flip. Figure 13 shows a comic strip I created that makes fun of Java’s slow response time and the unnerving effect it can have on users. My point was not original, but the comic format let me present it in a more meaningful way. Comics also help break up the text-only monoliths that wiki pages and status reports tend to become.
Figure 13—Comic about Java’s response time
As I learned from the Scott McCloud interview, making the weekly strip for my summary page helps me condense complex issues and also lets me communicate them in a humorous, but illustrative way.
Visual thinking and analysis can help us understand problem spaces in ways traditional word-based work habits and tools cannot. Designers can gain a more holistic understanding of their design problem spaces. User assistance writers can better understand the user interfaces they are trying to support—even if they don’t use these visual artifacts in the user assistance they create. The act of creating these visual artifacts inspires a vision that working with words alone cannot—and forces conciseness in its communication, too.