Guidelines
There are seven recommended guidelines to follow for tutorial design:
1. Identify User Actions You Need to Support
Analyze the users of the program and their needs, including what they use on the job, what software features are essential, and what features are used frequently. Embedded tutorials are useful to detect important skill lessons, but it should be clear how to close the embedded tutorial if not needed.
2. State Objectives as Real-World Performance
The objectives of the tutorial should be stated in the module in terms of the user's performance. State exactly what will be learned in measurable terms.
3. Choose the Right Type of Tutorial
Types of tutorials include The Guided Tour, The Demonstration, The Quick Start, The Guided Exploration, and The Instruction Manual. The Guided Tour consists of an overview of the main features of a program. It can be online or in print. The Demonstration demonstrates specific actions in a program. Experienced users may use The Quick Start to jump right in to a program and start working with it. The Guided Exploration allows the user to determine the direction of the tutorial, exploring its options. Finally, The Instruction Manual teaches users step by step how to use a program, from basic features to more advanced ones.
4. Present Skills in a Logical, Cumulative Structure
It is not enough to prepare logical and organized lessons in your tutorials--you must also order those lessons in a logical and coherent way. Like other aspects of documentation, the proper order and structure will be determined through an evaluation of your user's needs, i.e., a typical-use scenario. Usually, the tutorial will progress from the general to the specific, the structure of which will mirror the typical user's workplace routine.
5. Offer Highly Specific Instructions
Instructions should emphasize scenarios that are familiar and applicable to the user. These scenarios should contain specific instructions to ground the user in the lesson. Keeping them grounded will help them fight feelings of insecurity they may be having toward having to master a new tool. Some examples of specific instructions include using concrete data, interface tools, screens, and specific commands. In addition, remove all distractions from the lesson, including page design elements that may interfere with the learning process.
6. Give Practice and Feedback at Each Skill Level
Giving users positive feedback in a conversational and positive manner will help orient them emotionally to the tool you are helping them learn and to the tutorial itself. Avoiding jargon and making liberal use of "you" and "we" will give the tutorial a "human touch."
Building consistent patterns gives predictability to the tutorial and reduces the amount of work the user must go through to understand the concepts that are being taught. Avoid alternative explanations because they may overwhelm some users and distract them from what they are learning. If feasible, build in practice exercises or quizzes into the tutorial to help keep the interest of adults who enjoy challenges and self-exploration.Because most of your users will have competing demands on their time, keep the lessons short, about 10 to 12 minutes each. Also, let them know how to save their progress in case they need to shut the tutorial down and pick up where they left off at a later time.
7. Test Your Tutorial
Usability testing gives you necessary information about the effectiveness of your tutorial. If possible, test the tutorial in a real user environment. Focus the testing on the design elements, such as the cuing system and graphics. Perhaps most important, ensure that users can complete the lessons in the allotted time and that the lessons result in real learning.
Designing Tutorials
Because tutorials are designed to teach, the tone of the writer's persona must match the intended user to create a close relationship between the two. Because the goal of tutorials is to internalize work-related tasks and concepts, try to limit the scope of what the user is exposed to. This contrasts with other forms of documentation in which the writer attempts to be as expansive as possible. In order to narrow the scope of the tutorial appropriately, you must fully understand the needs of the user--which tasks are essential to them and which aren't? Without a thorough user analysis, it is impossible to narrow the scope of the tutorial appropriately.
Tutorial Users Need Special Care
Most of your users will be adults who have their own motivations for wanting to learn the tool that your tutorial is helping them master. For your tutorial to help them successfully, you must take into account the varied learning styles of your target population. As a tutorial designer, you need to understand how to limit the lesson times, prevent the user from being publicly humiliated for mistakes they make, give positive feedback, and make the user feel that they are self-directing their own learning.
Two Trends in Tutorial Design: Elaborative and Minimalist
The elaborative approach to tutorial design emphasizes reiteration to "bring the message home" to the user. Summaries, examples, and explanations all reiterate the learned material and may help the user retain and apply the knowledge they have gained. This approach is especially important for novice users with little-to-no experience with computers or the program being taught.The minimalist approach gives a nod to real human behavior: people often want to get off and running, without spending a lot of time in advance preparation. In the minimalist approach, the introductions and summaries are discarded because most readers will skip them anyway. To create effective minimalist documentation, use an action-oriented approach that is grounded in a workplace context that helps users recover from errors made and supports reading to "do, study, and locate."Team 4 (Chapman and Lukkonen)
13 comments:
A the risk of sounding like a broken record (does everyone know what I mean by that) my previous posts talked about writers getting involved at the ground level. We as tech writers need to know the product we are writing about very intimately.
In response to your post, I feel like you've hit on the subject matter accurately. The seven guidelines, if followed closely, really require the writer to know the product, not only for its intended use, but also in relation to the best way to help the user learn both verbally and visually.
In other tech. comm. classes, we talked about the team approach to documentation. After reading this chapter and your post, I can really see the value of the team approach. One can't do this on your own. In large scale documentation projects there are many scenarios to consider--probably more than just a couple of writers can tackle.
I'm also glad the you touched on the need to do a complete user analysis. It's so fundamental to not just tech writing, but pretty much all writing. The needs of the audience must always be considered.
The closest experiece I had with writing tutorials was a collaborative effort with one of the software engineers on a highly technical and complicated topic. I was really glad the the engineer had good teaching skills nad was patient with explaining the processes to me. My task was to compile his knowledge and create a tutorial for other engineers to "get up to speed". Looking back, had I not worked with that particular engineer, it might have been a disaster.
Unfortunately, I did not have a systematic approach, such as the one outlined here in this summary. I believe it would have made my work much easier.
Thank you for the comprehensive summary on tutorials.
To be perfectly honest, I am somewhat new to the field of technical communication. So, I have never written a tutorial or been involved with the process. I will be after this class!!! I am learning!
I do really appreciate Barker’s systematic approach that he outlines in the chapter-and thank you for the wonderful summary.
Just with the complexity involved in "good" and "effective" documentation, I find (or believe) that technical communication is something that people really take for granted. With documentation, the general public (or in my belief…) don’t really realize how complex it is for a technical communicator to take software or whatever it “is” and document it correctly and in such a way that people can use it. Yet, people do notice if they are struggling with the documentation, but they don’t necessarily realize good documentation when it is (hence, the mention of “take for granted”).
Anyway, just a thought. Thanks!
I enjoyed the part of the chapter that talked about elaborate vs. minimalist approaches to writing tutorials and how to decide which approach to take. Personally, I always prefer the minimalist approach for my own learning style. I like to jump right in and start clicking on buttons and see what happens. If I run into problems, I will look for help, but rarely will I take the time to learn about something first. However, I have used programs that are not intuitive and that by clicking on a unknown button can get you into some trouble. I use a program at work for ordering supplies, and each and every time I use the program, I have to get out my cheat sheet, to make sure I follow the correct steps. I curse the program every time I use it for taking a simple task and making it complicated. A good tutorial wouldn't help me complete the task. I have an expectation that software will, after I have learned the basics about it, become somewhat intuitive. If the program is difficult to use, a well written tutorial won't be able to save it.
As I write this, I recall Dr. Tesdell's comment on the class information sheet. He says, "Every piece of software has a help system that was written by professional technical writers who worked very diligently to document all the functionality correctly. Use it!" I recognize that my learning style might limit my ability to uncover all of the functionality of a program. I hereby resolve to make better use of the help features that are offered.
Although I have been on the receiving end of tutorials in the past, I've never before thought about the methods used to develop them. But indeed, you do have to consider user needs when designing your material.
For my documentation project, I would like to create a tutorial for use at work as refresher training for a software program. Employees originally attended up to 16 hours of classroom training, but of course, people typically retain a rather small percentage of what they hear in a lecture. Now that employees have actually used the software for a few months, I think a tutorial would be a good way to review some features that they have forgotten.
Thanks for the nice review!
I think that this textbook does a good job of presenting a lot of information in a learnable way. Each chapter is arranged the same, and the information is divided up into small enough chunks (but not too small), that it is easy to digest, as well as reference sections you have already read.
This was a good summary of the chapter, and the team did a good job of hitting all of the important points without being too long.
I also agree with Jennifer’s comment about taking good documentation for granted. I think we are all probably guilty of this to some degree (I know I am). My most memorable experiences using the types of documentation discussed in this chapter are the times I have been frustrated by not being able to find what I was looking for in a timely manner, or being frustrated with the lack of detail, or just confusing writing. After reading about how much thought goes into writing tutorials, I think I will appreciate more those that do their job effectively.
The essence of this chapter--writing the tutorial is to begin with the end in mind (My apologies to Stephen Covey). In other words, you must really understand who you are writing the tutorial for. Barker gets at this with his number one guideline: "Identify user actions you need to support." Indeed, the best tutorial writers are "students" themselves. I like Barker's list of the five types of tutorials. Each has its own unique purpose.
As other class members have pointed out, I believe the other diamond in this chapter is Barker's discussion of the differences between Elaborative and minimalist approaches in tutorials. With these unique approaches he pays homage to the fact that people have different learning styles depending upon their needs for information. There is no right or wrong, only which approach is best for your situation.
I think that the tutorial is probably the most important part of the software package for a new user. The manual is a good guide, but to actually see the process in action helps tremendously. I find myself using tutorials throughout new programs all the time and if I can not find the answers I am totally lost until I find someone who knows the program especially if the tutorial is not very user friendly. I like how the chapter was broke down and how it talked about how tutorials should be written. Tutorials are really written for the people who don't know the program and should be user friendly for all. I too am new to tech communication, so I will be learning all this new documentation writing, I could do a good tutorial for the new user, especially if it is a user like me!
I've never written tutorials, so I found this chapter to be a great introduction and overview. I also like the recommendations for presenting things in different ways. For example, the suggestion about presenting scenarios. As someone who likes concrete examples instead of abstract descriptions, I find it more helpful to be able to picture specific activities. I think that might be the hardest but most important part about writing instructions: considering the different ways people learn.
I agree with Keeley's comment - I too like my tutorials to be very minimalistic so that I can teach myself as I go and have the tutorial there in case I need it. I don't want to have a detailed set of instructions to follow along with, so I find the types of tutorials that allow me to learn as I go.
I thought your summary was very well-written and informative. Thanks!
I'm thinking I shouldn't be the last person to post because the ideas expressed so far have been so interesting and articulate:)
I have used or taught students how to use a variety of tutorials but I have no experience in the tutorial development process--at least I didn't think so. I have developed an online course, so I couldn't help thinking that in a way, writing the content is very much like "walking" a student through using a new product. Course content is broken down into learning modules, and each module contains quite a bit of instruction. The theory behind the design is to supply students with the same information that you would most likely provide if the course were delivered in a face-to-face manner.
After reading this chapter, however, I am now wondering if I need to also offer an opportunity for the learner to use a modified structure--a minimalist approach for those that prefer to be more independent learners.
The guidelines included so many essential items, but I think like others, I think the user analysis and usability steps are two of the most crucial. Frankly, I am not so sure we do a good job of either when we develop courses. We "think" we know what students should know and how they should learn, but...
Hmmm...sounds like a potential thesis or APP opportunity.
Thank you for the well written summary.
As some of you mentioned here I also have never written a tutorial before as I am new to technical communication field. Many concepts of this chapter were novel to me but they provided me with a starting knowledge on how to evaluate tutorial design and begin writing one. I also prefer minimalist tutorials if I learn new software or such as I seem to get lost in overloaded type of tutorials. But once again it all depend one’s learning style and preferences. As technical writers we should be able to produce effective elaborate and minimalist tutorial no matter what our own preferences are.
I find that tutorials are rather complex. I know, without a doubt, that I've used tutorials quite a few times in my life. But, to be honest, I do not remember what exactly was successful/useless during them. I suppose we all pick up a certain percentage of the tutorials we use, and we continue to practice that learned method. What I find interesting is that, through the steps mentioned in this chapter, we go through the same process in developing tutorials. Perhaps what I will gain most from this chapter is the steps leading to the development of tutorials, and I think, as a technical communicator, it will help to not only develop successful tutorials, but also to identify successful ones.
Thanks, David and Mary, for the great summary!
Post a Comment