Chapter 10 Barker -Designing for Task Orientation
- Designing for Different Groups, consider your navigational aids, scenarios, icons, and metaphors
- Design for Specific Program Issues and include job performance aids, background information, special forms
- Meet the User’s Task Needs – by telling them how to do things rather than describing the terms and fields on the screen.
- Meet the User’s Information Needs – by understanding how information is used in the job setting and writing the help to let the user know how the program supports that work.
- Match the User’s Computer Experience – consider the predominant type of user whether novice, experienced or expert and tailor the help to that level of understanding.
- Enhance the User’s Subject-Matter Background – which will enhance the usability of the software, like adding a special glossary of background terms used by the user.
- Leverage the User’s Workplace – by getting help from co-workers or suggestions for support groups.
- Meet the User’s Learning Preferences – choosing the media and designing documents according to that media.
- Meet the User’s Usage Pattern – tailoring your software based on how the users will reference the document – regularly, casually, or strictly troubleshooting.
Designing for online help should parallel the process of designing for print. Identify and list the online help topics. Topics are defined as “an identifiable body of usable information associated with a user activity.” (p. 317). The user’s view the topics as the final destination because it provides information to get the user back to the task of making the program work.
Accommodating Groups of Users:
You need to constantly consider the degrees of experience among groups of users as each will react differently. This means you have to write two or three manuals in one book. Two ways to group users are by degree of experience, or based on professional roles.
The experienced user is more patient with confidence in the program whereas the novice will blame the software.
- No one carefully reads more than two sentences at a time, so based on that:
- Keep paragraphs short
- Arrange information into tables and lists wherever possible
- Put important information at the beginning of each paragraph.
- Most users begin to use the table of contents before they read the manual.
- Make the table of contents complete
- Use both an abbreviated and an elaborate table of contents for complex material
- Use chapter-by-chapter tables of contents
- Make table of contents headings task-oriented
- Most users go to the manual or help only after they have failed to perform a task
- Be sensitive to user’s state of mind after failure
- Make descriptions of error recovery clear and complete
- Emphasize getting back to real world tasks.
- Most readers do not read the introduction first
- Replace it with useful information about user needs
- Replace it with material designed to get them applying the program right away.
- Most readers do not read any section in its entirety
- Tell them which sections go for particular tasks
- Make sure all descriptions contain complete information for performing the task
- Repeat important information as necessary.
Design Guide for Printed Documentation:
- Use navigation aids
- Use cross references
- Running headers and footers
- Book titles
- Graphic cues and icons
- Layering – has two types of information on the same page to satisfy two types of users
A good software manual contains useful patterns to help the user identify information easily. Some structuring methods are cuing (including visual patterns – icons, rules, fonts, caps, etc.)
Indexes and tables of contents make up the two most important user tracking and navigational devices in any manual. And lists of figures and tables make up a main element in the usability of a document
Solutions for Online Documentation:
- Using nonscrolling regions so as the user reads down they don’t lose sight of the topic
- Expanded or stretch text allows you to put more into a topic by use of an expanded link
- Keyword searches helps user electronically find topics
- Indexes – most online help compilers will generate this automatically
- Links and jumps allows user to go from one topic to another easily
- Popups – quick way to toggle on and off added information or definition
- Context sensitivity – user goes directly from a problem with a screen or field directly to the help topic.
- Histories – users can retrace steps
- Bookmarks – annotations – newer online systems have elaborate ways to use bookmarks
10 comments:
I really liked the design advice in this chapter. Keeping paragraphs short, and using tables and lists helps usability in big ways. I also think using color helps to link specific information in a way that’s very easy to understand. In general, I am also a big fan of “search” tools; however, they can also drive me crazy with the amount of time it takes to plod through until you actually find what you’re looking for.
I agree with Mary that one can get sidetracked easily using the search tools! With AuthorIt, I try to find the terminology for what I currently need, then run across something else that I also want to know and end up losing my focus. I think that's a good way to learn overall, at least for me.
Barker stresses that the user needs to know the terminology in order to locate information to work with the specific problem. AuthorIt is hard for me to follow since learning the AuthorIt terminology is step one to answering my questions and this is where it's been challenging! Barker also wrote that "the user must understand the many manual and help conventions in order to know how and when to search." I think it's essential to organize any manual we write in a manner that will allow our intended users to quickly figure out a process we are writing about. I'm writing my documentation specifically for my work group of users and am using the novice approach so it's clear and easy to implement. So much to remember...
Barker stresses that the documentation be created to match the users needs. It is all about meeting the users learning preferences and patterns. I agree with Mary, good advice is offered by using short paragraphs, the user will be more likely to read the information. Using lists and tables gives the user access to the information with a quick scan of the document. The importance of designing the documentation for user's needs is not an easy task. But Barker stresses meeting the users needs first, users expect information organized linearly.
I had a whole post written and then the power went out and I lost it!
Even though this chapter was intended for book design, it also had good advice for writing, such as keeping paragraphs short. The organization tips were also helpful. It is really important (as every chapter says) to keep the reader/user's needs in mind when writing. Since readers never read more than two sentences carefully, it is important to write concisely so that they can get the most useful information out of a manual. The different tips this chapter outlined--such as using tables when possible and writing short paragraphs--are important to keep in mind when writing manuals. This information has been in almost every chapter one way or another, so hopefully us technical writers never forget it! I will definitely keep this in mind when working on the final revisions on my documentation project.
This Chapter 10 in Barker is very Useful to make user friendly Documents. I useally have a hard time and struggle with a document if the design is poor. the material that it is printed on is not important if it expensive paper or fancy graphics, what matters is that it is clean and concise so that I can navigate throu it with out problem. The Technical writing is also an important aspect in this chapter, and should not be put aside. It is important that visual and writing go hand in hand so that thier is a equivical flow to the document.
Links an jumps can help the user use important information, but pop-ups can discourage the user if they already are familiar with the process.
It drives me nuts to read Barker and sometimes I think he could benefit from his own instruction. The text in this book is designed poorly in my opinion. He could benefit from keeping paragraphs short and concise...However I do think he presents valuable information regarding organizing things in certain ways in order to make locating the information much easier. It's one thing to ask for help but another thing to know where to look for that information when you want it. I also liked the bit about knowing the terminology in order to know where to locate the information.
I think this chapter (like many others) points out how important it is to keep the user in mind.
I like the point that most of the time, someone will only be reading the manual after they have already failed. The more confusing the documentation is, the more frustrated the user will get.
I wonder how many writers keep this in mind when writing. Most of the writers I work with talk about how no one ever reads the manuals...not how frustrated the reader might be.
There are so many methods in this chapter that are like a fail-safe for your task orientated document success. I liked the part on nonscrolling regions in order to keep them in view even when the user is deep in the document. Search tools, as Mary pointed out, are a big help but I also agree that sometimes you have to plow through so much found information it would almost be easier not to use them in certain cases. I have seen good and very bad search tools. I haven't been to successful using the AuthorIT search in the help section to find information so far... maybe I'm searching using wrong terms or something.
I agree with everything this chapter had to say about manuals. In fact, I designed my manuals the same way. When I worked at JT, it seemed to me that their manuals were wordy and cumbersome, but they wanted to keep it that way. That's fine, but I don't think users liked it very much. When I did my manual, I used icons (colored arrows and other marks), colored and italicized headings (I kept it consistent) and screenshots. I also love indexes and Table of Contents. Those are always helpful to me when I'm using a manual, so I am thorough with mine as well. Many project managers preferred my style over the one that was used in the past, but again upper managers were resistent to change... I appreciated this chapter.
The discussion about figuring out the user guess felt like I was reading about a mirror; I don't start off reading the manual, I start off with the table of contents, I skim until I find what I need. It's rather eerily accurate.
Post a Comment