Saturday, March 22, 2008

Barker Chapter 10: Designing for Task Orientation

This chapter presents tools and techniques for responding to characteristics of software users.

Guidelines for designing documentation

Create a table of contents

Match the user analysis with information design strategies

Acknowledge production constraints in document design

Test and review the design

Follow a design process for online help

1. Create a Table of Contents

Think in the sequence of stages that begin with goals and end with solutions. The prior user analysis with suggest overall goals. The outline embodies your most innovative and user oriented ideas. Decide on the overall organization of the manual and how to design so the user can easily find information.

  1. Match the user analysis with information design strategies

When designing for different groups consider the following:

· Navigational aids- Navigational aids make sure the user groups get to the information pertinent to their needs. These could include special statements, directing users to the sections of the documents, list of figures and tables, headers and footers.

· Scenarios- Scenarios give each group a role model.

· Icons- Icons identify information for each group.

· Metaphors-Metaphors make implicit relationships to the workplace so users can see and feel the document is familiar to them.

Design for a specific program issues:

· Job performance aids cover technically or repetitive tasks.

· Background information to meet special needs.

· Special forms can help users collect information in the field for later inclusion in the document.

Meet the user’s task needs

Illustrations, layout design, examples of usage, special document sections, and tips.

Meet the user’s information needs:

This requires you to understand how users manage information within a job setting. There are several strategies you can use:

· Explanation so the user understands their use and importance.

· Provide examples that illustrate workplace uses.

· Meet efficiency goals/command summaries for efficiency by providing things like shortcuts, macros, etc.

· Identify functions that relate to information management and communication work

Match the user’s computer experience –

There are different types of users like: novice, experienced, and expert.

Enhance the user’s subject-matter background:

Take advantage of the user’s knowledge of the subjects by doing the following:

· Special glossary of background terms

· Index entries linking background terminology to program functions

· Special booklets/sections describing background concepts

· Elaborate examples with explanations of key concepts

Leverage the user’s workplace

Try to incorporate the following to help new users:

Getting help from coworkers

Suggestions for support groups

Descriptions of network use

Meet the user’s learning preferences

Learning preferences are connected to the choice of media as well as design.

Instructor learning – For instructors use lesson plans, overheads, etc. For the learners use workbook, note pages, diskette.

Manual learning – Tutorial manual, list of learning objectives, samples files

Computer-based learning – Programmed computer-based training modules, etc.

Meet the user’s usage pattern

First determine which category is most appropriate: Regular usage, or Intermittent usage, or Casual usage.

  1. Acknowledge production constraints in document design

Decide on what design features you would like to have and what you can afford to have. You need to know you limitations before planning. Some constraints are: Writing tools, Production tools, Human resources, Budget, and External considerations. See table 10.3 for further explanation of the constraints.

  1. Test and review the design

In this phase you evaluate through reviews by clients and sponsors and test problematic areas in a lab or field test. To test your design you can follow these steps:

a. Mock up pages with access elements on them and field test them.

b. Consult the chapter on testing for was to do quick usability tests.

c. Decide on a design based on logic and experimentation.

  1. Follow a design process for online help

The design of online help should parallel the process of designing for print; however the process must be adjusted to accommodate: technical differences between print documentation and online documentation, and the different features of online document versus pages.

Identify and list the online help topics

Topic is an identifiable body of usable information associated with a user activity.

The 7setps program identifies the following kinds of topics.

About – offers introductory information of the program

Module – describes the modules of an interface

Action – describes situation in which a user would use a part of the interface to achieve a workplace end

Problem – describes solutions to problems/bugs/errors

Questions – describe questions the user might ask

Task – identifies the workplace activities the program supports

Update – describe new features of a program or application to the users

User group – describe the types of users with similar ways of using the program.

The two types of automatic topics are:

“Best practices” – when the user has performed an operation that is potentially complicated and would need more guidance

Corrective – topics open when a user has reached a dead end

Determine the interconnected elements

Those interconnections among topics based on user activities make up the heart of a help system because they allow the users to follow familiar patters of activity.

Decide what design features to use

