http://tc.eserver.org/dir/Articles/Documentation/Usability A listing of the most recently indexed works about Articles and Documentation and Usability in the field of technical communication. en-us Copyright (c) 2005-08 by the EServer. All rights reserved. tclib-editorial@eserver.org (TC Library Editorial Board) webmaster@eserver.org (Geoffrey Sauer) http://tc.eserver.org/images/newlogo.gif http://tc.eserver.org/dir/Articles/Documentation/Usability http://tc.eserver.org/35707.html http://tc.eserver.org/35707.html Listen up open source developers, if you want your project to succeed you’re going to have to do more than write great code; you’re going to have to document it, teach new users how it works and provide real-world examples of what you can do with it. That’s the message from Jacob Kaplan-Moss, one of the creators of Django, a very successful open source, Python-based web framework. At least some Django’s success can be attributed to its thorough documentation which is not just reference materials, but also includes tutorials, topical guides and even snippets of design philosophy. http://tc.eserver.org/35679.html http://tc.eserver.org/35679.html How can you guarantee a clearly understandable user manual? Is it even possible to measure the quality of technical documents or does comprehensibility merely depend on the reader? To answer these questions for the Porsche AG, content analysis provider semiotis³ developed a model to help measure the quality of documents. http://tc.eserver.org/35285.html http://tc.eserver.org/35285.html When the subjects of usability and user friendliness in relation to documentation are broached, writing isn’t often the first thing that comes to mind. But it should be. http://tc.eserver.org/35195.html http://tc.eserver.org/35195.html For simple, commonly known actions in a closed environment, you probably can design your way to a “no user documentation” approach. Good design can also lead to less documentation. However, customers may expect to do more than that with a product and, in those situations, documentation can play a key role in meeting those expectations. http://tc.eserver.org/35082.html http://tc.eserver.org/35082.html Usability is the combination of effectiveness, efficiency, and satisfaction with which the users accomplish defined goals in a given environment. User-centered documentation matches the users' mental model, thereby helping the users find information they want quickly and easily in their hour of need. The list of documentation usability criteria is fairly subjective at this time, and various opinionated discussion groups have contributed to this. Usable documentation is based on a deep understanding of the users' tasks, and this understanding can only be gained through interviewing representative users. Applying information architecture techniques, the content within documentation should be properly chunked so that the users can assimilate the information properly. Procedural guides should have a well-defined and searchable index that enables users to connect key application terms to their correct context. User-friendly documentation is always succinct, but never at the expense of omitting critical/useful information. It should be developed using a structured process so that it starts with the big picture and gradually adds lower level of details, addressing the needs of every unique group of users. Finally, the documentation must be tested among a representative group of users, and their feedback should be incorporated to make sure that it has met all of the major usability criteria. http://tc.eserver.org/34637.html http://tc.eserver.org/34637.html Even though your customers may not read manuals, your tech support team probably does, which means someone is reading the manuals and using them to help others. But if your users find it easier to call someone, wait on hold for an agent, and then ask the agent a question rather than find the answer in the help, maybe your help materials aren’t very usable. Maybe increasing the usability of your company’s documentation could alleviate the need users feel to seek answers from another source. http://tc.eserver.org/34586.html http://tc.eserver.org/34586.html Finding information in documentation is easy. Or is it? This blog post argues that there's no universal solution, and that each document and each delivery method offers challenges and requires a slightly different solution. http://tc.eserver.org/34506.html http://tc.eserver.org/34506.html Context-sensitive help is a practical way to cut down on customer support expenses and add more value to documentation. By providing more complex, context-sensitive help, the usability of the help increases while call center phone calls decrease. http://tc.eserver.org/34507.html http://tc.eserver.org/34507.html Makes the case for embedded help as one of the most effective ways to integrate help within an interface. Although it can be difficult, Bleiel illustrates a way to “elegantly implement and map embedded help.” http://tc.eserver.org/33339.html http://tc.eserver.org/33339.html This article explains the relative merits of paper and online documentation from a usability perspective. First, we look at the different types of user. Then we look at typical paper documentation and online documentation with respect to these user types. Finally, we present the relative merits of paper and online documentation for different user types. http://tc.eserver.org/32978.html http://tc.eserver.org/32978.html Computer documentation is shoddy, or more often absent. Missing information amplifies usability problems, leaving users stuck calling unfriendly technical support lines. In this installment of The cranky user, Peter Seebach explains what's missing in the documentation effort and why it is gone. http://tc.eserver.org/32823.html http://tc.eserver.org/32823.html Your product's unexplained features can turn into costly flaws. This article describes three real-world products with just such "features." It presents ways you can prevent these feature-to-flaw conversions by improving the User Documentation for your products. http://tc.eserver.org/32382.html http://tc.eserver.org/32382.html Blame it on poor usability or just not reading the frickin' manual, but it turns out that 95 percent of all returned gadgets actually work despite what customers may say or think. That's right -- of the $13.8 billion worth of returned products in 2007, only 5 percent were because gadgets were truly broken. According to Accenture, 68 percent of all returns work but aren't meeting customer expectations -- or they are simply too confusing to use. http://tc.eserver.org/32144.html http://tc.eserver.org/32144.html In my work with Bumblebee I use an approach I call 'User-Guide-Driven Development,' or UGDD for short. The mechanics of UGDD is similar to that of Test-Driven Development (TDD), but before I write the test for a feature, I write a snippet of the user guide describing the feature I am about to implement. http://tc.eserver.org/31738.html http://tc.eserver.org/31738.html Have you ever asked your users what kind of training materials they want, or how they prefer to learn software? This kind of information is critical to figuring out what help deliverables to produce. But really when it comes down to it, there are only so many options — printed manuals, short guides, interactive flash guides, videos, online help, live training, reference cards, context-sensitive help, workbooks and exercises, or, usually the favorite, someone to stand by their computer and answer questions whenever they need help. http://tc.eserver.org/30826.html http://tc.eserver.org/30826.html According to Jacob Nielsen's How Users Read on the Web, usability of web content can be improved drastically by making content more scannable. Many of his ideas would apply equally well to online help. So, how can technical writers leverage this information to make the help for their product more usable? http://tc.eserver.org/30790.html http://tc.eserver.org/30790.html The three disciplines of usability, testing, and documentation are important to the success of hi-tech products. These three areas are often overlooked, but they have a profound affect on the end user's experience of a software product. As customers become more perceptive about IT, their expectations rise. Since customers now have more choice than ever, to be successful, a software product needs to stand out from the crowd. This article explains why the three disciplines are important to the overall success of a software solution. It concludes with recommendations for obtaining the best return on investment. http://tc.eserver.org/30637.html http://tc.eserver.org/30637.html User assistance is defined as a form of assistance that is provided to users of products to help them use the products more easily and efficiently. In the Information Technology industry, a product is a software product/application that users use to perform specific business functions. Users of these products/applications use them differently, based on their social and philosophical environment, their cultural context, their learnability and a number of other factors. While the same user assistance must necessarily be designed and delivered to the users of a product, because all users use a particular product/application to perform similar tasks, user assistance can be designed and delivered differently to users, based on their social and philosophical environment. This could enable users from diverse social and philosophical backgrounds use the same products/applications more effectively. http://tc.eserver.org/30602.html http://tc.eserver.org/30602.html Different types of usability tests can be performed at different phases in the product development cycle for different reasons. Writers can plan and implement a usability test and then incorporate recommendations into their documentation, thereby improving its usability. You can improve the usability of your documentation by performing one or more types of usability tests, no matter the size of the product or the time frame involved. http://tc.eserver.org/30571.html http://tc.eserver.org/30571.html Producing online documentation requires a new view of a technical communicator's roles, skills, and responsibilities. http://tc.eserver.org/30574.html http://tc.eserver.org/30574.html 'Know your user!' is the first thing every aspiring technical communicator learns. Everyone agrees that understanding the technical skills and needs of your audience is essential to producing high quality technical documentation. However, knowing exactly who your audience is and what they need from documentation is no longer an easy task. The increase in international markets, multiculturalism in America, end the number of people using software products for the first time all mean that the audience you knew so well a short time ago may not be the same audience using your documentation today. As technical communicators, we can no longer assume that our users' language and technical skills remain stable over a long period of time. How to assess and meet the needs of a changing audience is a challenge many technical communicators face today. http://tc.eserver.org/30327.html http://tc.eserver.org/30327.html The following is a brief description of how I tested a user manual for a word processing program to be used by low-level and intermediate-level users. http://tc.eserver.org/30315.html http://tc.eserver.org/30315.html People who follow the right trends will someday lead them. Such an opportunity now lies in the hands of technical writers, as the computer field moves toward standardized, graphical, easy-to-use interfaces. http://tc.eserver.org/30113.html http://tc.eserver.org/30113.html PDF is a perfect format for assembling technical materials, so how can a PDF document work more like a standard three-ring binder? Here's how. http://tc.eserver.org/30077.html http://tc.eserver.org/30077.html Is your documentation and training a solution for complex product design? Whether designing software, hardware, documentation, online help, or a telecommunication network, a strategy for usability is essential to user-friendly design. Every organization has a product life cycle but not every organization is user-focused because of absence of a usability process. Where do you begin? This paper describes two ISO standards that I have used as a strategy for usability, and accompanies a presentation that demonstrates how to put the standards to practice. http://tc.eserver.org/30279.html http://tc.eserver.org/30279.html Writers who must edit their own manuals for ease of use can adopt three basic principles for doing so. The first principle, 'give the user a map,' helps users find information in an unfamiliar manual. The second, 'start from the user's viewpoint, ' presents information in the order the user needs it. The third principle, 'keep it simple,' puts complex data in simpler terms and formats. http://tc.eserver.org/29691.html http://tc.eserver.org/29691.html Software products are tested. Hardware products are tested. But, how often and how thoroughly are the information deliverables tested? In the rush to bring products to market, the full and thorough testing of information often gets overlooked. Last minute changes are crammed in. Procedures are not thoroughly tested. Even something as simple as testing links can be ignored due to lack of time or resources. http://tc.eserver.org/30289.html http://tc.eserver.org/30289.html Online documentation often seems to be a panacea for our difficulties in providing usable documentation. Scholars and practitioners alike provide a steady stream of new ways to apply, structure, categorize, choose, and develop online documentation. However, empirical evidence, either for or against many of these ideas, is still lacking, leaving us guessing about which concepts will truly help our users and which will be technical communication's Edsels. Recent studies show conflicting information about the key usability factors in online documentation, but do offer some hints of where to begin. This article will help technical communica- tors apply theory by summarizing recent empirical studies about online documentation usability. http://tc.eserver.org/29126.html http://tc.eserver.org/29126.html This study investigates whether Iconic Linkage--the use of the identical wording to present the same information recurring in a text--can improve the usability of user guides. Iconic Linkage is a writing strategy that potentially allows users to work more quickly and effectively and which promotes better retention of information. The usefulness of Iconic Linkage was tested in a laboratory-based usability study that combined: 1) objective task-based evaluation; and 2) users' subjective evaluations of a software program used in recording parliamentary debates. A post-test survey designed to test subjects' retention of information contained in the user guides was also administered. The study shows that Iconic Linkage significantly improved usability of the user guide: in all tasks, subjects worked more effectively and made fewer mistakes; while in the three timed tasks, subjects completed the tasks much more quickly. Subjects also gave higher ratings for the software and their retention of information was noticeably improved. http://tc.eserver.org/29049.html http://tc.eserver.org/29049.html Traditional models of usability assume that usability is a quality that can be designed into a particular artifact. Yet constructivist theory implies that usability cannot be located in a single artifact; rather, it must be conceived as a quality of the entire activity in which the artifact is used. This article describes a distributed approach to usability, based on activity theory and genre theory. It then illustrates the approach with a four-decade examination of a traffic accident location and analysis system (ALAS). Using the theoretical framework of genre ecologies, the article demonstrates how usability is distributed across the many official and unofficial (ad hoc) genres employed by ALAS users. http://tc.eserver.org/29067.html http://tc.eserver.org/29067.html Elderly people seem to encounter more problems than people from other age groups do, when using consumer electronics products and their accompanying manuals. This may be due to the absence of some kinds of information. In this study the effects of the absence of different information types in instructions on action performance were explored for different age groups. Younger (aged 20-30 y.) and elderly (aged 60-70 y.) participants installed a VCR with the help of the manual, while working aloud. The absence of goal information, consequence information and identification information in the instructions proved to have a negative effect on task performance, especially for the elderly participants. When one of these information types was missing in the instructions, the elderly performed more actions incorrectly than when the information was stated explicitly. http://tc.eserver.org/28493.html http://tc.eserver.org/28493.html A 'user edit' (also known as a 'usability edit') enables you to evaluate the usability of documentation (Schriver, 1991). Participants in a user edit study can either think aloud as they use the documentation to complete tasks or they can mark up the pages of the documentation to indicate where they had problems. The think-aloud protocols or marked-up pages are then reviewed for usability problems. The user edit report lists the problems and recommendations about how to improve the usability of the documentation. http://tc.eserver.org/27807.html http://tc.eserver.org/27807.html What makes documentation usable? Usable documentation accommodates the way I think. Hart summarizes his principles for define 'user-friendly documentation.' http://tc.eserver.org/27580.html http://tc.eserver.org/27580.html As I write the 'how to' documentation based upon the in-process design, the weaknesses of my original design become apparent and I go back and forth from writing text to designing the software until it all flows. http://tc.eserver.org/27544.html http://tc.eserver.org/27544.html This study compared two evaluation techniques, Usability Testing and Cognitive Walkthrough, in their ability to identify errors in aviation maintenance documentation. The techniques were evaluated to see how much unique information they each produced as well as the type of errors identified. Results showed that the techniques were complementary in their findings and both are recommended in the development of technical documentation. http://tc.eserver.org/27545.html http://tc.eserver.org/27545.html This article describes the Evaluation Toolbox (Chaparro et al., 2004) - an aid to understand the process of evaluating the usability of aviation maintenance documentation -- from the initial development stage through the final pre-publication stage. This toolbox provides techniques to help technical writers better understand their users and to evaluate their documentation more effectively and efficiently. http://tc.eserver.org/26720.html http://tc.eserver.org/26720.html This article takes a look at a methodology for developing and managing a Software User Assistance (UA) System, a way of doing things in a structured manner. It provides a complete walkthrough for managers responsible for designing, developing, and managing a software product’s user assistance system. The software’s UA system could comprise of both paper-based user manuals and online help systems. http://tc.eserver.org/26400.html http://tc.eserver.org/26400.html To successfully communicate to users, documentation must do more than meet the user’s information needs, it must present the information in the same way the user processes the information. The design of software and it accompanying documentation must be reconceived so that the design is done from the problem-solver’s point of view. http://tc.eserver.org/26402.html http://tc.eserver.org/26402.html Customer-feedback concerning product documentation is an 'artifact' of value. Product/project management depends on documentation groups to play an active role in closing the feedback acceptance and incorporation cycle to the best satisfaction of the sending-customer. http://tc.eserver.org/25904.html http://tc.eserver.org/25904.html Professionals are increasingly working in networked teams where electronic media and asynchronous communication play an important role. So how can communication behaviours in these contexts predict usability? Do efficiency, effectiveness and satisfaction in the communication process lead to the same for the resulting documentation? http://tc.eserver.org/25163.html http://tc.eserver.org/25163.html The technical communication community can no longer be satisfied to produce documentation that scores high in quality but low in effectiveness. We must use whatever means necessary to ensure our users reach their goals with as few obstacles and distractions as possible. This will require us to change the very nature of our work, from simply documenting complexity to designing collaborative systems. Our ultimate goal is not to write a better manual or online help system or web page, but to ensure that human beings and products can work together effectively to achieve common objectives. http://tc.eserver.org/25139.html http://tc.eserver.org/25139.html Documentation is a finger in the eroding dam of an unusable product. http://tc.eserver.org/24816.html http://tc.eserver.org/24816.html This panel will discuss usability analysis, user testing, and revision of a medical instruments manual. The study showed that a hidden audience constituted the real users of the manual and that that audience served as an unintended intermediary between the writers of the manual and the users of the instruments. Usability testing showed the merits of a design for the manual that served both the intended and unintended audiences. http://tc.eserver.org/24369.html http://tc.eserver.org/24369.html This presentation and demonstration will first establish the principles behind usability testing of the documentation, then show examples of lessons learned from testing both print and online documentation. Video clips of actual tests will be used to make some compelling points. The session will be especially useful to those who are interested in usability testing but haven't done it yet. http://tc.eserver.org/24279.html http://tc.eserver.org/24279.html Through the completion of an independently researched and developed academic proposal, this author demonstrated the need for change in academic instruction and the need for working technical communicators to extend their skills by recognizing the connection between usability testing and editing online documentation. In short, the underlying connection between these two processes is that, in order to edit online documentation effectively, the editor must know the basics of usability. This paper discusses the background, the methodology, the results, and the implementation of this research project. http://tc.eserver.org/23764.html http://tc.eserver.org/23764.html It would be useful to determine how much effect errors in product documentation have on users, if the errors do not seriously interfere with product use. In an effort to start collecting information on this issue, we designed an experiment to explore the reactions of users to a simple interactive program with flawed documentation. We hypothesized that product quality would be judged in part by the quality of the documentation, if the errors in the documentation interfered with task performance. We also hypothesized that some but not all users would be sensitive to documentation errors and would downgrade their rating of the program and the documentation based on these errors. Our experimental design is described in this paper. http://tc.eserver.org/23564.html http://tc.eserver.org/23564.html How do I effectively include usability as a part of developing online and printed documentation? http://tc.eserver.org/23566.html http://tc.eserver.org/23566.html The term 'easy to use' is typically used in connection with the user interface of software applications. However, the term can also be used to describe documentation, referring to techniques of organization, layout, or design that make information both easy to understand and easy to find. As the technology associated with documentation moves toward online and multimedia documentation, the concept of ease of use becomes even more important and relevant. In this paper, we address some of the differences between paper and online documentation that impact the development of easy-to-use online documentation, and outline some of the high-level, emerging issues to be aware of in the development of multimedia documentation. http://tc.eserver.org/23403.html http://tc.eserver.org/23403.html Despite the fantastic development of computers and software, the paperless society seems to be far from implementation. On the contrary, the consumption of paper for documents has increased over the recent years. http://tc.eserver.org/22847.html http://tc.eserver.org/22847.html This paper covers the usability testing of a prototype digital library. The library holds technical manuals for scientific instruments. Findings show test subjects can locate desired documents faster with this digital library than a corresponding paper library. However, the same subjects can locate desired information faster in a paper document than a digital one. Finally, most subjects reported they would prefer to using the online library of technical documents over the library of paper ones. http://tc.eserver.org/22829.html http://tc.eserver.org/22829.html A retrospective look shows earlier advice still relevant to both predicting and producing readable writing. For prediction, refined readability formulas with stronger criterion passages and updated familiar -word lists have appeared, although the computerization of readability tests sometimes encourages misapplying or misinterpreting them when screening text. For production, attention to sentence construction, word characteristics, and information density remains relevant to both drafting and revising computer documentation for readability, especially since reading speed and reader preference often interact with comprehension in practical settings. http://tc.eserver.org/22169.html http://tc.eserver.org/22169.html Describes how one company approaches usability testing of documentation and incorporates usability testing into its writing process through a Documentation Usability Team. http://tc.eserver.org/21543.html http://tc.eserver.org/21543.html This article, which appeared in the Dutch journal Tekst[blad], describes four recent studies that are relevant to help developers, and suggests how help developers can use the knowledge gained from those studies to improve the performance support systems they build. http://tc.eserver.org/21382.html http://tc.eserver.org/21382.html This article shows how a user-centred approach to software design can reduce the requirement for documentation. It lists Jakob Nielsen's usability heuristics, and for each one, shows how following the heuristic can reduce the requirement for user documentation. http://tc.eserver.org/21026.html http://tc.eserver.org/21026.html A few years ago, the NeXT user publications group was handed a charter to create casual books with personality. We were also told to condense the user documentation for an entire operating system and several bundled applications into 300 pages. And of course we had the top priority of creating accurate, complete, and easy-to-use documentation. To our delight, these goals ended up being mutually compatible. The keys? Task orientation, flat hierarchy, carefully crafted page design, illustration, and a casual, intelligent tone. We also broke some 'rules'! (Caution: Some of the following material may seem radical to seasoned traditionalists.) http://tc.eserver.org/21023.html http://tc.eserver.org/21023.html Often in the computer industry there is a tendency to provide information about the features of a system. However, customers usually purchase the system based on knowledge of its features, when they receive the product they need information on how to accomplish tasks. Developing task-oriented information requires a shift in perspective from what the computer technology can do, to what your customers want to do with the technology. The resulting information must be usercentered rather than feature-driven. These types of customer requirements demand afresh development approach. http://tc.eserver.org/20851.html http://tc.eserver.org/20851.html The reduced reading speed on computers can be compensated by good hypertext design that allows the user to read less information and to find it faster. A typical example is online help and documentation: because the information is right there on the computer, there is no need to spend time finding the hardcopy manual, and because of good search tools and hypertext links between related information, users can go directly to the one or two sections that contain the answer to their problem. After all, Nielsen's first law of computer documentation is that users don't read it. The second law is that if they read it 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, so online presentation makes perfect sense. http://tc.eserver.org/20839.html http://tc.eserver.org/20839.html A collection of hints and advice about documentation and usability from David Orr (one of our Institute instructors and the founder of the first usability lab in Chicago). http://tc.eserver.org/20727.html http://tc.eserver.org/20727.html Rockwell Software is a $90-million company specializing in plant automation software. Offices in West Allis, Wisconsin, and Mayfield Village, Ohio allow technical communicators to work closely with development teams to design, test, and release usable, consistent software and information products. While Rockwell Software’s information development process is a multi-faceted endeavor, this paper focuses on the following three steps we implement to create our information products: interviewing customers to establish information guidelines, conducting usability tests, and writing Getting Results guides. http://tc.eserver.org/20364.html http://tc.eserver.org/20364.html This paper questions the ubiquitous practice of supplying minimalist information to users, of making that information functional only, of assuming that the Shannon-Weaver communication model should govern online systems, and of ignoring the social implications of such a stance. Help systems that provide fast, temporary solutions without providing any background information lead to the danger of users completing tasks that they do not understand at all. (Word will help us write a legal pleading, even if we have no idea what one is.) As a result, we have help systems that attempt to be invisible and to provide tool instruction but not conceptual instruction. Such a system presents itself as a neutral tool, but it is actually an incomplete environment, denying both the complexity and alternative (and possibly improved) modes of thinking about the subject at hand. http://tc.eserver.org/20096.html http://tc.eserver.org/20096.html Customer satisfaction studies are valuable tools for developing documentation strategies. Information developers at Compaq Computer Corporation used a satisfaction study to develop a comprehensive strategy for producing online service and support documentation. http://tc.eserver.org/19744.html http://tc.eserver.org/19744.html Many professionals in the field of technical writing involved in the design of instruction guides, will at some point in their career have experienced some doubt whether their efforts to produce high quality documentation really make sense. Do consumers attach some value to the instruction guides for the products they have purchased? Do they use these documents at all, or are most instruction guides thrown away, together with the packing material of the equipment they come with? http://tc.eserver.org/19383.html http://tc.eserver.org/19383.html Details a process for improving the usability, consistency, and organization of user information within businesses that maintain medium to large documentation libraries. http://tc.eserver.org/15226.html http://tc.eserver.org/15226.html Presents several tips for applying traditional usability standards to online help development. http://tc.eserver.org/15004.html http://tc.eserver.org/15004.html Describes two cases in which usability testing and documentation projects were performed in conjunction with one other. It describes how usability testing affected the design and content of the documentation and how follow-on usability studies added significant new data not revealed in the initial tests. http://tc.eserver.org/14998.html http://tc.eserver.org/14998.html Describes two case studies where Tec-Ed leveraged usability research and documentation activities to create solutions that met the needs of both our clients and their customers. http://tc.eserver.org/15006.html http://tc.eserver.org/15006.html Increasingly, online documentation is the only documentation that companies provide with their products. To minimize customer resistance and encourage its use, online documentation (PDFs and help systems) must be at least as easy to use as a printed book. This paper presents a structured process for evaluating the usability of online documentation, based on a list of heuristics for navigating through and finding content. http://tc.eserver.org/12941.html http://tc.eserver.org/12941.html We technical writers have a mantra that we mutter quietly whenever someone asks an obvious question about how to use our software: 'RTFM.' But though Reading The (ahem) 'Fine' Manual would often solve the problem--assuming the purchaser actually received one of those increasingly rare printed manuals with the software--only technical writers seeking inspiration on how to do their own jobs better can be relied upon to read product documentation. To make matters worse, many of us admit that we'd rather play with a product, hoping to figure out what to do, than use the documentation. http://tc.eserver.org/11787.html http://tc.eserver.org/11787.html We all are familiar with Jakob Nielsen's heuristics for evaluating the usability of interfaces. When I was conducting a study on documentation usability, I started wondering if there existed a similar set of heuristics for evaluating the usability of documentation. The natural place to pose such a question was the STC Usability SIG mailing list. The response was that there was no heuristics set available although someone had tried to open the discussion in the mailing list some time ago. An answer, which led to the list of heuristics presented below, was something along the line 'Well, now that you asked, why don't you put the heuristics together' and so I did. http://tc.eserver.org/11772.html http://tc.eserver.org/11772.html When we began discussing this joint issue of Usability Interface and DocQment, we quickly realized that no concise definitions for either usability or quality existed: in fact, there were many definitions for both terms. A query to a usability professionals’ mailing list for a definition produced many varied responses from which a brief working definition of usability can be distilled: A usable product is one that is learnable, efficient, memorable, error-averse, and satisfying. In other words, usability is a characteristic of a product or document. Defining quality is no easier: there are also a variety of answers. A brief working definition might be: Quality documentation is documentation presented in an easy-to-use, straightforward manner with complete glossaries and indexes. http://tc.eserver.org/11751.html http://tc.eserver.org/11751.html It has been an exciting few months, what with the usability flaws in the 'butterfly ballot' in Florida possibly changing the course of history. The good news is that the controversy put usability into the public conversation with news articles, press releases, and even new research articles. It was an opportunity to explain 'what we do' to friends, relatives, and associates. Some of the lessons from the 2000 Presidential election are the basics of Usability 101. http://tc.eserver.org/10571.html http://tc.eserver.org/10571.html In two recent consulting projects, we worked with online documentation developers who wanted to understand the problems users encountered and how their documentation helped solve those problems. To find out, we went and observed users in their own work environments. Although the clients and their software differ significantly, we found similar issues. http://tc.eserver.org/10583.html http://tc.eserver.org/10583.html So you follow all the standards and guidelines, but suffer nagging questions about whether anyone can and will use the help you’ve just written. Or management wants you to move your printed documentation online, but you wonder whether that’s really best for your users. In the course of our consulting work, we’ve done dozens of usability studies that focus on how people use a variety of printed and online documentation, including manuals, help, cue-cards, and wizards. We’d like to share some of our results and observations, in hopes that this will help you make more informed design decisions. http://tc.eserver.org/10576.html http://tc.eserver.org/10576.html Usability testing isn’t just for software and web sites. Testing documentation can ensure that it includes — and accurately conveys — all the information users expect and need. Testing gives you accurate information on how well your documentation and Help work. It can even uncover problems that are better solved by changing the interface. http://tc.eserver.org/10273.html http://tc.eserver.org/10273.html Internal usability reviews, systematic examination of documentation to identify basic usability problems, can improve your ability to address usability issues and solve usability problems. These reviews help you eliminate documentation problems before they become problems for your customer.