Suyog Ketkar, Autodesk
December 1, 2019
If it is true that our work defines us, then technical communicators and jugglers are alike. Just that we play toss-and-catch between project deadlines, tools, requirements, meetings, and even products. Writing is only an aftereffect of our juggling. Which is why problem-solving may take backstage. We don’t always essay to address what the seekers require, but what our design and development teams have to offer. Through this article, I put forth the questions that came up in a recent coffee-table interaction on how we could fill this gap.
Who’s a seeker?
If there is one common term that puts all our customers, consumers, readers, and users (both internal and external) in one bucket, then it is that of a seeker. A seeker is someone who wishes to accomplish, obtain, or resolve something. They are someone who wishes to resolve and straighten the tangled strings in their daily responsibilities. The key takeaway here is that only those who wish to find, seek. For a seeker, the quality of documentation depends as much on locating the correct information as that on locating the information correctly. But, most importantly, they often use our documentation in that one way we have never thought of. And, to counter this, we need intuition as much as we need research.
Why is it important for us to know who a seeker is?
A seeker’s role is to help us get to work as much as it is ours, to help them get back to theirs — frankly speaking. Ours is mostly a unidirectional relationship with the seeker, in which we get to hear from them only when they can’t fix things. Understanding who the seeker is and what they seek, therefore, can help us fix something for them even before it is broken.
Look at the picture above. We all are trained to think like a user (seeker, for this post). So, we know that they seek the shortest or quickest path to the resolution. The information that goes into troubleshooting is, therefore, either or both shortest and quickest. We help them clear the obstacles for we can hear them say, “I want to get through this thing.” Still, our aim is not to fix their problems, which is what brings me to the key thought here: troubleshooting isn’t always required.
It is a lot easier for the seekers to find the required information if it is organized, grouped within topics — especially so when they have time on their side. What one may need may not necessarily be from the same topic but organizing information within topics still improves findability. The problem with this approach is that our products are usually bundled with lots of functionalities and interoperable tools. It is then possible for a seeker to begin with finding the information (for example, in a WebHelp) for functionality A and end up with the resolution for functionality B. This is why we also occasionally implement the concept of User Persona-based writing.
What are the challenges for us?
Even Persona-based writing is limited in its scope because seekers can assume more than one persona. Our current help systems aren’t capable of dynamic display of pages: from top-down, bottom-up, or lateral navigation, we need a lot of dynamic links that update themselves as we move pages and re-organize our content. The challenge here is: if we let our seekers free, will they be able to find their way back home? In cases when someone, logged in as a Contractor, wishes to search for operational information — in the capacity of a Business User — must log off to switch roles and only then they can have access to the corresponding information.
What should we wish to achieve?
The problem with all the approaches so far is that we seem to be engulfed in bringing the seeker to the information, while we should bring the information to the seeker. To take the point to a conclusion, let me make another assumption here. We know and have seen that despite our efforts, the seekers prefer to experiment than look for information. Let us then help them make such experimentation in the right direction.
For such reasons, I propose that we focus on empowering our seekers. Let us try to reduce the experiential friction between the seeker’s requirements and our offering. For this, I strive to write not about what my product can do for the seekers, but what they could do with it: I don’t tell them the product’s features, I show them how and why the offering is useful.
From the space-management perspective, a smartphone, for example, may contain a feature to delete duplicate photos. The benefit is of saved space (and troubled speeds) — not being able to delete duplicate photos. How advisable is it, in such a case, to write instructions on how to use this feature without first telling them how empowered they will be when and if they use this feature? The user documentation, as I propose, should not be a list of features but a list of benefits.
How do we do it?
We do it by empowering the seekers without their knowledge. It is the co-existence of independent information tidbits that seekers count as their experience. Hence, I say, we help them do two things, locate the correct information and locate the information correctly. If their experimentation trumps our information, let us ensure that our intuition trumps their experimentation.
We must help them experiment in the right direction: align our intention with their intuition and our content with their context.
We must enable them to witness the transformation of the information: from experimentation through data through critical business decisions and quantifiable results.
Let us continue with our example of a smartphone. Other than deleting duplicate photos, which, I agree, is a feature, we should talk about it wherever we talk about space management, speeding up the phone, clearing up cache, or organizing the media on the phone. This will help the seekers create mental cross-links between two disparate topics. Generically, for whatever we write, let us begin with talking about benefits and end up with describing features.
So, what is the takeaway?
The initial thought to seek itself comes from a combination of pre-defined parameters, an identified need, and some previously stored information. The crux of the matter does not lie in the result, the decision, or the fructification of information, but in giving the seekers a method to get to what they want. For such purposes, we could contribute to the user documentation, the user interface, and, at times, even to product development. Such individual efforts will help build a comprehensive experience.
The resolution of one need brings the seeker to the admission of another. Supplying troubleshooting information or developing content based on user personas can never do that. If the seeker reports the same problem the second time, how will they recall where the information resides will determine the quality of our documentation.
I would like to use the analogy of a garden, here. Given that the seeker is hungry (and in search of food), should the user documentation talk about the number of trees in the garden or which tree bears what fruits? Or, should it talk about how eating fruit can satiate the seeker’s hunger?
It is true that our work defines who we are. But, in the context of technical communication, we are not jugglers, but gardeners. We curate our own gardens of information that bear the fruits of empowerment. Our job, unlike the mechanical work of juggling, then, is to enable a fruitful conversation. It could be as simple as enabling the seeker to pluck a fruit to satisfy their hunger. Or, as complicated embarking the seekers on a journey from the root to the fruit or the other way around, depending on the way they wish to travel.
Suyog Ketkar is a certified technical communicator by profession and writer by choice. Throughout his career, he has empowered the seekers of information. He has spoken on content and design interoperability at the STC India Annual Conference. In the recent past, he has written for and has co-edited Indus, which is the STC India newsletter. His articles have also appeared in PMI Chapter magazine and in the Annual Conference magazines for the STC India Chapter in 2015 and 2018. In 2017, he released, The Write Stride-A Conversation with Your Writing Self, a book on writing. He is currently working on his second book.