Dan Bjorkegren

 

In The Nurnberg Funnel, John Carroll writes,

 

The first salient component of experience with a computer is being overwhelmed. Computers are novel and complex. Still, it is amazing how rapidly new users go from being excited and expectant to being lost and frustrated. (23)

 

Computers are hard to use; computers are overwhelming. Computer manuals reflect the inner workings of the software industry: the heated politics, the short product lifecycle with its ‘get the product out the door’ mentality, and the market-driven emphasis on features rather than benefits. In addition, users’ poor previous experiences with documentation shape their expectations for their next purchase. Users don’t know what their computers can do, and their manuals won’t tell them. Ultimately there is a fundamental disconnect in the computer industry: software developers don’t understand users, and users don’t understand software.

 

Software is Recursive

Computer documentation is intensely shaped by the patterns of the computer industry, the short product life cycles and emphasis on profit. We will analyze computer documentation, and more specifically, the software manual, by looking at what Paré and Smart call the 'four dimensions' of genre (147)—a set of texts, composing processes, reading practices, and the social roles of readers and writers. Our set of texts is software manuals, written for various markets and audiences. Our investigation will take us behind the scenes of the software industry—looking at how the organization of the industry affects the composition of documentation. Further, we will see how the readers—the users—struggle to understand not only the final product and documentation, but also, more importantly, their own role as consumers. To begin our study, let us consider a statement about documentation made by usability guru Jakob Nielsen:

 

“Nielsen's first law of computer documentation is that users don't read it.”

 

John Carrol writes about how usability studies can only be done with completed products: only after a product has made it to the market can the product and its manual be evaluated from their users’ standpoint. So most users have had a bad experience with ‘bleeding edge’ products and their poorly designed manuals. These users realized that documentation wasn’t useful, and they lightly put it down and stopped reading it. When companies realized that users weren’t reading documentation, they gave up trying to produce quality documentation. When users saw this next set of documentation that was not only useless, but poorly made to boot, they lost all hope in documentation solving their problems. On the most basic level we have users who don’t read manuals because manuals are useless, and companies who produce useless manuals because users don’t read them.

Further, manuals are simply a reflection of the software they describe (many are not very good mirrors, but they are mirrors nonetheless). The ‘80-20’ rule of software development fundamentally influences how software, and thus manuals, are developed. Initially, software companies realized that 80% of their users were using only 20% of the capabilities of their products. Companies now use this observation to develop their software, designating whether each feature they add will go into the 80% or the 20% user bucket. The 20% of features designed for 80% of the users will be refined for the lowest common denominator, and the rest of the features (all 80% of them) will remain unrefined—software companies assume that they will only be used by ‘power users’ who can figure out computers by themselves, and don’t bother making them easy to use. So that’s why you stare in awe as your neighborhood computer expert sits down and magically transforms your Excel data or digs into the operating system’s internals to solve that problem with your modem: those features weren’t designed for you, and your computer, or at least 80% of it, was not designed for you. So people don’t understand software because software is hard to use, and software is hard to use because people don’t understand it.

Yet the most disturbing problem about software design in general is backwards compatibility. In updating products, software developers try to both keep existing customers satisfied and gain new customers. In “When good interfaces go crufty,” Matthew Thomas writes about the problems that crop up when software developers try to maintain this fine line: creating software that is easier for new users to use means breaking the patterns to which existing users are accustomed, but satisfying existing users means making it more difficult for new users. So a company may release a poorly designed piece of software, and its initial users may struggle to learn how to use it. Now when the company decides to ‘improve’ the software and make it ‘easier’ to use, the existing customers will object—they have put time into learning the software already and don’t want to have to relearn, even if it is easier to use. Thomas writes about the ubiquitous ‘Save’ button as an example. It would easier for users if they didn’t have to understand that what they see on screen is stored in memory which is separate from what is saved onto permanent storage when they press the save button. “They don’t have to ‘save’ when using a pencil, or a pen, or a paintbrush, or a typewriter, so they forget to save when they’re using a computer.” Why the save button? Thomas answers, “In the 1970s and early ’80s, transferring documents from a computer’s memory to permanent storage (such as a floppy disk) was slow. It took many seconds, and you had to wait for the transfer to finish before you could continue your work. To avoid disrupting typists, software designers made this transfer a manual task. Every few minutes, you would “save” your work to permanent storage by entering a particular command.” But our modern computers are more than capable of saving changes every few minutes, or even every few seconds; this is a 'feature' that is no longer necessary, rather it detracts from the user's understanding of the system. So our software is hard to use because our software was hard to use.

