http://tc.eserver.org/dir/Articles/Documentation/User-Centered-Design A listing of the most recently indexed works about Articles and Documentation and User Centered Design 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/User-Centered-Design http://tc.eserver.org/35627.html http://tc.eserver.org/35627.html Seth Godin believes that everything reflects what you stand for—right down to your technical documents. Ever looked at Apple’s tech docs? http://tc.eserver.org/35301.html http://tc.eserver.org/35301.html I have no idea what our users want. I do know they want information, and I know they want that information to be kept up to date as our product evolves and as far as those basic needs are concerned, I’m happy that we are meeting them. Beyond that I admit I’m not really that sure. http://tc.eserver.org/34711.html http://tc.eserver.org/34711.html Part of the problem in our attempt to demonstrate value is that our help deliverables look the same as they did 15 years ago, more or less. Online help and a PDF manual. It’s not a format that engages users. The web marches forward with innovation after innovation, while the technical communicators are figuratively hunched over keyboards, staring at CRT monitors, wearing 1950s horn-rimmed glasses, typing away. 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/34638.html http://tc.eserver.org/34638.html In this presentation, Joe Sokohl talks about gathering user research prior to designing and implementing your help deliverables. http://tc.eserver.org/34613.html http://tc.eserver.org/34613.html What FAQ pages have become are elephant graveyards of non-information, the equivalent of the Miscellaneous file folder, the place where information-we-didn’t-know-where-to-put was dumped. The challenge of creating a FAQ page that customers will find useful has several aspects to it, but can be accomplished with a lot of planning and a little strategic work. http://tc.eserver.org/34587.html http://tc.eserver.org/34587.html Although there will always be a need for people to explain technical material non-technical people, Ellis Pratt said, others may be doing it instead, through the formats users prefer. To survive, technical writers may need to morph into content strategists, managing the information in a systematic way rather than merely creating it. http://tc.eserver.org/34444.html http://tc.eserver.org/34444.html Why do product manuals sound formal and stiff-upper-lipped? Why don’t users read manuals? These questions have haunted the precincts of Technical Writing for quite some time now. From what I have seen in Indian writers, I am forced to conclude that English Composition, as we were taught in school, is the culprit. http://tc.eserver.org/34378.html http://tc.eserver.org/34378.html Users would save time by reading the manual, but instead they try to figure the application out themselves and then get lost/frustrated as they end up spending even more time getting up to speed with the application. http://tc.eserver.org/34093.html http://tc.eserver.org/34093.html User assistance can add value to a product or Web service’s business model by influencing how deeply users adopt new features or services. As more products employ pay-as-you-go models like that of SaaS (Software as a Service), the contribution user assistance makes becomes increasingly more important. http://tc.eserver.org/33894.html http://tc.eserver.org/33894.html I should never fully trust anyone on a project. I don’t mean this disrespectfully, because I work with competent, talented professionals. But no one has the full picture of how the application will truly work. The quality assurance (QA) engineer usually has the clearest picture. The program manager and project manager are often living in a slightly different world, full of a vision of how the product should work and how they expect users to interact with it, but sometimes they’re missing important nuances in the actual implementation. The interaction designer builds prototypes and assumes the developers will build them to spec, but since the prototypes are usually HTML-based, and not in Java or .NET, variances are inevitable. http://tc.eserver.org/33865.html http://tc.eserver.org/33865.html In recessionary times, organisations should focus on getting sales from existing customers - so customer retention becomes ever more important. http://tc.eserver.org/32824.html http://tc.eserver.org/32824.html Before you release a product, have some people use it. From these "test users" get solutions to problems, tips and knowledge that would help your real-life Users. Put that information in your User Documentation, and on your product support website. http://tc.eserver.org/32540.html http://tc.eserver.org/32540.html When initiating or expanding the role of user-centered design (UCD) in an organization, consider documenting UCD best practices as they fit within existing processes and the best practice of other areas. Such documentation communicates the role and value of UCD throughout the organization in terms familiar to your organization. Because what best practices means varies from company to company, there is no single way to do this. Here are some questions to consider. http://tc.eserver.org/32349.html http://tc.eserver.org/32349.html Users turn to help to look for a specific question, just as someone consults an encyclopedia for a specific question. No one reads the entire encyclopedia/manual, nor is anyone expected to. Well-written encyclopedias allow users to find information through indexes, tables of contents, alphabetical organization, and search fields. http://tc.eserver.org/32171.html http://tc.eserver.org/32171.html If you document everything, you are giving everything an equal weight. Do that for a complex system, and you are buried in detail. In any system there are some aspects that are more important than the others, key aspects of the system that once understood, will help someone to learn more. The art in documentation is to find how to document these aspects as clearly as possible. In this you emphasize these areas, and leave the details for the code. 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/31893.html http://tc.eserver.org/31893.html In this podcast, Nicky Bleiel says we should talk to as many users as we can — conducting on-site visits, sending surveys, gathering information from Marketing, Support, and other departments — so we can have a better understanding of our users’ needs and the formats and mediums that will work best for them. After completing this audience and needs analysis, we can then go out and create the deliverables that will best serve our users. http://tc.eserver.org/31894.html http://tc.eserver.org/31894.html In this podcast, Joe Sokohl explains how to create user-centered documentation by contacting, observing, and interviewing users to gather information about what types of information they use and the help deliverables they actually want. http://tc.eserver.org/31780.html http://tc.eserver.org/31780.html With all the talk about Web 2.0 and the attendant technologies, are readers actually being better served by documentation now than they were in the past? http://tc.eserver.org/31748.html http://tc.eserver.org/31748.html The gaps in your documentation aren’t there because you haven’t consider a particular level of user; the gaps in your documentation are there because you haven’t considered how one level of user becomes another. How DO you get from Beginner to Expert? 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/30622.html http://tc.eserver.org/30622.html Faced with growing demand from customers for specific courses, addressing only their needs, in very short time-frames, we had to re-examine the way we worked. Patching together one-shot customized coursework was labor-intensive for a non-homogeneous and unsatisfactory result. Each new customer request required repetition of the same amount of effort. With reduced turnaround time and dwindling human resources, a solution had to be found. http://tc.eserver.org/30555.html http://tc.eserver.org/30555.html A features-based approach to documentation is appropriate for reference manuals, where the goal is to provide information on something the reader already knows. This article explores how to meet the needs of the reader when providing documentation for user manuals. http://tc.eserver.org/30491.html http://tc.eserver.org/30491.html From the customer's perspective, an important and visible part of a product or service is its documentation. Bellcore's Technical Publications (Tech Pubs) organization uses a Quality Assurance (QA) program that focuses on enhancing customer satisfaction through delivering high-quality documentation. This program emphasizes a 'network' approach to documentation development, whereby technical writers can most efficiently use the support network of QA reviewers and management available to them. The Tech Pubs QA program draws on the needs of clients and the expertise of technical writers to strive to achieve the highest level of quality possible in producing documentation. http://tc.eserver.org/30505.html http://tc.eserver.org/30505.html In an effort to improve the quality of our documentation, our Information Development department personally visited over 80 of our customers in 10 different locations across the United States. Our goal was to find out what we needed to do to create documentation that would satisfy our customers' needs. We came up with a process for planning our visits, gathering the information from our customers, implementing their requirements, and increasing communication with them. From the visits, we not only made changes that immediately satisfied our customers, but we created an environment for them to work with us as a team. http://tc.eserver.org/30400.html http://tc.eserver.org/30400.html When purchasing complex software products, users frequently receive large quantities of information; however, to use the product efficiently, they need a visually obvious starting point that helps them locate the specific information they need. With maintained With the quantity and diversity of information, customers need to be able to find the information they need without flipping through endless pages. In order to give the users a starting point in all of the printed and ASCII file information. we created a document entitled the Guide to products, users can use the features available with a new release most efficiently if they have an overview of the major changes to the product and to the information about the product. By using visual devices and creating an overview document. for each release, technical communicators can decrease their costs and increase users' productivity. 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/29770.html http://tc.eserver.org/29770.html Technical writers make distinctions between the types of documents they create: user guides, reference manuals, tutorials. But do users really understand these document types? How do users look for different kinds of information--and how do we, as technical writers, make it clear to them what types of information are available? This paper presents results of usability evaluations of documentation for electronic design automation software, showing how a writing team tried to improve the categorization and presentation of document types. http://tc.eserver.org/29166.html http://tc.eserver.org/29166.html A comparative evaluation of two user guides,--the document traditionally used by a company and a model document designed on the basis of research results and recommendations,--was carried out using a number of complementary approaches focusing on the user. The quality and suitability of these documents for the target audience were assessed in terms of content, structure, presence of certain organizational devices (such as headings) and pictures included. The results revealed that the model document was more attractive, more efficient, and better adapted to users' needs, thanks to its modular organization (being structured according to "functions"), a large number of pictures, the presence of headings, and rationalization of the vocabulary used. http://tc.eserver.org/29116.html http://tc.eserver.org/29116.html A significant problem in technical communication is persuading the user that the information is accurate, valid, and useful. All too often, technical communicators treat users as members of their own culture. When authors do consider cultural issues, they often focus on matters such as vocabulary, visuals, and organization. Other strategies, however, can be useful in gaining acceptance of technical information in cross-cultural situations. For example, the communication theory of compliance-gaining offers suggestions for how the technical communicators can adapt the text to enhance user acceptance when communicating to members of their own culture as well as when communicating across cultures. Communicators can use promises, threats, demonstrate positive and negative outcomes, extend friendliness, etc., to develop the text. In this article, I will explain several compliance-gaining strategies authors can use, identify rhetorical strategies they can combine with compliance-gaining strategies, show how these strategies can be effective in a cross-cultural environment by comparing the strategies in two sample cultures, and analyze a brief sample. http://tc.eserver.org/28764.html http://tc.eserver.org/28764.html Discusses a number of trends in the technical writing world, particularly the need to make help more human by adopting conversational tones and addressing the angry/frantic state of the user. http://tc.eserver.org/28686.html http://tc.eserver.org/28686.html Here are some 'truths' we've all heard: 'Documentation is just a band-aid for poor design.' 'Real users don't read manuals.' 'Super users never read anything.' 'Help doesn't.' But are they really true? I've seen some signs of life in the use of documentation for digital products recently. http://tc.eserver.org/28553.html http://tc.eserver.org/28553.html Braun Corporation's home-grown documentation processes served the organization well for its first 50 years as it grew from a local to a nationally-competitive producer of mobility and accessibility products. Now poised to become a global leader in its field, this corporation found its efforts hampered by ineffective and outdated documentation practices, which were hurting the company's competitive advantage. This article describes Braun Corporation's curious mixture of global reach and local isolation. By bringing in a technical communicator with expertise in user-centered design, Braun has begun reforming its formerly exhaustive documentation and communication practices. While technical communicators have incorporated a variety of strategies to develop user-centered and task-based documentation, less attention has been placed on changing the cultures of these organizations. The case presented here represents a shift from establishing documentation procedures to critically assessing and reforming existing procedures for the global workplace, describing the shift from ineffective and exhaustive processes to effective processes with defined goals and measurable outcomes. The article concludes with an inventory for determining whether other organizations are over-documenting processes and products, and offers suggestions for creating better documentation procedures. http://tc.eserver.org/27704.html http://tc.eserver.org/27704.html Should instructional texts be purely technical, with a focus on effectiveness and efficiency, or should they also focus on satisfying and motivating users? Good arguments have been made for paying attention to motivational aspects. But only analyses of existing instructions have been published so far, and guidelines for making user instructions motivational have not yet been studied carefully. This article presents motivational strategies and an experiment to test their effects. The results show that motivational elements have little effect on users’ effectiveness and efficiency in performing tasks, their product appreciation, and their self-efficacy, but they do increase users’ appreciation for the instructions. http://tc.eserver.org/27654.html http://tc.eserver.org/27654.html It's often easy to identify what kinds of error messages don't help users, but it can be tricky to avoid them, and even more of a challenge to create the opposite: error messages that give users a clear indication of the problem, offer information to help them fix it, and provide tips on how to avoid the same situation in the future. This paper details the steps involved in creating understandable, helpful error messages, and suggests ways of communicating the value of good error messages to managers and executives. http://tc.eserver.org/26466.html http://tc.eserver.org/26466.html Information Layering is not new, but it has acquired a new dimension through modern technical and interactive possibilities. Even as of now, this technique can be used to make HTML-help considerably more user friendly. http://tc.eserver.org/25076.html http://tc.eserver.org/25076.html Documentation and information organization are an integral part of video game construction. The video game industry may be one of the directions technical communicators will move toward in the near future. http://tc.eserver.org/25057.html http://tc.eserver.org/25057.html The Documentation Development Department (DDD) of Hitachi has been improving manuals by collecting, classifying, and analyzing inquiries from its customers to the Hitachi Customer Answer (HCA) Center. The HCA Center is a telephone inquiry center established to give quick and clear answers to inquiries from customers who use Hitachi computers. http://tc.eserver.org/24884.html http://tc.eserver.org/24884.html User empowerment offers a strategy for addressing the software end user's needs. The definition of user empowerment emphasizes a user-driven, informationmanagement oriented approach in response to changes that have taken place in the modern workplace after computers and computer software arrived. Working with software requires a significant shift in thinking and learning, responding to increased abstraction, isolation, and information volumes. Computermediated work demands that users develop new skills and job roles, and that documentation writers develop new techniques for manuals. http://tc.eserver.org/24850.html http://tc.eserver.org/24850.html All too often, developers think that documenting their new creations just means writing a detailed technical description of what it does. In a sense, they're explaining things to themselves. But what you really need to do is explain things to someone who's coming across your stuff for the first time. http://tc.eserver.org/24606.html http://tc.eserver.org/24606.html The sensation-perception continuum represents the interplay of sensation and perception in everything we think and do. Technical communicators must exploit this continuum by understanding and applying sensory filters and perceptual tendencies in the design and development of information. This paper discuss three sensory filters: thresholds, cocktail-party effect, and sensory adaptation; it discusses four perceptual tendencies: perceptual set, figure-ground relationships, laws of grouping, and goodness of figures. http://tc.eserver.org/24572.html http://tc.eserver.org/24572.html This article shows how user-centered design can be applied to documentation and reports the results of a two-year contextual design study. The article (1) demonstrates how contextualdesign can be applied to information and (2) reports some of the study's results,outlining key insights gleaned about users. The study found that users vary widely intheir information needs and preferences. Users employ a variety of learning strategies inlearning new software and in overcoming problems encountered within applications.Documentation can better meet variances in learning styles and user preferences whentightly integrated into applications, accessible in the user's own language. Additionally,documentation is most beneficial when several assistance options exist for users tochoose among, varying according to context, task, and user need. Finally, the article discussesthe constraints that affect the implementation of design ideas and explores implicationsfor practice and additional research. http://tc.eserver.org/24422.html http://tc.eserver.org/24422.html Effective technical manuals and training meet the needs of the customer. No one will argue with that statement. But the trick is to identify the needs of the customer. This paper describes one method to focus product information development on the customer: the needs analysis survey. This methodology that is common in course development and training identifies the tasks customers perform. It also allows course developers and technical communicators to collaborate on an area that they both understand. http://tc.eserver.org/23698.html http://tc.eserver.org/23698.html The experience of setting up a new home theater system also sharply reminded me of what it is like to look at something as a new user: staring at a bunch of knobs and holes for the first time, holding a tassel of wire in one hand and a manual in the other, and really just wanting the darn piece of ?%^%! to do what it's supposed to do. http://tc.eserver.org/23576.html http://tc.eserver.org/23576.html This presentation addresses designers and documenters who develop technologies for human use. The content is based on an intensive 42-hour training package, developed by Communications and Training Inc. Course content and duration can be modified to meet individual requirements. One day interactive workshops are also available. http://tc.eserver.org/23406.html http://tc.eserver.org/23406.html This article deals, despite the title above, with aspects on handling and checking of technical documentation. I consider these aspects as part of the functionality of documentation besides more conventional functionality such as factual correctness, layout, combination of figures and text. http://tc.eserver.org/23389.html http://tc.eserver.org/23389.html The current trend among technical communicators is a twisted form of minimalism that says the documentation should contain procedural documentation but little or no reference documentation. I believe that this trend is a disservice to our customers and tends to increase technical support costs because customers subjected to this form of documentation have little or no access to the information they need. If it’s not there, they can't find it. http://tc.eserver.org/23399.html http://tc.eserver.org/23399.html Quality management is forcing technical communicators to meet the challenge of writing user-centered documentation. Adequate preparatory work would be to categorize potential users according to experience, knowledge, tasks to be performed, and other use-relevant features. Users' requirements and requests should then be incorporated into the document's design. http://tc.eserver.org/23409.html http://tc.eserver.org/23409.html Documentation, operators’ manuals, maintenance instructions, etc, can never be perfect and satisfy all users. The organization of the documentation, particularly for large systems, will never suit all users and there will always be some errors present. This means the supplier and the user need to cooperate in various ways to avoid the fatal consequences of errors and misinterpretations, and for the improvement of documentation over time. http://tc.eserver.org/23430.html http://tc.eserver.org/23430.html Nobody reads user manuals for pleasure. And yet we all make our living from them, and hope that what we produce is at least useful, if not actually enjoyable http://tc.eserver.org/23289.html http://tc.eserver.org/23289.html What can manufacturers do to improve the readability of manuals that accompany juvenile products? http://tc.eserver.org/23288.html http://tc.eserver.org/23288.html According to the Consumer Electronics Association, product returns represent a $10 billion-dollar-a-year problem for the consumer electronics industry. Technical support costs are spiraling (even with the migration to off-shore providers) while consumer satisfaction with this support is plummeting. New technology and expanded offerings to a stabilized market are increasing competition. What can manufacturers do to help combat these problems? Better consumer manuals are a start. http://tc.eserver.org/23141.html http://tc.eserver.org/23141.html The user's idea of the problem is often very different than the help or program designer's. The online help topics often reflect the designer's viewpoint, not the user's. http://tc.eserver.org/22878.html http://tc.eserver.org/22878.html Today's documentation must be designed with information retrieval as its key objective. When information is organized and mapped into a consistent, logical structure that uses retrievability aids such as labels that facilitate scanning, blocks of information, advance organizers for the information, keywords, meaningful indexes, and a hierarchical organization, readers can quickly locate and use the information that they need. http://tc.eserver.org/22160.html http://tc.eserver.org/22160.html Nearly 20 years ago, the profession of technical communication began to focus on developing task-oriented documentation. Although task-oriented documentation has always been produced, particularly for consumer products, it was not the standard in the computer industry. More often, people writing about computer systems focused on the system rather than on the tasks people needed to perform. Systems-oriented documentation was the norm. http://tc.eserver.org/22161.html http://tc.eserver.org/22161.html Redesign your information; write topics, not books. http://tc.eserver.org/22144.html http://tc.eserver.org/22144.html Technical communicators today must document complex applications used in complex environments. Information about users and use models is important under these conditions, especially if documentation will be presented online. Customer partnering, a method of information gathering that supplements surveys, contextual inquiries, usability testing, and interviews, provides a way of involving the users of complex applications in the design of information delivery systems. We used this method to help a client gather important information about user and use models and design a new information library for complex server computer systems. http://tc.eserver.org/21435.html http://tc.eserver.org/21435.html Benutzerinstruktion muß sein. In Form von Online-Documentation ist sie unmittelbarer Teil des Programms. http://tc.eserver.org/21027.html http://tc.eserver.org/21027.html In 1993, Compaq Computer Corporation ventured into a totally different market--the consumer market. Once known primarily as a company that manufactured high quality, expensive business computers through its elaborate dealer network, Compaq was faced with selling its units to consumers through retail outlets. As a result, the PC Marketing Communications department concluded that its current documentation set was not giving the students; retirees; homemakers; and small business owners, who work out of their home offices, the kind of information they needed to be productive. This led the department to the challenge of creating a new documentation set that would meet the needs of these new customers. 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/20725.html http://tc.eserver.org/20725.html Technical communication's long-time focus on task-oriented documentation has left customers with too many tasks and too much information; itï¿Âs time for a new approach. A user-centered approach reflecting a thorough understanding of users and how they engage the product is the surest route to effective documentation and training. To understand what users need, we need to get closer to them by spending time in their workplaces, watching them execute everyday tasks, and listening to them. Through this kind of ethnographic activity, we will become user experts, gaining credibility within our own organizations and our user communities. 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/20552.html http://tc.eserver.org/20552.html The user-centered design of documentation is an aspect of product design that has often been under-emphasized. Difficulties inherent in documentation design include obtaining user, feedback to high-level design objectives; extracting user. feedback specific to a product’s documentation. rather than to the product as a whole; and managing the various resource constraints inherent in product development. IBM User-Centered Design offers a solution to these difficulties by employing a set of user feedback methodologies from which the documentation designer, a member of a multidisciplinary design team, extracts pertinent data to set design objectives and follow through to low-level designs. 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/20328.html http://tc.eserver.org/20328.html You've never met them before. To you, they may represent the unknown and the strange. They view things differently, and their ways may seem almost alien. Yet you are supposed to serve their needs. They are your customers. Isn't it time you made first contact? In this paper, we share lessons learned and invite you to being your own voyage of discovery. http://tc.eserver.org/20330.html http://tc.eserver.org/20330.html This presentation will describe an area of documentation that is often overlooked--that which covers the process between the customer purchasing a computer system or upgraded software and the customer becoming productive using that system or software. This information includes all that needs to be planned and accomplished to get new software up, running, and integrated with existing software. Unisys Corporation fills this gap with what we call 'Release Documentation.' This presentation describes the who, what, where, when, and how of that process. http://tc.eserver.org/19743.html http://tc.eserver.org/19743.html We often hear that users do not read documents. To lure readers into reading our documents, we must make documents user-friendly. http://tc.eserver.org/19501.html http://tc.eserver.org/19501.html How do you stop writing documentation and instead give people the information they need to use a product? You start by understanding your users: their level of expertise, the tasks they need to accomplish, and the problems they are likely to run into. Then you can help them do their work by presenting the information from their point of view and focusing on real tasks, rather than product functions. With this background, you can develop information that is easy to understand, easy to find, and visually effective. http://tc.eserver.org/18986.html http://tc.eserver.org/18986.html By soliciting and receiving customer feedback, writers learn how customers use existing documentation and what additional information customers may need. In May 2001, we began a formal process of gathering customer feedback for the IBM WebSphere Commerce Suite product. The first phase of this process involved two main initiatives: creating and promoting a documentation questionnaire for customers; creating and working with an internal test team that acted as customers. Feedback allowed us to determine which information strategies helped customers meet their business needs, and which areas we need to concentrate on in future releases.