By the time your customers are finding and reading your support or troubleshooting documentation, they’re likely frustrated or very confused. It’s easy to accidentally compound a reader's exasperation by writing content that uses a tone of voice that does not match the customer’s perspective or skill level.
One of the most important steps in helping (and ultimately retaining or evangelizing) a buyer is demonstrating that you understand their feelings, and that you want to help.
The good news is this: if your support articles lack empathy and perspective, it’s pretty easy to identify the problem and rewrite.
Identifying unsympathetic articles
Create and monitor a feedback channel for your documentation. Be sure that you’re collecting feedback on your writing from users (customers) and your colleagues or peers. Implement a star rating system, offer a way to be in touch with the author directly, or create a feedback form. You need to know ASAP if a piece of documentation is not working for your audience.
It’s important to remember that user feedback will not usually include solutions to badly written documentation, but it will be useful in flagging a piece of documentation as a problem.
You should also plan regular check-ins with your customer success or support team and your salespeople. These are individuals who spend their entire day talking to customers, learning how they speak, and working with them to solve issues. Get a feel for what they’re hearing most often, how users want to be addressed, and areas where empathy is lacking.
Use the product. This might seem obvious, but in order to write useful product documentation you’ll need to use the product and struggle with it yourself. You should do this consistently, approaching it in all different moods and settings, using different site navigation paths every time.
Fixing the problem
Embrace your expertise. Since you are the product expert, it’s okay for your opinion to come through in your writing. The reader assumes that you know the most about their problem, so if your documentation lacks a clear point of view, it will send the message that you aren’t confident in your own advice. Would you follow instructions that seem uncertain? Would you trust an authority who can’t speak definitively about their domain?
Think of it like this: the customer is reading documentation so that they don’t have to do all of the thinking that you already did.
Cut out the jargon. Your readers do not want to open several tabs and frantically google your industry terms. Use an informal, active style similar to the way you’d speak to someone in person. Say you were on a support call, how would you explain the process? What if you were addressing the user in person?
If you would have to stop and define a bit of lingo for a friend of yours, who doesn't work in your industry, avoid using it without an explanation in your support documentation.
Seek immortality. When writing documentation, you need to plan for the future. When you write something with the mindset that “this will be replaced or will quickly become outdated”, the user can tell. Write docs that transcend time, and don’t forget that the internet never forgets an article.
“Good writing will get replaced. Bad writing will get replaced immediately. Epic writing will get edited.”- Daniya Kamran
Highlight the dilemma. You need to be explicit about why someone should read your support document. Your worst enemy is not a competing piece of documentation, but a lack of initiative. Create a sense of urgency, increase the readers autonomy, give options for further assistance, and provide a clear call to action.
Lean on resources like Write the Docs. Write the Docs is a global community of support and technical article writers, editors, and contributors. They have fantastic articles about Support team documentation writing and even have an active Slack community dedicated to relevant discussions.
Your users typically look to support materials when they're in a confusing situation, or something has gone wrong. Remember that when writing your documents. And don't forget to...
- Create a feedback channel for your users to weigh in on the helpfulness of your articles.
- Use your product to find and highlight potential trouble areas proactively.
- Form an opinion, and cut the jargon.
- Seek immortality by writing articles that can be updated or adapted, but can be accessed years down the line.
- Clearly highlight the dilemma you're solving for.
- Get help & connect with technical and support writers like yourself.
When in doubt, remember: an emotionally appropriate response should always preclude a substantive response.
Want Salted Stone to audit your top support articles? Mention this article when you reach out to us and let us put your materials to the empathy test.