Definitive Guide to Technical Communication Experience (TCX)
Taking care of users’ experience is much more than a trend: it’s a way of life for a technical communicator
In Technical Writer’s Mission Is To Write No Instruction Manual, as Far as Possible, I proposed that the best way to communicate how products and services work is to avoid the need for instruction manuals. By design, communication is always imperfect, so the only solution to make it perfect is to cancel its need wherever possible.
In this article, I want to explore more in-depth why technical communication may be so problematic — the distance — and provide a guide to melt down its complexity — the guide to technical communication experience (TCX).
The distance
There is a distance between the experience of products and services and the experience of their documentation.
Often, engineers build products and services to solve problems; then, at a certain distance of time, technical writers write documentation to tell users how their issues are solved thanks to those products and services.
Probably because of a long habit that has become a bias, engineers tend to distinguish and isolate the problems they solve from people to which that problems are relevant.
That distance causes the need for technical communication that is poor by design. In that scenario, technical writing is mainly a mitigation of the forgetfulness of users when designing and implementing a product.
Nullify the distance
It’s a matter of standpoints.
A company builds a product when there is a potential market to which that deliverable is valuable. At the story’s beginning, there are defined personas that are supposed to benefit from the new product. Those personas identify the market and are the focus of the product design and development kick-off.
After a while, the focus shifts from personas to the problem to solve, and that’s when the distance starts to form. A product is a solution to some personas’ situation, so it’s unavoidable that building a product implies focusing on that solution.
Yet, solutions have their peculiar dynamics and complexity independent of their users.
Imagine that the product is a smartphone, and the problem it solves is providing an always-available means of communication for influencers. When designing that kind of smartphone, there are two facets to focus on, and that may conflict:
- A feature: the smartphone must always be up and running.
- A purpose: the smartphone must serve the influencer’s purposes.
An always-be-up-and-running smartphone requires complex technology, which may be engineers’ primary focus when designing and producing it. If so, the final product likely meets the always-be-up-and-running requirement, but in a way that may be problematic or not smooth enough in an influencer’s life. Then, the need for an instruction manual to instruct the influencer about how to use the smartphone that the influencer will never consume: that’s the distance, and that’s a market failure.
Nullify that distance requires a constant two-focus approach:
- Solution effectiveness.
- How the user experiences the solution.
The two focuses validate each other. Once a solution is effective, the question is: does the user have a great experience with it? The more arduous the instruction manual to use the solution, the poorer the experience. Likewise, the more difficult to convince to adopt the solution, even an effective one, the poorer the experience.
The definitive guide for technical communication experience (TCX)
The goal is a great user experience. That means that products and services are like a suit that users wear to shield themselves from the problems that those products and services promise to solve.
The TCX relies on the feedback loop based on the two-focus approach
- Effectiveness of the solution
- How the user experiences the solution
by leveraging technical writing as
- Based on use cases -> Effectiveness of the solution
- Audience-centric -> How the user experiences the solution
TCX mirrors the feedback loop that technical writing puts in place when it influences product development by revealing how tough it is to instruct on their usage.
TCX is where technical writing interleaves with product management, as I wrote in 5 Tips to Tackle a Technical Writing Project.
The TCX algorithm is straightforward:
- Give a price P to how effective a solution is, compared to the problem it solves: how much money does the solved problem value?
- Give a price S to how smooth it is to adopt the solution (that’s experience), compared to the user’s characteristics: how much money does the solution value?
- If S<P, review the solution and re-evaluate steps 1. and 2. until S>=P; otherwise, you’re done!
Conclusion
You see: we are in the domain of the obvious when stating that users must have a great experience with products and services. Nevertheless, how tough is acting accordingly to that statement?
Probably because of a long habit that has become a bias, engineers tend to distinguish and isolate the problems they solve from people to which that problems are relevant.
TCX is a remainder: users are more important than the solution, meaning the solution must be usable, not just working.
Sure, it’s a matter of budget: a great user experience costs and increases product and service prices. Yet, a great user experience implies efficiency when using those products and services and, as such, increases their value and pays the cost back. Then, it’s marketing.
If you enjoyed my article and found it helpful, please consider joining Medium through my referral link: you’ll support my writing and get into a sea of knowledge. No extra costs!