We see deep recursive patterns of misunderstanding between software producers and users in computer documentation and software itself. Why do we see these problems? Unlike other genres, where writers and readers dynamically interact and understand each other, the readers and writers of computer documentation are separated by a void. Anis Bawarshi describes genre as “a state of mind a reader assumes” (345) when confronted with a text; for computer documentation this state of mind is of fear, insecurity and intimidation. Users aren't sure what to expect from a manual. Worse, users aren't sure what to demand. Users automatically assume that tech companies know what they are doing—that if other people can understand and use these products, something must be wrong with me, the simple user. Since users don't feel empowered to make demands of tech companies, tech companies don't know what users want, what they don't understand, or what needs further explaining. Tech companies produce manuals that are not all that useful to the end user, and many users end up buying other, additional books. But this won't financially hurt a tech company. What will hurt, however, is if users cannot figure out how to set something up, and call tech support, or worse, send the product back, thinking it defective. Tech support is expensive, and a wise company (like Microsoft) will make design decisions about its future products based on what the support department is spending most of their time explaining to users. So indirectly, there is a connection between the users and the software developers. But this indirect connection—tech support—is intimidating and frustrating to the user—not an environment that fosters the teamwork necessary to produce a better product. There is a definite void between the user and the developers. If we could eliminate this void, what would the manual look like?

Documentation’s Identity Crisis

What is the manual? What should it tell us, the user?

Nobody knows. Users don’t know what to expect; companies don’t know what to produce. Should the manual be a collection of step by step tutorials that demonstrate the features of the product? Should the manual simply describe the features of the product? Should the manual be a marketing document that flaunts snazzy features and trash talks the competition? Almost as important as the format of the manual is who it is written by. You will read a much more honest account of the shortcomings of Microsoft software from a book written by IDG in the “For Dummies” series than from a book written by Microsoft Press. Also fundamental is the audience of both the documentation and the software it describes. Software like Microsoft Office will have a more general business audience—generally an audience that doesn’t refer to the manual, but rather to a resident expert or an IT department. Professional graphics software users, on the other hand, generally small studios, must take on the task of learning the idiosyncrasies of software themselves by using the manual or training books. And then we have the home user, about whom we can assume almost nothing.

Let's discover good manual design by looking at bad manual design. I noticed that the Office XP manual was organized more like a marketing document, showcasing features and benefits, than like a useful piece of documentation written for users. This is largely due to Microsoft’s focus on the business user rather than the home user. Most home users make their own purchasing decisions, but management makes business users’ decisions. In general, management is used to working with marketing materials. To test my observation about the organization of the manual, I gave the manual to a user familiar with Microsoft Office and Excel and asked him to tell me how I could highlight outlier data points, points that are outside the range of expected values, and make them stand out in an Excel sheet. First he looked for an index in the back of the manual, but found none, then started at the beginning of the book at the table of contents. In the Excel chapter there was a promising section entitled “Reporting and Data Analysis”—which offered no help in finding the feature he was looking for. He browsed through the Excel chapter, looking for the feature on every page, and found nothing.

What he was looking for was a feature in Excel called “Conditional Formatting,” which applies special formatting to cells that satisfy an inequality (for example, it could make cells that have values greater than $100 boldface with a yellow background). Although this feature was fully covered in the manual, it was organized under the heading “Creating Conditional Formatting,” a vague description that didn’t clearly identify the section’s contents and meant nothing to the user. Similarly, a feature in Word that makes it faster to align text was hidden in a section entitled “Using Click And Type.” The manual is not organized from the user's point of view, but rather from the product creators' point of view—it showcases features rather than benefits—and thus is completely unapproachable for users who aren't familiar even with what their software can do, much less with what the features are called.

Microsoft’s Office XP manual is designed to be read cover-to-cover. Realistically speaking, that is the only way a user would be able to find features like conditional formatting. However, this design flies in the face of the next bit of wisdom from Jakob Nielsen:

“The second law is that if [the users] read [the computer documentation] anyway, it's because they are in deep trouble and need the answer to a specific problem. Thus, somebody reading a manual won't really read it cover-to-cover.”

The Office XP manual is organized backwards for real users. Users won’t come to the book looking for a description of the feature entitled ‘conditional formatting,’ but rather they will come with a description of a feature that they suppose the software may have and look for the title. This is not just a documentation problem: the software itself is designed backwards, without concern for what the user is actually looking for. More generally I want to make my document look more lively, not choose a ‘Font.’ I want to organize my information, not ‘Create a New Folder.’ I want to put my document on the web—or even better—to simply share it with my friends, not ‘Save as HTML.’ As a user, I am concerned with the end product, not the intermediate operations required to produce it. I want to tell my computer what to do, in the most general terms possible, not how to do it. So my software programs, with their menus full of intermediate steps, are designed backwards.

