Stop writing boring support copy. We’re all very tired.
5 steps for writing copy that doesn’t suck
Zzzzz.
Oh, sorry. I didn’t see you there. I fell asleep reading an app troubleshooting article.
I don’t blame the writers. It’s in our DNA to revert to a robotic tone whenever we’re asked to write any kind of documentation — a response handed down to us from our forefathers of technical writing: The industrial revolution wordsmiths.
It was from their examples, like this 1941 car manual, that we learned the roots of writing instructional product copy.
Informative, right? Dare I even say.. helpful. But how did you feel when you read that? Personally, I felt like I was sitting in a classroom with Ferris Bueller’s economics teacher.
Sadly over 70 years later, not much has changed in the way of car manual instructions — or product support writing in general.
Looking at these two examples, we can see the bones of product support copy that have carried forward to this day:
Yawn-worthy bare bones
. Guiding headers
. A list of instructions
. Diagrams or illustrations
. A bossy tone
. Transactional, action-based language
Despite having made leaps and bounds in the way of humanizing how we write for products, we haven’t given the same amount of love and attention to the consumer-facing documents and support copy that we write… which begs the question:
Does anything really need to change?
Yes! The more integrated technology becomes in our lives, the more of a reliance users have on our words to not only teach them how to use the product, but to fill the void left by the asbsence of human interaction.
More importantly, our experiences with technology from visiting a website to playing a VR game, have created a user expectation that we will be delighted whenever we engage with a product. That expectation knows no bounds, which means… Your support copy can’t suck anymore.
There there. Let’s change it.
How to write good product support copy
1. Get in the mood by setting your tone
Mark my words — the biggest mistake you can make when writing a support article is starting with the technical details.
Whether you’re the writer or the product manager, assembling all the facts first is actually a huge disservice.
Why? Because if you start with facts, you’re already in that inherently robotic mood I mentioned earlier. You may not realise it, but you’re going to start thinking in instructions and details. Before you know it, that mood has trickled into your writing (if you’re the writer, or your brief if you’re the PM) and the whole article wreaks of it.
It will be clear, sure, but not delightful.
Start instead with getting into the minds of your user. Anyone reading a support blog or help centre article is lacking some kind of information, and we can assume that they want to be successful in achieving a particular task, however big or small. The job of our copy then is to deliver answers in a way that helps them feel confident in doing the thing they want to do.
Here’s a little snippet from our brand’s Product Voice & Tone guidelines that we reference when trying to set the right tone with users who need information. This may be the case when writing a support article, or even a tooltip or tour in our app.
2. Practice the conversation and then write it out
If we think about the key business goal of writing product support copy: To cut down on the amount of incoming calls or queries that would require costly resources (ie people), we have to wonder…
How might we replace a human-to-human interaction without sacrificing the emotional connection that speaking to a real human builds?
Hypothesis? Writing emotive support copy in a way that mimics a two-way conversation can both instruct and delight the user, maintaining product confidence while cutting business costs.
And it’s easy to do (you’re already on step 2 of 5).
Next, you’ll need to find the person closest to the thing you’re writing about, and ask them to role-play a conversation with you.
For example, let’s pretend your mobile Product Manger sends you this slack message:
Luckily, you have this friendly chart of who to talk to.
You decide the query is best matched to doing something in the app, so you get in touch with the Lead Product Designer. Let’s call her Mary.
Mary suggests that you get into the user’s shoes by trying to do the same task as them. She shares her design flow with you, so you can see how the process is meant to work.
But that’s not all! Then she gives you a call.
You and Mary talk through the exact scenario your user is in, and she explains how to solve the problem while you reference her designs. You record the conversation (or take notes throughout).
3. Write your 2-way conversation using 1st & 3rd person pronouns
While the conversation and friendly tone is still fresh in your mind, start transcribing it into whatever content is required (support blog, help centre article, etc.)
Along the way, be sure to switch between 1st and 3rd person pronouns which mimics natural conversation.
When you’re writing as the user, try to emulate their tone and emotional state. Don’t be afraid to use negative or destructive words in this context, it actually serves to validate their emotions and build empathy into the interaction.
4. Go back to your original, boring documentation … just in case.
Remember when I warned you not to start with the details, requirements or brief? Well now I’m suggesting you finish with it.
After all, every writer knows to always come back to the brief.
Cross-check your beautiful, friendly new support copy with whatever already exists out in the wild that is your confluence space, desk drawers, etc, just to make sure you haven’t missed anything.
And then it’s time to…
5. Test before you ship
We’ve uncovered that product support copy plays a bigger role than just delivering answers. The business relies on it to cut costs, the brand relies on it to maintain relationships and your product relies on it to build empathy and trust.
Sounds like it’s worth testing, right?
Start by assembling a team of stakeholders, including someone to represent the business goals, someone from customer service, someone from marketing (from a brand reputation POV) and of course the product expert you worked with earlier.
Here are some questions you can ask the group when testing:
Testing content — Is this factually correct? Did I miss something? Can I get rid of anything?
Testing tone — How did it sound to you? What kind of voice did you hear?
Testing success — How did you feel after reading this? Was it helpful? Are you confident now?
TL;DR — Here’s how to write product support copy that doesn’t suck
- Pick the right tone based on how your user is feeling.
- Role-play (and document) the scenario with the product expert
- Transcribe that into a 2 way conversation using both 1st & 3rd person pronouns. Emulate the user’s tone but respond with empathy.
- Cross-check what you wrote with the original brief or existing documentation to make sure you didn’t miss anything
- Test it with a group of stakeholders representing all interests in product support copy
Well, back to sleep now. That was exhausting. If you have any exciting product support copy to wake me up, send it my way.