Design features are the software capabilities you can build into a help system and the electronic interface elements of a help system. Some features of the help systems are: Hypertext links, buttons, hot areas, browse controller, pop-ups, context sensitivity, and system affordances. See table 10.4 for detailed description of each.

Here are several areas to consider when designing for task orientation:

Accommodating groups of users

You must constantly consider the degrees of experience among the groups of users. You may have to write more than one manual to accommodate the different needs and expectations of the users.

Pay attention to users psychological differences as experienced users may have more patience and confidence with the program .Novices have less experience with manuals and online help and do not know the conventions of documentation thus can get lost looking for things in the wrong section. As a documents designer use a variety of features (glossaries, cuing, graphics etc) to help novices and get them on track.

Consider the roles based on computer experience and professional activities such as installers, operators, evaluators, decision makers and so on. Each of categories of users needs to use different functions of the program and need different level of support. Writer needs to use different cuing to make sure each user’s type can find appropriate section easily.

Matching the user’s problem-solving methods

There are several issues to consider:

  • No one carefully reads more then 2 sentences at a time.
    • Solution: Make paragraphs short. Include tables and lists whenever possible.
  • Most users begin using the table of contents before they ready the manual.
    • Solution: Make table of contents complete. Use abbreviated, complete and chapter-by-chapter table of contents.
  • Most users go to the manual or help only after they have failed to perform tasks.
    • Solution: Describe error recovery clearly and completely.
  • Most readers do not read instruction first.
    • Solution: Replace introduction with information about users needs, special documents features, or helpful routing information.
  • Most readers do not read any sections in its entirety.
    • Solution: Tell users which section to go for particular tasks/problems. Make sure all descriptions of tasks are complete for performing task. Repeat important information.

The Design Guide for Printed Documentation

Navigation

Navigational aids are elements of a document that tell the reader where to go next for what kind of information. Make sure you include navigating as organizing feature only after you have examined your user’s tasks carefully.

Cross-reference points to other sections of the chapters containing related information. Try to include the cross references and information that the users need at the point they need it.

Running header and footers - This may include: chapter and section names and numbers, book title, graphic cues and icons, task names, and color to indicate sections.

Layering – refers to having two versions of information on the page at once to satisfy more then one type of reader. Things like keyboard shortcuts on the side, use of columns for instructions, etc. You might have elaborate steps for novice user and abbreviated version of the steps for the experienced user.

Headings – All manual use heading, and all users expect them. Use short phrases to indicate contents of the section such as “Setting Margins” or “Saving a file”. Avoid making headings too short- “Margins”/”Save”. Headings also create visual part of the pages.

Advance organizers – tell the users the structure and organization of the information that will follow. Remember to put advance organizers in front of the information they reflect, use them consistently, make sure they relate to user’s work/tasks, and keep them short.

Document overview – Users need to be introduced to document’s setup and how to use it to find information. You can include things like: audience, content, organization, scope, and navigational information.

Parallel structures – There are two benefits of parallelism in software manuals. First parallelism reassures the user that the writer has sorted out the important information. Second, it creates pattern of expectations so the reader learns how to use the document.

Cuing – This refers to the technique of including visual patterns to make a certain kind of information memorable. You can cue with icons or rules, fonts, and caps.

Indexing and tables of contents – The two most important navigational and tracking devices in any manual. The table of contents describes the content of the document from a task perspective. The index provides a meeting place of all users of a program.

List of figures and tables – They make up the main element in the usability of a document and help users see quickly if they can find an example of a screen in a figure.

List of screens – This list works when you have program with easily recognizable screens. This list of screens should appear early in the manual or in the primary index screen of a help system.

Interrelated examples – These are examples when you follow the same example from one procedure to another. Doing so builds continuity into you document design.

Solutions to the design problem for online documentation

Here you face the same objectives as you do with the print document which is getting the user the right information.

Non-scrolling regions – regions that appear at the top of the screen and stay there while the user scrolls through the procedure or topic. This feature has advantage over the print document because user does not loose sight of the document.

Expanded text – Sometimes called “stretch text” allows you to embed more details into a topic so the user can click on the expanded text link to view details.

