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.
This paper describes a study that examined the effect of heading frequency on comprehension and perceptions of information presented in print versus online text. Results indicated that heading frequency did not differentially affect the comprehension of readers of print text while it did differentially affect the comprehension of readers of online texts who had considerably lower comprehension scores with text that had high frequency versus medium frequency headings.
If you work on a new-concept website—that is, a website that doesn’t follow an established format like an ecommerce site or a blog—producing user documentation might be the last task on your mind. Yet for sites that present processes unfamiliar to users, quality documentation is crucial.
Debates about Microsoft Word vs. Adobe Framemaker appear with regular frequency on the tech-writing mailing lists I am subscribed to. Everyone agrees Frame is an awesome publishing tool. Yet, everyone keeps cribbing about it. So, why does a bright bunch of people who are masters at figuring out stuff, otherwise known as tech-writers, only hesitatingly agree Frame is “kind of great”? I think it’s mostly because Frame is so difficult to use.
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.
Leading is the space between lines of type. Technically, leading is measured from baseline to baseline. The default leading for body text is approximately 120 percent of the point size of the type. But the default isn’t always appropriate. If fact, it’s rarely appropriate.
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.
Examines the phases of document development and describes how to incorporate them with usability techniques to ensure that your information products remain continually useful and valuable.
Proceedings of a paper about how readers interact with designed documents.
Peter Morville and Jeffery Callendar, two information architects, call faceted navigation “arguably the most significant search innovation of the past decade.” Because of its importance in content findability, one aspect I want to now explore further is a second-level faceted browsing system.
Writers of performance- and response-oriented documents, such as instructions, procedures, proposals, and grant applications, need to consider the interaction of human factors with conventional document design factors such as accessibility, readability, legibility, consistency, style, language, and suitability to audience. This session explores that relationship, based upon a summation and synthesis of previous Annual Conference presentations as modulated by this presenter's extensive technical communication experience. It will be of particular interest to newcomers to the profession who seek to broaden their grasp of its intricacies.
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.
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.
In several recent websites we have user tested, the site designers have placed important task critical links and information on the right hand side (RHS) of three column page layouts. The user testing was conclusive, users ignore any information presented on the RHS. We think this is a similar effect to the well documented banner blindness. It is essential to ensure that import links or information is not positioned on the RHS as they will surely be ignored.
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.
Why technical communicators and usability? Both writers and software development managers have asked me that question. In both cases, it springs from a narrow view of communicators as 'just writers.' It is a point of view that fails to see the many activities, from learning the subject matter to organizing the information or creating good document design, that are hidden behind that final task of writing the words.
Much technical documentation merely describes the features or appearance of a product or service, leaving readers uninspired and disinterested. In fact, much of what we write probably never gets read. A combined audience, task, and benefits analysis can help us communicate why a user should do a task—not just how to do it.