Improve the User Experience with Dialog Maps
Many books provide guidance on how to create effective user interface displays, a vital aspect of the user’s experience with a software application. But a user often must navigate through a series of screens to perform a task. Making that flow sequence logical and efficient also is an important part of the user experience.
I’m a big fan of analysis modeling, drawing diagrams that visually represent various aspects of a software system and its requirements. One of my favorite models is the dialog map, which provides a convenient way to represent, validate, and improve how a user navigates through a user interface.
What’s a Dialog Map?
A dialog map illustrates the architecture of a user interface design. It depicts the dialog elements in the system and navigation links among them, but it doesn’t show detailed screen layouts (Figure 1).
A user interface (UI) can be regarded as a series of state changes. Only one dialog element — web page, menu, workspace, dialog box, line prompt, or touch screen display — is active for user input at any given time. The user can navigate to certain other dialog elements based on the action he takes at the active dialog element and the system’s state at the time.
In formal terms, a dialog map is a way to model a user interface in the form of a state-transition diagram. More simply, it’s a set of boxes and arrows that show how the user can move around in a system to accomplish a task. Similar modeling techniques are called a navigation map or user interface flow.
Dialog maps are related to storyboards, which also include a short description of each screen’s purpose and perhaps a screen sketch. You can think of a dialog map as a high-level model of the UI and a set of storyboards as a low-level model.
Just as in ordinary state-transition diagrams, the dialog map shows each dialog element as a state (rectangle) and each allowed navigation option as a transition (arrow). The conditions that trigger a UI navigation are shown as a text label on each transition arrow. There are several types of trigger conditions:
- A user action, such as pressing a function key, clicking on a dialog box button, or touching a link
- A data value, such as an invalid user input value that triggers an error message display
- A system event, such as detecting that a printer is out of paper and then popping up a message box on the screen, or displaying a “done” message when the system completes a task
- Some combination of these, such as typing a menu option number and then pressing the Enter key
Why Draw a Dialog Map?
When exploring requirements, a dialog map helps the team consider hypothetical user interface concepts. Through this activity, they’re certain to find errors along the way that can be corrected quickly and cheaply at this conceptual stage. Dialog maps help you find missing, incorrect, and unnecessary navigation options, thereby revealing missing, incorrect, and unnecessary requirements.
As a design tool, users and developers can review a dialog map to reach a common vision of how the user might interact with the system to perform a task logically and efficiently. Dialog maps capture the essence of the user–system interactions and task flow without bogging the team down in detailed screen layouts. And as with most visual analysis models, you can also draw a dialog map to document an existing system, which is a good way to practice the technique.
Dialog maps are useful for modeling the visual architecture of any app or website. Navigation links that you build into the system appear as transitions on the diagram. It’s easy for users to walk through a dialog map and imagine how they might perform a task. When I did this once, we realized that it took too many clicks to complete a specific operation, so we thought of ways to simplify the dialog map and hence the UI itself. You can employ a dialog map to improve the user experience even before the users begin to complain about it!
A dialog map is an excellent way to represent the interactions between an actor and the system that a use case describes. The dialog map can depict alternative flows as branches off the normal flow. I found that sketching dialog map fragments on a whiteboard was helpful during use-case elicitation workshops in which a team explored the sequence of actor actions and system responses that would lead to task completion. If you think you already understand a use case or process flow, compare it to a dialog map to ensure that all the functions needed to execute the steps can be accessed in the UI navigation.
It Looks Suspiciously Like a Flowchart
Dialog maps look a bit like flowcharts, but they serve a different purpose. A flowchart shows the processing steps and decision points involved in a process sequence, but not the UI screens you encounter along the way.
In contrast, the dialog map does not explicitly show the processing that takes place along the transition lines that connect one dialog element to another. The branching decisions (either user choices or system decisions) are hidden behind the display screens that appear as rectangles on the dialog map. The conditions that lead to displaying one screen or another appear in the labels on the transitions. Dialog maps and flowcharts therefore are complementary visual analysis models.
The Dialog Map Illustrated
I often employ as a case study for requirements discussions a project I once worked on called the Chemical Tracking System. A core use case for this system was called Request a Chemical. The normal flow for this use case let the user request a chemical bottle from the chemical stockroom’s inventory. An alternative flow was to request a new bottle of the chemical be purchased from a vendor. The user placing the request also wanted the option to view the usage history of any available stockroom bottles of that chemical before selecting one.
Figure 2 shows a dialog map for this fairly complex use case.
The entry point for this dialog map is the transition line that begins with the solid black circle labeled “ask to place a request.” The user would enter this portion of the application’s UI from some other part of the UI along that line. Exit points for the dialog map to return to some other portion of the UI are the transition lines that end with a solid black circle inside another circle: “cancel entire request” and “OK; exit request function.”
This diagram might look complicated at first, but if you trace through it one line and one box at a time, it’s not difficult to understand. The user initiates this use case by asking to place a request for a chemical from some menu in the Chemical Tracking System. In the dialog map, this action brings the user to the box called Current Request List, along the downward arrow in the upper-left part of the dialog map.
That Current Request List box represents the main workspace for this use case. It shows a list of the chemicals in the user’s current request. The arrows leaving that box on the dialog map show all the navigation options — and hence functionality — available to the user in that context. These options are to:
- Cancel the entire request.
- Submit the request if it contains at least one chemical.
- Add a new chemical to the request list.
- Delete a chemical from the list.
The last operation, deleting a chemical, doesn’t involve another dialog element; it simply refreshes the current request list display after the user makes the change. This appears in the dialog map as a loop that goes back to the Current Request List screen.
As you trace through this dialog map, you’ll see elements that reflect the rest of the “Request a Chemical” use case:
- One flow path for requesting a chemical from a vendor
- Another path for fulfillment from the chemical stockroom
- An optional path to view the history of a container in the chemical stockroom
- An error message display flow to handle entry of an invalid chemical identifier or any other error conditions that could arise
I hate it when some app forces me to complete a task even if I change my mind partway through. It’s a good practice to show transitions on the dialog map that allow the user to back out of operations. The dialog map lets you maximize usability by designing in those cancellation options at strategic points. In fact, reviewing a dialog map can show places where you’ve missed such options. It’s a lot cheaper to find those problems on a simple diagram than after you’ve delivered the product and customers start to complain.
A user who reviews this dialog map might spot a missing requirement. Suppose a cautious user wants to confirm the operation that leads to canceling an entire request to avoid inadvertently losing data. You could easily add a box and some arrows to depict this confirmation display. Again, it costs less to add this new function at the analysis stage than to build it into a completed product.
I Love Dialog Maps!
I’ve worked on projects where we created dialog maps to illustrate the user’s navigation options among more than 50 screens. We found dialog maps to be invaluable for communicating with our customers to create an optimal user experience. They also were a great way to begin the transition from requirements to design. Creating and analyzing dialog maps helped us discover many requirements errors at the conceptual stage. This helped us avoid considerable rework we otherwise might have encountered later in development or after delivery.
Because the dialog map represents just the conceptual view of the possible elements involved in the interaction between the user and the system, you don’t to pin down all the user interface design details at the requirements stage. Instead, use these models to help the project stakeholders reach a common understanding of the system’s intended functionality and design a superior user experience.
=================
This article is adapted from Software Requirements, 3rd Edition by Karl Wiegers and Joy Beatty. If you’re interested in software requirements, business analysis, project management, software quality, or consulting, Process Impact provides numerous useful publications, downloads, and other resources.
