Nibu Thomas, Associate Director at Whatfix joins us in this episode of Knowledgebase Ninjas.
Connect with Nibu and Whatfix here:
Key Takeaways:
Nibu has 23 years of experience in technical writing
Nibu has worked in the field of technical writing for 23 years at companies such as AOL, Bosch, GT Nexus and now Whatfix.
He has progressed into a position now where he predominantly manages writers and documentation as opposed to actually writing documentation.
Nibu’s support team are the target customer
Interestingly, Nibu’s support team are the perfect customer for Whatfix’s product: a digital adoption platform. This means that Nibu’s team are naturally looped into the product development cycle to give feedback on the product roadmap.
This gives valuable insight to the product team about their roadmap, but also ensures that the support team are kept up to date with any new potential features and updates that will require them to create documentation.
Contextual content
Nibu states that all content and documentation must be contextual. E.g. you must be aware of what the user is trying to achieve before you start writing. This will make your writing more actionable and useful for your reader.
Another way of saying this is understanding what your user is trying to achieve as they use the feature you are currently documenting. This broader view may enable you to link to other valuable resources or even suggest different methods for your user to achieve their goal or solve their problem.
Nibu’s mantra
Nibu said:
“Tell me and I will forget, show me and I may remember, involve me and I will remember”
He uses this to guide his teams writing style, urging them to include, show and involve their reader in the in the documentation process.
Achieve more by writing less
Contrary to popular belief, Nibu urges writers to actually write less. Technical writers need to understand that users and customers don’t want to read their writing, they want to achieve their end goal.
So actually the goal of the documentation team should be to help the product team build a better product, which over time will mean that the documentation team will write less.
If executed successfully users will be able to effectively solve their problems through the product itself without the use of documentation. Allowing the documentation team to spend less time churning out documentation and more time invested in strategic projects.
Subscribe To Knowledgebase Ninjas:
Quote:
–