Five Ways to Avoid the "Congratulations" Cliche as You Start a User's Guide
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.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.