But it gets worse. Not only are features unapproachable because they are organized backwards, applications themselves are organized backwards. You don’t get to tell your computer, ‘I have some data here and I want to visualize it’; you have to tell your computer to launch ‘Excel.’ But launching Excel presupposes that you know what Excel does. So our applications are in the same boat as our features: they are organized by the intermediate operations, not by the end product. The picture becomes even more muddied when there are, as frequently occurs, more than one way to produce this end product. How can you recommend one method over another, when in the user’s eyes they do the same thing?

This, then, is the fundamental, oft overlooked struggle with the manual: explaining what features do and describing the differences between different methods of producing the same result, without explaining in nitty-gritty detail how the features work. And then the challenge of user interface design is telling the user what is going on, without requiring knowledge of how it works. Your computer should also give you the freedom to either ‘fine tune’ the intermediate steps to produce an end product or simply specify what the end product should look like.

 

Objects and Mindsets

                  The 1980s saw a revolution in software development. Earlier, software had been constructed out of functions, which do things, and data structures, which store things. The new model, object-oriented programming, put functions and data structures together, into objects. This model clarifies how operations work on data, but requires a completely different mindset for the developer. Object-oriented programming requires the developer to think in terms of objects; in a drawing program a developer might build Rectangle, Ellipse, Polygon, and Text box objects that users can create and manipulate. One of the goals of object-oriented programming is encapsulation: what an object does (its external representation) should be independent of how it is built (its internal representation). This is not only a fundamental concept in programming, but user interface design as well: the user should not need to know how their computer works in order to use it.

                  Although developers have the capability to produce software whose interface makes sense to the users, and whose design makes sense to the developers (with encapsulation), they don't. Microsoft DOS, built back in the days of functional programming, presents itself to the user as a bunch of functions that operate on data. Microsoft Windows, on the other hand, presents itself to the user as a bunch of objects—files, disk drives and applications—and operations—delete, move, copy, and open. Yet Windows is not constructed out of object-oriented code. So the reason that Windows presents itself to the user as objects is not technical—it is built out of the same type of code DOS is—rather, the developers of Windows simply thought in terms of objects. This new encapsulation concept did a good job of separating how Windows presents itself to the user from how it is actually built; yet it presents itself to the user as a collection of objects because programmers now think in terms of objects—not because users do. Most workers in the software development industry know at least something about how to program—even at the managerial level. An entire development team may agree that their user interface is sensible, or even natural, to use—because these people think like programmers, not users. To varying degrees, you have to get into the programmer mindset in order to use software.

                  The simple solution to the interface design (and manual design) problem is to connect frustrated users to the software development teams. This is difficult when users have 'resident computer gurus'—when they know someone who understands how computers work—because asking a friend for clarification about a concept that doesn’t make sense means that the company who built the product won't get feedback. The company that learns how to make tech support friendly or even fun will get these customers' input and be able to design products for users instead of programmers.

Conclusion

                  Ultimately, there is hope for the computer industry: computers do not have to be difficult to use. Yet in order to make these devices easier to use, what is required is a complete shift in perspective and assumptions—it is not possible for developers who assume computers are hard to use to produce one that is easy to use. Maybe it is due to this mental shift that Apple Computer products—which, though well designed, are not that different from IBM/PC products—are considered ‘easy to use’. It is not the technology per se, but rather the mindset that the user assumes in approaching the technology, and the mindset that the developers assume in producing the technology. That’s not to say that computers are simple, however. The computer industry is looking at the greatest challenge in the history of technical communication: bringing complex technology into the homes of laypeople, users we can make little or no assumptions about (other than that to function in society they must be able to use technology). So it’s an exciting field, full of potential, especially if we consider the adage, ‘if you’ve hit rock bottom, the only way you can go is up.’

 

Bibliography

Bawarshi, Anis. “The Genre Function.” College English62.3 (Jan. 2000): 335-360.

 

Carroll, John M. The Nurnberg Funnel: Designing Minimalist Instruction for Practical Computer Skill. Cambridge: MIT Press, 1990.

 

Discovering Microsoft Office XP Standard and Professional. Microsoft.

 

Nielsen, Jakob. “In Defense of Print.” Alertbox. http://www.useit.com/alertbox/9602.html Feb. 1996 (Nov. 29, 2002)

 

Paré, Anthony, and Graham Smart. “Observing Genres in Action: Towards a Research Methodology.” Genre and the New Rhetoric. Eds. Aviva Freedman and Peter Medway. Bristol, PA: Taylor & Francis, 1994. 146-154.

 

Thomas, Matthew. “When good interfaces go crufty.” mpt. http://mpt.phrasewise.com/stories/storyReader$374 Nov. 9, 2002 (Nov. 30, 2002).