|
–Geoff-Hart.com: Editing, Writing, and Translation —Home —Services —Books —Articles —Resources —Fiction —Contact me —Français |
You are here: Articles --> 2004 --> Streamlining an interface
Vous êtes ici : Essais --> 2004 --> Streamlining an interface
by Geoff Hart
Previously published as: Hart, G. 2004. Streamlining an interface using information design principles. Intercom December:9–11.
“Information design” is the art and science of understanding problems from the product user’s standpoint, and using that understanding to select an appropriate mix of graphics and text that supports the design and presents necessary information appropriately. This topic, originally presented as a progression topic at an STC annual conference, presents a simple, iterative way to examine a design problem, and uses that approach to solve a common design problem: using space more efficiently in a software interface.
Users of the products we document often have a difficult time understanding the products well enough to use them. That complexity often arises more from poor design choices than from the task’s inherent complexity, and skilful design of the documentation (including that portion of the documentation embedded in the product’s interface) can greatly facilitate working with the product. The field of information design offers many tools for understanding the information needs of our audience and discovering how to meet those needs.
Software interface design represents one area in which technical communicators are increasingly being asked to assist developers. Although we may have little opportunity to influence the overall software architecture, we can sometimes make existing architectures far more usable simply by presenting the embedded information more effectively. Typical problems we can resolve include:
All these problems make it more difficult to use the product, but they also cause considerable frustration for the designers, who lack the time and often the skill to create a user interface they can be proud of. Moreover, these problems make it difficult to document the application well: poor design logic is difficult to explain, and the documentation takes more time to create.
Although length (and thus cost) is less of an issue with online information than with paper, there’s still a practical limit to the number of screens users will accept while performing a task. In general, minimizing the number of screens facilitates tasks, but when developers reach the logical minimum (a single screen), the density of information can become overwhelming. In this case, our goal must be to simplify the interface so that it uses the available space efficiently and effectively. This design challenge is particularly relevant for the extremely limited screen space in handheld computers, personal digital assistants (PDAs), and cell phones.
Many of us first try our hands at interface design when a developer asks us to edit onscreen text to fit better in limited space. The goal is often phrased in terms of a specific number of characters when the actual solution requires more than simply shortening the text. Poorly designed labels, a dense screen of text, no clear indication of the sequence of actions required, and missing affordances often pose the real design challenge.
This paper summarizes a more detailed paper (Hart 2003), and complements a hands-on exercise in interface redesign presented at the annual conference. A goal of the exercise was to avoid reprogramming the underlying software code, since programmers often resist such significant changes. However, because modern screen-design software makes it easy to reorder and relabel screen elements, programmers are generally willing to work with us to redesign screen layouts. The benefits for the programmer are less than for the product’s users, but include the ability to produce a design faster than they might without our help. Successful co-operation is a good first step towards gaining their support for more significant interface changes in the future.
In this paper, I describe a simple, iterative four-step process for analyzing and improving screen designs. These steps are repeated as often as necessary to produce a satisfactory design:
A subscriber to the techwr-l technical writing discussion group (www.techwr-l.com) asked for help simplifying the labels in a dialog box. All four fields shared a common theme; thus, they needed to appear similar (to reflect the common theme) yet distinct (to communicate their differences). The dialog box was designed to let users find entries in a database of contracts based on the expiration dates. The developers insisted that the labels be no more than three words long because of tight space constraints. The four fields had already been grouped into this dialog box to address their similar goal, but their labels communicated the differences between fields ineffectively. For the first step in the analysis, identify common components that could be removed from each field and used as a heading. The four fields appear in Figure 1.
Figure 1. Four fields with similar themes.
In attempting to group similar fields based on their common aspects, it’s clear that users must search for contracts based on their expiry dates. Moreover, the expiry dates may lie in the future or the past, and include a time limit. The design challenge now becomes how to describe all these possible situations with a single heading. The wording “Display contracts with expiry dates:” solves this problem by (i) focusing on the task (displaying contracts), (ii) providing context (based on expiry date), and (iii) suggesting (using a colon) that a list of options follows. Figure 2 presents the new design that results from this analysis, and is clearly shorter than the original wording. The wording is still not as clear as it could be, but that’s because we’re starting with a bad interface and improving it slowly to focus on the individual steps and emphasize the process.
Figure 2. A new configuration for the fields presented in Figure 1.
In the second step, try to discern the actual problem to be solved so you can provide additional clues (affordances). Assuming that “a maximum of three words” is literally correct conceals the real problem, namely that space is limited, not the number of words; the screen might actually have room for 10 three-letter words. In this example, the actual space constraints weren’t available, so I’ve assumed that English root words average about 5 letters long, and that the “three words” constraint thus limits us to about 15 letters per field. (In a real example, we would confirm this limit with the developers.) All four labels in Figure 2 exceed 15 characters.
The original wording was also unclear, since the actual time limits may be “less than or equal to” and “greater than or equal to”. (Note that although “fewer than” might be more grammatically correct than “less than”, and the time intervals are uneven and inconsistent, I’ve retained the original wording in the problem posed by the developers.) To simplify, I’ve assumed that “less than” and “greater than” are literally correct. Symbols such as < (less than) and > (greater than) would be efficient labels for an audience that understands these symbols, but without knowing our audience’s background, we might be forced to provide “tool tips” to explain these symbols to users who don’t already know them. That’s neither efficient for the user nor likely to encourage the developers, who would have to perform additional programming. Thus, it makes more sense to use words rather than symbols.
Affordances can help. For example, text labels may be less efficient than radio buttons because with text, the need to make a selection must be inferred; radio buttons clearly communicate the concept “pick one”. Recognizing that the simplified labels in Figure 2 contain additional shared information lets us transform that information into subheadings that can be described as “future items versus past items” and “more than versus less than”. Letting users select these four choices produces the interface in Figure 3.
Figure 3. Using affordances to turn the shared information into subheadings.
Next, try to identify the order in which users would state their question and any dependencies that arise from that order. For example, users would typically determine when the problem occurs (how many days) and whether the situation lies in the future or the past. An improved design recognizes that the number of days follows the “before vs. after” choice rather than depending on it, and could thus be displayed only once; moreover, the timing (past or future) can become a simple choice (Figure 4). This new design expresses the choices in the same order that users would express the problem. In fact, the interface now expresses the information in the form of a sentence: “Display contracts with expiry dates [more than/less than] X days [ago/from today].”
Figure 4. Expressing choices in a different order.
To further improve this design, repeat the previous three steps as often as time or diminishing returns permit. For example, typical interfaces ask users to click an “OK” button to begin searching for the specified contracts. Given that the user’s real goal is to display the contracts, not search for them, the button could instead say “Display” to reflect that goal. With that change, we could also remove the word “display” from the heading (Figure 5).
Figure 5. The results of the first iteration.
Of course, we’d want to test the design to ensure that the results are as good as we think they are; for example, the change reflected in Figure 5 may actually decrease usability because the heading above the choices is no longer as clear. Even so, the simple analysis described in this paper has already produced impressive increases in clarity and ease of use. The wording now matches how users would define the problem and the sequence they would follow to define their question and solve the problem.
Interfaces often represent abstractions of complex information, relationships between information, and tasks that users perform with that information. Thus, interface design often seems to be more art than science. Nonetheless, the approach described in this paper lets you rigorously examine a design and identify means of improving it. This process takes advantage of the information design principles of grouping related information, eliminating unhelpful redundancies, and developing new affordances. Moreover, it has two additional benefits. First, it emphasizes an iterative approach that focuses on (and potentially involves) the users of the interface. Second, it recommends consecutive rounds of improvement rather than a static approach with only a single iteration, which may provide suboptimal results. Raskin (2000) provides considerable guidance on analyzing the theoretical efficiency of improved interfaces that can help when you lack the opportunity to test an “improved” interface with real users. Ray and Ray (2001) also provide a helpful discussion of how to move the help into the interface itself, and thus build on my paper.
Hart, G.J.S. 2003. Redesigning to make better use of screen real estate. p. 337–350 in M.J. Albers and B. Mazur, editors. Content and complexity: information design in technical communication. Lawrence Erlbaum Associates, Mahwah, NJ.
Raskin, J. 2000. The humane interface: new directions for designing interactive systems. Addison-Wesley, New York, NY.
Ray, D.S.; Ray, E.J. 2001. Embedded help: background and applications for technical communicators. Technical Communication 48(1):105–115. (Available online at: www.techwr-l.com/techwhirl/magazine/technical/embeddedhelp.html)
©2004–2024 Geoffrey Hart. All rights reserved.