Good information design makes good information

The information architecture is the result of the integrated approach to information design. It is the blueprint for maximizing software usability via the integrated design of labels, messages, online support elements and printed support elements. The information architecture identifies all the information elements users need and expect, describing each in terms of content, media and form-all based on the needs and expectations of users.

The information architecture helps cut time and cost by ensuring that big design errors are found and corrected early. It is much easier to cut four chapters from an information architecture than to add three pages to a final draft. Just as the architecture plan for a building project coordinates the activities of many workers, the information architecture coordinates the activities of a number of writers. For the technical writing team, it makes information development a more professional endeavor.

For real usability, the entire user interface, including all aspects of every interaction with the user, should be designed as a single, integrated element of the system. (See references, Constantine.) Only if the components work well together will the product be viewed as usable and meeting the user's needs.

Take for example a two-color, nicely produced user manual that has all the information about your software system. Though it also has that small piece of detail that a user is looking for, retrieving that detail will take a longer time because the manual is bulky, probably with many pages of unnecessary or inappropriately placed information. This will only adversely affect software usability. Some of the information in that manual should have been dropped or covered in another appropriate information element.

The usability components of a software system are user objects, user actions, interaction information and support information. What's critical, therefore, is integration. Integration is the software usability-driven approach to identifying all the information elements users need and expect, and designing, evaluating and improving them as an integrated whole. In this definition, "identifying" implies deciding on the content, media and form that users need and expect from each information element. And, "all the information elements" covers, labels, messages, online support elements and printed support elements.

Integration might appear obvious. But, here is what communicators say (see references, Gould, Lewis) about developing printed and online information:

• Online documentation should be written after printed documentation. The technical communicators' reasoning is that the online document is a subset of printed information. They also say that printed information contains many different structures such as introduction, procedures, examples, glossary and reference. The problem with this approach is that online information is not designed specifically for online use. For example, online text taken from a printed user's guide may not provide the quick how-to information users expect while working online.

• Online and printed information should be written independently. The technical communicators say that the same text should not be used to serve different purposes. Therefore style, formatting and retrieval techniques for online text will be different. Even in big companies, online Help, for instance, is often planned and written separately from the printed manual-often in another city. The problems with the approach are as follows:

Information provided in, say, online Help is repeated in, say, a printed manual, when there is clearly no such requirement from the users' viewpoint. Worse, if the Help (or manual) writer incorrectly assumes that the writer for the other media will cover certain topics, critical information could be left out. Error message might say that how-to information is available by pressing F1. When users press F1, all they get is what-went-wrong information.

Printed and online information should be generated simultaneously from a common database. The technical communicators say that printed and online documents contain the same information and that this ensures consistency.

Here are the reasons you should apply the integrated approach:

• It ensures that users have all the information they require-in the media and form they need or expect.

• It eliminates information users do not need or expect.

