Guidelines for Developing Instructions - Chapter 8
In Chapter 8, the authors lay out their suggested procedure for preparing instructions; we might call this chapter meta-instructions (instructions about instructions.)
Their six-step procedure for preparing instructions includes the following: (1) set ground rules, (2) gather source materials, (3) conduct analysis, (4) design, (5) write and edit, and (6) conduct user test. The chapter consists of an explanation for each of these steps.
The first step is to set the ground rules. Technical responsibility is laid upon the Subject Matter Expert (SME), while writing and presentation are left up to the writer. Trouble brews when some of the burden of writing is placed on the SME, with no compensation to go with the extra burden.
Responsibilities:
Technical Accuracy: SME is responsible for providing source documents, and reviewing resources for accurate information. Problems can arise if the writer attempts to act as their own technical expert.
Technical Content: Responsibility is shared.
Schedule: Depends on the deadlines; however, sufficient time should be given to both the writer and SME to ensure enough time for creation and reviewing documents is given. If one party is late, the other party should not be penalized..
Define Users
Literacy Levels
User Familiarity
Constraints
Graphics: Graphics are possibly restricted or even banned from use; this makes creating documents difficult.
Sometimes writers are not informed of restrictions until the project is well under way.
The second step is to gather source materials. This can be complicated, especially if the company doesn’t have all that much data to spare; sometimes, all they have is engineering illustrations and assembly instructions. A part of the writers task is to seek out information, often interviewing engineers to do it. Data to look for includes:
• Instructions for previous models
• Engineering drawings and specifications
• Line drawings
• Task analysis data
• Test specifications
• Photographs or videotapes of the product in use
• Product specifications
The third step is to conduct analysis. This can be accomplished by someone simply observing while a SME demonstrates the tasks. The primary goal of analysis is to see if there is anything safety related that should be included.
The fourth step is the design of the instructions. At this time you will select the media, format, and layout. You will also determine what the rules will be for developing the instructions.
The fifth step is the writing and editing. This is the process when you take data and instructions that you have compiled and analyzed, and place it in tis final format. Limit your usage of verbs. After completing the first draft, walk through the steps mentally. Editing consists of basic quality control.
The sixth and last step is to conduct a user test. Have two or three inexperienced subjects perform all tasks, with no prompting from the writer or SME. Keep in mind this is a minimum; the more people you test with, at varying levels of experience, the more likely you are to detect problems before going on to mass production. When changes are made, especially major changes, retest to make sure you have solved the problem.
posted by Lilith Singer | 8:55 PM
10 Comments:
My favorite part of this whole exercise is the User Test. I'll never forget Lorraine at Blue Cross Blue Shield of Florida testing a system I'd helped to build. Holding her head in her hands, she screamed "I don't understand! I just don't understand!" Well, that test was a failure.
But the feedback from users, even if negative, like the example above, is valuable. Techies typically assume the users are more proficient than they really are. A user test is an excellent reality check.
The user testing can always be an interesting part of the process. I’ve conducted numerous user tests for tech comm classes over the years, and the majority of them have been good ones. There have been some that have been less than successful though. Some participants give up within ten seconds, some give no feedback, and some don’t read all of the task instructions!
I do like that the chapter talks about delegating tasks between the writer and the SME. Group work is something that can always go wrong if it’s mismanaged, and I think it’s a very wise idea to get some of the delegation outlined right away. The outline here—though it may not be the perfect for every project—sounds like a good place to start.
I was interested to read about the Subject Matter Expert in this chapter. I've never really heard of that term before. It is always hard to think about the challenges in planning and executing a document. Sometimes planning can seem to take forever - many technical communication texts I've read talk about creating timelines to keep your project on schedule. This is a good idea, although sometimes it seems like a lot of work just to figure out the timeline. User tests at the end of the creation process are very important to ensure the effectiveness of the document.
I've heard the term Subject Matter Expert in a previous class I took called Project Management. We bascially simulated the development and implementation of new software. I became very aware of how important user testing and SME's are to the correct and efficient development of any new software. It makes sense I guess, you would want to consult with someone who is familiar with the product when you yourself are trying learn that product. I guess SME's can feel comfortable knowing they have job security.
I once helped re-write a series of instructions, changing the format from a two-sided sheet to a one-sided sheet that could be taped n place to be there forever (right!). It was an interesting process, to be sure, and I (we, me and the SME) did indeed mostly parallel the steps that the author outlined in this chapter.
The SME gave me the basic guidelines, then allowed me free reign to design the document as I saw fit (as long as he OK'd it as I went). Between us, we evolved a usable document that "said" the same thing as the original, but used much less space and far fewer graphics.
We also did some testing, and the test results quite favorably attested to the clarity and usefulness of the new document. One caveat to the testing was that some people would actually take the instruction sheet and discard it, preferring to "figure it out" on their own. At least one subject attempted to perform the tasks for most of the allotted time before finally resorting to the instructions. (The subject was then able to successfully complete the assigned tasks.)
I worry that an SME, because he/she is an expert, will develop a conceited attitude and judge their opinions of design and language to be more usable than mine. And indeed, their opinions will be more usable...to them. Similarly, my opinions will be usable to me, but not necessarily to anyone else. I think working as an equal group, where the members all respect each other, is far more useful to a project that will be used by a variety of people. Therefore, I agree that responsibilities should be determined before any content design is done, but that content should not be approved without general agreement by everyone.
Very well written summary. I have run across individuals that don't want to consult with SMEs as they feel it makes them less. They want to do the project all alone but when the information is inacurate, it causes great problems and inconsistencies across the workplace. In my experience, these types of individuals can't be told any different. Something almost has to go wrong for them to understand that sometimes information must be gotten from other sources.
I feel the most difficult aspect of writing instructions is "dumbing down" the information so even the most, for lack of a better word, simple user can follow and understand.
I like the diagrams in this chapter they really help me to see the path way more clearly. When I have made instruction I always found it hard to write them and do the constructing at the same time. It worked best for me to observe someone else as they while I did the writing. That way I didn’t miss the little steps I found myself doing without even think about it.
I think the collaboration between SME's and writiers is very important and I can't imagine wanting to go wothout the SME (well I can but hope not to). I have been hearing the term SME forever so I'm a little baffeled to see people write that they haven't really heard the term.
User testing is always important, and even if there isn't much of a budget for it there is always someway to force some one slightly invovled to give a hand in some way. Even having people read through the doc and express any confusion from the text is helpful.
Post a Comment
<< Home