What technical writers and kindergarten teachers have in common

Do you remember kindergarten? Standing next to your little wooden desk reciting the Pledge of Allegiance before you slather yourself in finger paint? Eating Twinkies in a room full of screaming little people who can’t wait for recess? Talking constantly and watching the kid next to you pick his nose while your teacher patiently recites the ABC’s?

Well, technical writing is a lot like teaching kindergarten. Sure, your audience wears grown-up clothes and has likely swapped the Twinkie for a danish, but deep down, they are still waiting for recess.

Let’s take a look at some of the struggles and concerns that you share with the ever-so-patient kindergarten teacher.

Warnings matter – Kids will eat the glue

Your users will find novel and dangerous ways to use your products. They will open the box, make immediate assumptions (what fits where, what can double as something else, what tastes good), and start cobbling things together or using them in a life-threatening fashion.

Warning labels are essential. Your users aren’t dolts; they are just busy people who don’t always have time to read a well-crafted set of instructions. So, they aim for efficiency and try to guess at how things work. Do them a favor, and find a way to warn them not to eat the glue.

Short attention spans

at-shcool-iii-311131-m What technical writers and kindergarten teachers have in common Apps

If you had a dollar for every time a kindergarten teacher said “Pay attention,” you’d be very wealthy indeed.

Technical writers face the same struggle. If your content isn’t gratifying, you’ll be talking to yourself. That doesn’t mean you need to entertain readers or dumb down the content to keep them from zoning out and drooling on their desks. Instead, you need to consider the business goals the user is trying to achieve and introduce your content by showing how following your instructions will help in achieving those business goals.

When you write your documentation ^(http://www.appmarsh.com/2009/06/writing-user-manuals-tips-and-templates.html), have a clear sense of the user’s desired outcome. That way you will stay on track and avoid the inclination to over-document everything. Keep it relevant and goal-oriented.

Complaints, complaints, complaints

Mislead a kindergartener, and parents will call the office to complain.

Mislead a customer, and they’ll keep calling back for Support. If they still can’t figure things out, they’ll stop using the product, and give it a lousy rating on the nearest product review website. They’ll tell their friends how difficult your product is to use.

Try to anticipate any misunderstandings. Take the time to verify the accuracy of your documentation, and do some usability testing if possible.

Technical writers do not always have the chance to interact directly with customers, but keep in mind that your documentation has a direct impact on the impression your product makes. Always consider the marketing impact of your work. This may be obvious if you are writing a white paper ^(http://www.appmarsh.com/2009/10/white-paper-writing-strategies-for.html), but you should still keep marketing in mind when working on other types of documents.

If you receive complaints about the documentation, address them quickly, and be thankful for the feedback ^(http://www.appmarsh.com/2008/04/savvy-ways-to-gather-user-feedback.html). It will result in a better product.

Rewards are everything

Kids love treats. Offer a kindergarten class a box of doughnuts for cleaning up the classroom, and they’ll turn into a blur of activity and find every bit of scrap paper on the floor.

Your users also like rewards. Often they are engaged in tedious activities when they use your products, and would be happy to see some light at the end of the tunnel. Offer them a reward for reading the manual, completing a training guide ^(http://www.appmarsh.com/2009/02/writing-training-manual-tips-and.html), etc. Perhaps you can offer points toward professional certification, or a printable certificate, or maybe just a cup of coffee. Better yet, write such great documentation that they will be able to complete the tasks at hand, and spend the rest of the day with their family.

Give the user something to look forward to ^(http://www.appmarsh.com/2010/03/what-your-users-arent-telling-you.html), and that motivation will help them through the tedious path toward expertise.