• It eliminates unnecessary repetition of information (note that repetition may be required from the user's viewpoint).

• It eliminates user dissatisfaction resulting from the above.

• It changes the user perception that using support information is an unnecessary diversion.

• It often results in smaller information elements with improved retrievability.

Because of interdisciplinary collaboration, when you take the integrated approach within a user-centered design process, you will have integrated information elements and, more important, the information elements will be integrated with the rest of the software usability components.

Users will perceive the overall software system as one single, usable system.

The information architecture should be designed by the technical writing manager or senior technical writers in consultation with the usability engineer and the programming team. The initial information architecture is designed during the high-level design phase. It should be improved based on task (user interface) complexity data, which may be available later in the project.

Integration clearly is the way to maximize software usability. Unfortunately, there is no single right mix of information elements-a predetermined set-that you can provide for every software system. For example, among the three software products of Netscape Enterprise Server, Microsoft Word and IBM Interactive Storage Management Facility, everything is different. The user interface is different. User groups are different. Information requirements are different. Obviously, the mix of information elements for each of these products is different. Similarly, you should determine the specific information elements required to support the information needs and expectations of your product users.

Nor can we define a comprehensive "IF . . . THEN . . ." formula. For example, I cannot say, "If you provide online Help for error messages, you don't need to provide a Messages section in the printed guide" because that depends on many factors that only the project technical writers know.

Therefore, what is provided here is only a framework to get you started on the right track.

The question you are trying to answer is, "What information elements should be provided?" In other words, what sets of topics should be separately packaged for which media? To answer this question, you should know the following:

• Users' information requirements. Know users, tasks and task (user-interface) complexity.

• Media characteristics. Know which media is best for what type of information and what user situation.

• Project-specific requirements. Be aware of things like resource and schedule limitations that are specific to the project.

Armed with that knowledge, you should do the following:

• Visualize the use of the software system to determine what information users will need and when.

• Pack a set of topics into each information element. For this, also consider various packaging approaches, such as task orientation described later in this chapter.

• Title each information element.

• Document the information architecture. List all the information elements that you should provide, describe what each element contains and show how each element fits into the whole. Place those details in the user-centered information design (UCID) plan.

Information elements provided should contain just the information users need and expect. Exclusion of some information may affect the users' task performance. Presenting information that is not required is a waste of time and effort. Moreover, it worsens retrievability and makes manuals bulky. To find what information users need, you need to know the users, the tasks they perform and the complexity of the user interface.

The more you know about users and tasks, the more you will know about the information required.

One of the things you should do to determine information requirements is construct a matrix where you list the tasks against the user groups that will perform the tasks. Use that matrix to identify the most important user-software interactions.

Task complexity

This is about how users will perform the tasks as implemented in a particular software system. Knowing task complexity is an excellent way to know what types of information users will need and when. You will, however, need at least some idea of the look and feel of the user interface, which is unlikely to be available at the start of the UCID high-level design phase. Iteration of the information architecture should therefore continue, at least until some user interface is available.

To understand task complexity, you could try a technique described by Doris R. Watts in "Creating an Essential Manual: An Experiment in Prototyping and Task Analysis." (See references.) Using a list of 10 questions, Doris set up a difficulty index to describe the tasks users can perform with a software system.

• Does this task require a single key response?

• Does this task require the use of more than one key?

• Does this response require synchronized operation of two or more keys?

• Does this task response consist of a sequence of keystrokes?

• Will users need to reposition the cursor?

• Does this task require numbered steps to explain it?

• Does this task response result in one or more new screens?

• Does this task require a typed response?

• Does this task require a choice from a menu?

• Does completion of this task leave users on a new screen?

An analysis based on a difficulty index can indicate user interface complexity. In the context of the example software described, Doris remarks that the easiest task is "deleting a character to the left," which required only one keystroke. The most difficult task is "selecting a specific page to print," which requires the use of five key responses, involves three or more steps, results in two new screens, requires two typed responses and three menu choices, and results in users being left on a new screen.

Decision time

Such indications of user interface complexity help you in designing the information architecture as well as in writing the information elements.

The medium of information delivery is a decision you make at the time of designing the information architecture. To make that decision, you must first understand the particular media where users will need or expect certain types of information. You should also know what kind of information would better go online and what would better remain on paper-from the users' viewpoint.

Print and online are the media most often used for communicating information. In the following sections, we will look at the effectiveness of online and print media in terms of retrievability, usability and readability.

The Web is a new media for providing support information. Although information appears on the users' screens, I'm not discussing Web support information under online media, because of the Web's unique characteristics. You should mull Web-based information elements for your software products. The possibilities are enormous, including multimedia capabilities and pointers to useful Web sites and newsgroups. Cost savings are possible for the software house that cuts down on printed information. Disadvantages with Web support information are the need for Internet access and slower access to information.

Video is another support information media. It is primarily used for presale demonstration and tutorials. The advantage is that it is fairly well-suited for demonstration. The disadvantage is that it demands a TV and VCR.

The audio (tape) media is used, but rarely. Its obvious advantage over online media is the absence of screen clutter. The disadvantage is that it demands a cassette player.

Print: Old reliable

Even after the "invasion" of the online media, print media is still used for its many advantages. Examples of printed information elements are user's guides, reference cards, and instruction foldouts.

Types of information better suited for the print media include information that:

• Is "a lot of text;"

• Contains concepts;

• Demands careful or detailed reading;

• Must be available when a computer is unavailable (e.g., installation and crash recovery information);

• Users may want to take home;

• Is legal, such as copyright, disclaimer, license, warranty and safety information.

How effective is print media? How good is print media? Let's review it in terms of retrievability, usability and readability attributes.

• Retrievability. Compared to the online media, retrievability with print is generally slower. However, there are many techniques you can use to maximize print retrievability.

• Usability. Printed support elements are difficult to make available to everyone. Often, users need to walk up to the bookshelf or library. Printed elements can get loaned, misplaced or lost. They take up desk space. One advantage is that most users find it easy to perform tasks online as they read instructions from a printed element. Finally, there is the advantage of portability.

• Readability. If designed carefully, printed information elements can have excellent readability. Here are certain factors that contribute. Resolution is excellent, with typeset pages having a typical resolution of 1,200 to 2,400 dots per inch. You can also use good graphic design to enhance readability. Size is a contributing factor. Size varies, but is usually small enough so that two full pages can been seen in one glance. Shape is another factor. It is predominantly portrait.

From the software house's viewpoint, one disadvantage with print is the production process it demands. A separate, time-consuming and expensive production process is required through an external agency.

The online media is the computer screen, where support information is displayed. The information element is often "physically" part of the software system itself. Information better suited for online media include quick "how to" information. Examples of online information elements are Help, tutorial and cue cards.

How effective is online media? At information design seminars I give, when I ask participants which media is better, most of them would put up their hands for online. But when I get down to specific questions such as, "Is it easier to read on the screen?" they start thinking again. In fact, there are people-like me-who would rather print it and read. Just like print, online has its advantages and disadvantages.

• Retrievability. If designed carefully, online retrievability is clearly superior to print retrievability. Users can retrieve and display information with a keystroke. The best thing about online retrieval is that even if you have a large amount of information, users do not perceive going from one "manual" to another. Hypertext and other techniques make retrieval a breeze.

• Usability. One of the best things about online media is the fact that users perceive online information as the software system explaining itself. In contrast, a printed manual is physically separate from the system and, therefore, users might think of it as a hindrance to the task they are performing with the system.

The online ability to display context-sensitive information has no parallel in the print media. Users can get just that piece of information they need at the moment-with one keystroke. Depending on the user's task context and his or her earlier performance, you can even automatically display contextual information.

Users do not perceive the "bulkiness" of online information. Only what they request appears on their screen. Moreover, removing the information is usually quick and easy.

Users, however, have complained about online usability in terms of them having to turn information "off and on" to continue using the instructions. This problem is eliminated in many new software systems, where a small window containing the instruction always stays while users read and apply the information to their application task.

Design shortcomings

Bad design can create problems. If the user interface for an online support element (e.g. Help) is significantly different from that of the user interface for the software system, users have to learn how to use that element. This defeats the purpose of providing Help or other online support elements. Bad design can also cover or clutter users' working screens.

Readability studies have shown that online readability is a loser against print readability. Resolution, the spacing between pixels on the screen, is not yet as good as on a printed page. Moreover, users cannot easily adjust the reading distance. Whereas most paper-based graphics can be shown on the screen, not everyone's computer will have the required resources, such as high-resolution monitors. The bottom line is that on-screen reading is 20 percent to 30 percent slower. For many users, online reading can result in eyestrain and headache. Online readability may be improved in the future when technology advances and becomes affordable.

Here are some reasons why developers prefer developing information for the online medium.

• Easier to produce and distribute. For producing online support elements, you don't have to use an external agency, whereas for printed support elements, you will go through a print shop. Of course, online information elements have to be put on a diskette or CD-ROM. However, this duplication usually happens alongside-and the same way as-the rest of the software system. In general, online information is also less expensive to duplicate, store and distribute.

• Better acceptance. Software engineers generally accept online technical writers more readily as fellow team members. Online writers themselves accept and enjoy the technical-writing profession better because online information is "physically" part of the software system and because of the various technical procedures, such as testing, that are involved.

We may have a design that is excellent from the users' viewpoint. From a business viewpoint, however, the solution may be infeasible. It is important that we strike a balance between an excellent solution and an infeasible solution by understanding the realities of the business environment in which the software engineering project exists.

References

Constantine, Larry L., "Toward Usable Interfaces: Bringing Users and User Perspectives into Design," American Programmer, February 1991.

Rubin, Jeffrey, Handbook of Usability Testing: How to Plan, Design and Conduct Effective Tests, New York: John Wiley & Sons Inc., 1994.

Gould, J.D., Lewis, C., "Designing for Usability: Key Principles and What Designers Think," Communication of the ACM, Vol. 28, No. 3, March 1985.

Brockmann, John R., Writing Better Computer User Documentation: From Paper to Online, New York: John Wiley & Sons Inc., 1992.

Watts, Doris R., "Creating an Essential Manual: An Experiment in Prototyping and Task Analysis," IEEE Transactions on Professional Communication, Vol. 33, No. 1, March 1990.

"User-Centered Information Design for Improved Software Usability" (0-89006-946-8) by Pradeep Henry is available through Artech House Publishers. The cost is $19.

---

This article is excerpted from "User-Centered Information Design for Improved Software Usability," by Pradeep Henry, Artech House. It deals with a major issue in software development that is often overlooked: How usable is the end product?

This week's Embedded Focus deals with the latest software/tool developments for embedded systems and reveals how difficult it can be to just get a segment of code right. Henry points out that even if this task is done well, the final product may fail to be useful due to problems in integrating software components into an effective user interface. He suggests that software project managers should attack the problem with a comprehensive "Information Architecture" centered on end-users needs. Called "User-Centered Information Design," the process needs to start even before the software and documentation is written in order to ensure the quality of the end product.

The book is available through Artech House at www.artech-house.com.