WtD Prague: Empathy in support documentation
This week I’m attending Write the Docs Prague. It’s super exciting to attend a European Write the Docs conference, and to be visiting the lovely city of Prague. This post contains my notes from a talk at the conference. All credit goes to the presenter, any mistakes are my own.
Plamena Maleva’s talk was titled, “The Power of Empathy in Support Documentation: A 5-Step Guide”.
Empathy and design thinking
Empathy is the ability to understand and share the feelings of another. But the kind of empathy that Plamena is talking about is more related to the methodology of design thinking. The first stage of design thinking is “empathize”. You need to walk in your user’s shoes so that you can clearly define the problem you need to solve, rather than just assuming you know what the problem is.
Design thinking relates to the creation of a product, and documentation is a product. Plamena used a help centre as the example in her presentation. A product is something designed to solve a particular problem. Therefore, a help centre is a product too. It requires innovative processes to design and maintain.
Support documentation needs to please many parties: users, founders, designers, developers, and ourselves.
Plamena says the definition of empathy should be seen as relating to users, but also to the product and support teams, including the writing team. If you look at it that way, you design the docs with a holistic view.
How do you go about designing with empathy? Plamena presented the following steps:
- Start small. Draft the key articles for your help centre first. Come up with the most general use cases, write those up, then link to the basic step by step guides. Then delve deeper in the next step.
- Include all the perspectives. Listen to product owners, developers, your own team, and of course the users. Define the key people and key teams, contact them and get their feedback. Do this at the earliest stage possible. Make sure that the customer support articles are designed for the end user. Show your work to people who have used the product as well as to people who have never seen it before. Also show the work to your stakeholders (developers, product owners) to ensure it meets their requirements too.
- Build the infrastructure. Define all the feedback touchpoints and link them in the way that makes sense for your product. Empathize with the developers and your team of writers, to set up the tools that everyone needs. The help centre should belong to everyone in the company. Important channels in the infrastructure: Backup of the feedback received so that you can share it with the team, reporting user feedback, collecting internal feedback.
- Monitor all the incoming feedback, from all relevant channels. For example, look at customer satisfaction ratings for each article. Follow the reports from the product team about new features and update your docs accordingly. Monitor incoming support tickets, and edit the docs accordingly.
- Iterate. Be open to the possibility of changing the initial idea in response to feedback. Plamena says you should think of this as a way to view your entire writing process, not only a particular document. Approach your work as if it will have to change within a relatively short period, as the environment will change. Plamena mentioned that we don’t have a definite “conclusion” phase for tech writing projects. Some people feel a lack of fulfillment as a result. By adopting the open, iterative mindset, the lack of a conclusion doesn’t bother us.
Plamena closed by saying that documentation is a constant work in progress, and this applies to all aspects of our lives. The journey is essentially the destination. With that philosophy, we can apply empathy to ourselves.
Thank you Plamena for an in-depth look at designing support docs with empathy.