This paper describes how user assistance can streamline deliverables and improve product design by analyzing usage patterns from server-based content. We can then base decisions about how to improve deliverables on a thorough understanding of how customers use help content to find information and solve problems. This approach enables user assistance to add more value to both our companies and our customers by creating a three-way dialog between user assistance, the customer, and the product team. It also broadens the definition of assistance to include helping to design products that people can use without the need for instructions.
Power user. It’s a term that I don’t like. But there definitely are people out there who are working with the software and hardware that we document who want more than just basic information. Getting them that information can be tricky.
Information and knowledge workers are important users of technical communication products, but they do their work in different ways. Information work (i-work) follows a procedure to achieve a desired and prescribed result. Knowledge work (k-work) is decision making, the process of using one's skills and experiences to solve a problem. Information and knowledge are not always differentiated properly when organizations provide training and documentation for their workers, and information and knowledge tasks are not neatly separated in most business processes. Information and knowledge tasks can be separated and identified, allowing for the development of proper teaching and support materials.
'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.
At a user group meeting in 2007, TechScribe researched users' experiences of the software documentation that they receive. Do they prefer online or printed documentation? Do they read the manual, or do they call the help desk? How important is background information? Which is more useful, a 'how to' user guide or a reference manual? Do people prefer explanations using visuals, descriptions, or a combination? Read the survey to find the answers (we obtained 29 responses from 64 attendees).
Software documentation writers frequently fail to consider the broad range of their users, limiting themselves to overly simple audience breakdowns such as novice, intermediate, and expert. Before writing, technical writers should analyze their audience based on considerations such as the users’ physical environment, learning preferences, skill levels, objectives, and computer systems. Once this audience information is obtained, writers should create design models that accommodate as many of these users as possible.