As the IT industry changes introducing new trends and searching to propose more value to a user, technical communication should adapt as well. Technical communicators start searching for better ways to present information and predict all pains to be resolved by the documentation.
One way of doing so is to look for some useful practices outside of technical communication domain. In this article, I would like to briefly introduce a visual practice of empathy mapping that can be adopted into technical communication.
Design thinking approach
Now, as the design thinking has influenced many domains, product development cycle is more user-oriented. It iterates through a loop of user-centered understanding – design and development process – and after-action review. Empathy map is a technique that is used at the preliminary stage of software development process, mainly in the domain of UX and business analysis.
Similar to software, documentation as a product has its own DDLC, with one of its stages being analysis. Therefore, on the stage of analysis, we as technical communicators should consider taking the user perspective and analyze possible user experiences with our product, just as UX designers do.
Why an empathy map?
The empathy map helps to understand your user or user group, and dive into things that influence and motivate them. It helps the initial user research and visualizes user’s pains and gains. Below you can see the empathy map canvas designed and adapted by me for the purpose of technical communication. Let us be more empathetic ☺
For example, if we are working on a User Guide for a file hosting service, then the main tasks the user will perform would be setting up service, managing files, sharing files, and so on. Therefore, the structure of the guide can be elaborated around these main tasks.
The influences we need to consider are the other guides of similar competing services that user might have already seen. We need to examine these guides and evaluate their strong and weak points.
Feelings. Let’s take the perspective of a user and think: “What would I feel while reading the guide? Would it appeal to me? Is it visual enough? Maybe it seems excessive in language, since as we know users tend to get frustrated with wordiness. Is the guide helpful?”
Pain points are concerns user might have using the service, like security level and upgrading account to a bigger storage size. How should this information be presented? Should we provide any tips from UI to inform the user about running low on storage place and upgrading mechanisms?
We can formulate the user goal in this case as being able to store and share files. These simple tasks probably don’t require consulting the guide too often, just a quick scan through it would do. Therefore, we need to make the guide as much visual and scannable as possible and make the key procedures stand out. The web-based guide stored at the product site would be probably the best deliverable format in the proposed case.
The above is just an example of how we can contemplate about possible documentation solution before we start actually writing. Hope the empathy mapping technique will be something practical in a daily life of an information developer. Tell me what you think!