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:

Another congratulations cliche

Another congratulations cliche

“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.

Madcap FlareAdobe Robohelp

By Tom Johnson

I'm a technical writer working for the 41st Parameter in San Jose, California. I'm interested in topics related to technical writing, such as visual communication, API documentation, information architecture, web publishing, JavaScript, front-end design, content strategy, Jekyll, and more. Feel free to contact me with any questions.

  • Pingback: Five Ways to Avoid the “Congratulations” Cliche as You Start a User’s Guide | techcommgeekmom()

  • Alan

    “You’re reading the manual? Now we feel kinda bad that we printed it in 8-point type on crappy paper folded into a tiny wad at the bottom of the packaging.”

    • Donna

      Too, too funny. Great post and I absolutely love Alan’s response.

  • Neal Kaplan

    Great ideas, Tom. I’ve long been tempted to add a contest somewhere in the middle of a manual: “Congratulations! Because you’ve made it this far, you’ve won $50!” I’ve had debates with other writers about how often I’d have to pay (“rarely” or “very rarely”).

  • Danie

    “Thank you for validating my reasons for choosing technical writing as a career. I can’t wait to tell my mom that someone actually read something I wrote!”

  • Mike L.

    “Where now? Who now? When now?”
    or a similarly famous first line

  • Karla

    Now when someone tells you to “RTFM,” you can reply “I *did* RTFM, and I still don’t know what to do!”

  • Grace

    Sounds quite good. Indeed, we have many other different expressions to kick off the start of a relationship between a product and user. So our technical writers may try to use the expressions in related manuals.

  • Melinda

    LOL, my company actually uses this sentence. I hate it but couldn’t think of a different way to kick-start the manuals. Thank you so much for these great ideas to break the ice between frustration of the user and the ‘great now I have to read the manual’ mentality.

  • Cindy Fisher

    I love your suggestions! For my particular company, I think the following applies:

    “Our software tries to be everything for everyone. Consequently, it is unintuitive. Like a 1000-piece puzzle, finding what you need is cumbersome, time consuming, and frustrating. That’s why we’ve designed this help to guide you to the exact information you need to actually be able to use the software in such a way that your bosses take notice, your company profits soar, and you get a five-figure bonus after every quarter.”

  • straygoat

    I can see where you are coming from, but a few of your suggestions would kick the instructions off with a kind of negative feeling. Like it or not, instructions do have a marketing purpose too – they enhance/lessen customer confidence in a brand, so the first thing you see should create positive feelings towards the product.

    • Anne Sandstrom

      Ah, this was meant to be humorous. But, I guess the truth of it all is just a little too close to home. Fortunately, I’ve never had to include one of those abysmal, insincere “congratulations” messages in any manual.

    • Cindy Fisher

      I disagree somewhat, straygoat. The best meeting I ever attended with users of a company was when the CEO just flatly came out and said, “We do a few things wrong. Let’s discuss them.” I like that Tom’s examples put them right up front.

  • Kevin

    The “congratulations” line is analgous to walking in on your first day in a new job and congratulating your new boss for his wisdom in hiring you. It’s arrogant.

    It would be better to start the relationship by THANKING the reader for purchasing the product.

    • Neal

      I agree that Thanking would be better, but I think that the “Congratulations!” is less arrogant than it is a sort of fake, automatic praise that’s intended to make the buyer feel better about their decision (maybe it’s supposed to counter feelings of buyer’s remorse?).

      I think it’s closer to the way a waiter will say “Good choice!” when you order at a restaurant. Was that *really* a good choice? And was it a good choice because the waiter happens to like it, because they think that I’ll like it, or because the restaurant sees more profit from that particular item? (And why am I overthinking a routine transaction and an associated, harmless social convention?)

      • Jim-ski

        You make a good point. Who has ever heard a waiter say, “Poor choice ma’am, surely you can find something better”? If phrased properly, the waitress’ praise should make it sound like you’ve found a delicacy buried amongst the other items-and I’d venture to say most of us do take a journey through the menu until we settle on one or two finalists and the praise is welcomed.

        Maybe that’s what our opening line should present: acknowledging some sort of journey that led to one’s decision to buy our product. However, I do agree that “congratulations” somehow doesn’t quite stand up to the occasion.

        Could it be that using “congratulations” has passed as a fad?

  • Laurie Nylund

    Wonderful column. Regardless of the tongue-in-cheek nature of some of your suggestions, they have a lot of merit. AndI have a project right now where I am going to propose this one (albeit without the read it slowly part) because it is exactly the philosophy of the team!

    “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. ”

    I think this is genius!

    Though I quite liked Danie’s offering as well. 😉

  • Marcia Riefer Johnston

    Tom, Congratulations on getting my day off to a rolicking start.

  • Mike L.

    How about users who are
    1) reading the manual to find features they may have missed
    2) looking at the manual online as part of the purchasing decision

    A. Don’t start the manual “I ….”
    B. Don’t start the manual assuming the reader has already purchased the software
    C. Conceptualize the manual as part of the sales material for the software

    So the manual starts: “This software is the most sophisticated …. with many advanced features. Here are some you may want to know more about (a list with links).”

    • Neal

      If documentation starts with blatant marketing copy (“This is the BEST. PRODUCT. EVAR.”), I immediately skip the intro and look for the real content. At that point, the documentation needs to regain my trust.

      That said, I’ve had battles with PMs who insist on fluffy, marketing-y copy in introductory text, and I certainly haven’t won all of those battles!

  • Janet Swisher

    “If you are on fire, STOP, DROP, and ROLL to extinguish the flames.”

  • Swapnil

    Tom, excellent article.

    I’d love to see the look on the Project/Development Manager’s face when I submit a draft of the UG for review, starting with something like “I’m sorry that you have to read this manual to figure something out. We tried to build our product as intuitive as possible…”

  • Oana

    Excellent input! I know a few technical writers who will find this info very useful :)

  • Tom Johnson

    @Alan, I love it. You made me laugh quite a bit with that one.

    @Danie, nice. Thanks for reading my blog, by the way. It’s always great to hear from you!

    @Cindy, interesting approach. It’s fun to read these.

    @straygoat, Good point. Obviously I didn’t mean these kickoff sentences seriously, but I like the point you raise about helping the customer start off with positive feelings.

    @Cindy, Yes, an honest spin on a meeting might make users more receptive to the content.

    @Kevin, Perfect analogy with congratulating your new boss. I like that.

    @Mike, I like your approach. That’s obviously more realistic. I might just try that one.

    Thank you everyone for the lively discussion and response to this post. I’m sure that the next time you see a “congratulations cliche” in documentation for a product you just bought, you’ll never read it the same.

  • http://www, Just Plain Karen

    Great post, Tom. I’m with Kevin completely. I LOATHE any sort of salesmanship in user guides.

  • Petra Lindblom

    Just give the instructions and let the user move on with her or his life? The manual is supposed to HELP an information-overwhelmed person to DO something. It’s not an area to brag about the product, be witty or anything else like it.

  • Danielle W.

    I found that “Congratulations for buying …” in the start of manuals a waste of ink. I think your approach is much better. The types of openers you suggested provide a way to also include customer service emails and numbers if the customer still does not understand as well as documentation team emails for general document feedback.

  • Pingback: CM Chapter 4: Knowledge Managers Sit at the Big Boys’ Table « Powering Pencil and Paper()