It seems that the manual for almost every product I buy starts off by congratulating me for having purchased the product. I recently bought a waterproof iPod shuffle to listen to audio books while I swim, and since I couldn't figure out how to switch playlists on the device, I turned to the manual. Here's how I'm greeted:
"Congratulations on purchasing your iPod shuffle."
Have you seen this congratulations sentence before? I see this same pattern of congratulations on almost every manual for products I buy. Could no one think of any other way to kick off the start of a relationship between a product and user? Take the coolest kind of product, an iPod that goes underwater, and then drown the user guide with a cliche.
How about these for alternatives:
I'm sorry that you have to read this manual to figure something out. We tried to build our product as intuitive as possible, but hopefully you'll find the instructions here clear, simple, and easy to follow. If you don't, please feel free to read them again, but more slowly.
— Or —
I'm so glad you decided to read the instructions to your new iPod. Many users casually dismiss instructions and seek to figure it out on their own. But studies show that people who read instructions will get up to speed more quickly and efficiently than those who poke around with trial and error.
— Or —
I know what you're probably thinking — do I really need to read all of these instructions? Is the product really this complicated? Hopefully not. Feel free to skip and skim around, focusing on the problem you came here to solve in the first place. But we also encourage you to read some sections you may not have planned, because although you are no doubt sharp, you don't know what you don't know, right?
— Or —
Congratulations, you are actually reading the manual! So many people have wantonly dismissed user guides these days, attributing them as a bandaid to poor product design. But a product with any degree of complexity and sophistication, one with robust and flexible features such as the one you just bought, is going to take a little bit of figuring out. That's what this manual is for. Dig in, mark it up, cut out your favorite sections. It's going to be a wild ride.
— Or —
If you're reading the manual to get familiar with the features and functions of your device, continue in on the Navigation Basics section and browse through the material. If you're upset, frustrated, mad as hell, and trying to troubleshoot something that can't be deciphered, then skip ahead to the troubleshooting section. If you are on fire, though, take a few deep breaths and clench and relax your fists a few times. Patience solves more problems than panic and rage. Take the time to find the right topic to address your issue. Most likely it's in here. If not, send us an e-mail and we'll be sure to address it.
Feel free to use any of the above in your product manuals! If you're feeling creative, add your own in the comments below.
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. Topics I write about on this blog include the following technical communication topics: Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, and certificate programs. I'm interested in information design, API documentation, visual communication, information architecture and findability, and more. If you're a professional or aspiring technical writer, be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.