Keyword and whole text search – refer to the ability of a help system to electronically find topics and the user types into a keyword search box.

Indexes – shows an alphabetical view of all the important topics and terminology used in a help system. The author has to identify some terms for index to ignore when presenting the list to the user.

Links and Jumps – in a help system allow users to go directly from one topic to related topic. Here online system has definite advantage because user does not have to turn pages and can link topics and get back and forth between topics.

Pop-ups – provide a way to handle glossaries in an online system. User can click on the term in the topic window to see the definition.

Context sensitivity – With a print manual, the user goes through a chain of events between identifying a problem and finding the solution. With the online help system, user goes directly from a problem with a screen or a field to an appropriate help topic containing a solution. However the limitation is that you can’t guarantee that the user will get right information.

Histories – allow the users to trace their steps, save histories and refer back to them. This is advantage over using print material.

Browse Sequences – When you identify a series of related topics you cab easily include the relationship in the form of browse sequence. The system displays forward and backward arrows when moving from topic to topic using browse sequence which cannot be done as easily with the print material

Bookmarks/Annotation – With a book the user can easily mark a place in the book and then return to it as well as mark on the pages. Newer help systems also have incorporated bookmark options as well as annotation features.

7 comments:

David said...

As I was reading this chapter, I really felt like we were getting to the meat of the issue: how to design our documentation in a task-oriented way. I have to say that I feel a little overwhelmed as I try to decide the best way to develop my own documentation project--there are so many important decisions to be made. I think I'll be returning to this chapter for guidance again and again--lot's of great information in here. Above all, the advice on matching your manual to the abilities and expectations of your users seems very useful.

Mary said...

I agree that this was a very useful chapter. I found myself thinking especially about matching the users to the documentation for my project. Since I'm dealing with a mixture of experience levels, I will have to be careful of how I write my documentation. I think everyone has a fairly equal computer experience level, which is what I'll focus on, as compared to the experience level with the software.

Vanda Heuring said...

I liked this chapter, since it looks at the writer's side of technical communication, rather than just the technical component. The technical writer has so many tools available to him/her and most are basic writing and rhetoric tools. This is where the artistic and creative side of a person can shine through, as there are several different ways to get the point communicated in an effective manner and one can decide, which writing style works for him/her to get to job done.

Lance said...

Yes, this was a useful chapter by Barker. I felt as though some of the topics he covered could actually be expanded into full chapters themselves. Take for example the sections on color and cuing. I think most people read documentation sparingly. They scan for the information that is pertinent to their problem at a given moment. Color and cuing can really help someone get to the bottom of their question relatively quickly. I would have loved to see these sections expanded, and yes, given some color to the examples to really show what well thought out documents can do for the user. I like the practicality of this chapter. It will serve as good reference for future projects.

Keeley said...

If we leave this class with one lesson, I think it will be make a detailed plan at the start of a project, focus on the users' needs, and test your work along the way. I guess that is three lessons, but they must be important because they seem to be discussed in every chapter of both Barker and Campbell. Every conceivable part of a project seems to tie in somehow to one of these three requirements. I need to hear these points over and over because my natural tendency is to jump in and get started.

Karen said...

In his book, Barker demonstrates the techniques he describes in this chapter: he provides introductory directions, he considers the different type of readers ("reading to learn" or "reading to do") and offers different types of information to meet their needs. (Note: I do always wonder why he places examples first, followed by discussion, when he often recommends starting the reading with the discussion...)

There are many things to consider when designing documentation. Barker does a nice job of spelling them out in enough detail to make them usable.

brunsj1 said...

David mentioned how he was really going to refer to this chapter while designing his documentation project-I thought so as well, but quickly found that Author-it really had the design for our project set-up.

I chose the User Guide Template for my documentation project. When I published my document, it was fun to see the template for “User Guide”-I liked the blue and the page numbers, headers, etc.

However, it was a little sad too because those stylistic choices were already made-and to change them in my word document (before I converted it to PDF) was difficult since the template was pre-determined. I suppose this saved some valuable time (which is the major reason to use a software like Author-it), but sometimes it is fun to be creative with those stylistic choices.