Is your documentation AI and chatbot ready?

It seems likely Artificial Intelligence (AI) and chatbots will play a key role in helping users, in the future. Amazon, Facebook, Google, IBM and Microsoft, as well as smaller technology companies, are all developing platforms for simulating an intelligent conversation with human users.

This raises a question:

Will chatbots mean we’ll write a how-to task in the chatbot app, again in the Help, and again in the tutorials?

It’s not very productive to write the same content three times, in three different places. It makes even less sense if you need to update the content on a regular basis, or translate that repeated content into multiple languages.

One solution is to store different types of data in its native format until it is needed, and then serve that information to the AI or chatbot system. You write the content once, and “serve” it to the chatbot, the online Help, the tutorial, and so on.

This requires that content to map accurately to the chatbot’s information structure  –  the use cases; the user’s intent, role and sentiment; and the entity (i.e. the problem and product) that relates to the user’s question.

As a technical communicator, this means you can start by making sure your content is in a structured format. For example, it has metadata (and uses a taxonomy) that will help the AI system or chatbot know which piece of information to serve the user. This includes common metadata such as product, symptom, problem, version, user role and operating system. It may also include new metadata relating to responses based on the user’s current mood (“sentiment”),  and the context in which the question is made to the chatbot.

This approach makes it more likely that your documentation will AI and chatbot ready, at the time when it’s needed.


Tryo Labs has published a useful summary of the different approaches and technologies you can use for creating chatbots. See: Building a Chatbot: analysis & limitations of modern platforms.

See also:

Towards content lakes

Cherryleaf’s technical writing services

The ROI of user documentation: you could break even if you avoided 3 support calls per week 

We’ve been experimenting with another spreadsheet for calculating the Return on Investment (ROI) on User Assistance.

We wanted to look at: how many support calls an organisation needs to have resolved by users reading the Help content instead of calling Support, before it starts to see a return on the cost of creating the Help.

Using typical costs for an average sized software application, the figures suggest you could break even if you avoided 3 support calls per week.

Chart showing the ROI of user documentation

Contact us if you’d like a copy of the spreadsheet, so you can make your own calculations.

You also find a related Support call cost reduction spreadsheet on the main Cherryleaf website.

Just in time documentation – some pros and cons

Bri Hillmer has written two articles on Just-In-Time documentation (https://www.knowledgeowl.com/home/just-in-time-documentation-a-practical-guide and  https://www.knowledgeowl.com/home/just-in-time-documentation). This is an alternative to what she called Just-In-Case documentation. The idea is you write topics that answer real world queries users ask the Support team. This rather than writing a comprehensive user guide, just in case someone wants to know about topic X or topic Y.

This approach focuses on user needs, answering the questions user have. It also provides users with worked examples, each one aimed at solving a particular scenario. In a complex environment, users may need to combine a set of functions or features in order to solve their problems. Sometimes a topic-based approach doesn’t provide that type of information. Just-In-Time documentation could help users understand individual features and how to combine them. And it may be that 80% of the queries relate to 20% of the product’s functionality.

However, this approach does require the technical authoring team to be able to turn around these articles quickly enough. It’s likely that similar topics will come up a regular basis, so there also needs to be a way to reuse some passages of text, in order for the Technical Authors to work in an efficient manner. Also, there might be a legal requirement to provide a comprehensive guide.

Is this an approach you have used? If so, please share your experiences, using the comments box below.

Is documentation a dirty word?

Daryl Colquhoun has written an article in tcWorld about the international standard ISO/IEC/IEEE 26512. He explained the standard is going to be revised and renamed: from “Systems and software engineering – Requirements for managers of user documentation” to “Systems and software engineering – Requirements for managers of information for users”.

The reason for this, he states, is because, in many parts of the world, the term “documentation” is associated with a printed manual only. The neutral term “information for users” refers to all types of content: Online help, audio, video, and Augmented Reality.

The problem with “information” is it can mean many things. Information for users could mean the weather forecast. We may well need to move away from the word documentation, but I’m not sure we’ve yet come up with a suitable alternative.

 

Documentation as an API – the docsbot

In a recent presentation, Twilio’s Jarod Reyes and Andrew Baker mentioned their plans to make Twilio’s developer documentation available as an API. They plan to start with an API for code samples, stored in a github repository.

Making documentation available as an API means means users can create or remix their own versions of the documentation. For example, they could embed Twilio’s code samples. It also means those embedded code samples will be updated whenever Twilio updates those snippets of code.

Jarod and Andrew suggested something new that we’d not heard before – the API can also be used to create a “bot” in Slack, to help new users. The Twilio bot, currently in development, is called docsbot. If users type “lookup py” in the Slack command line, docsbot will reply with a message containing a code sample for the Python development environment.

Twilio's Slack docsbot

It relies on users knowing the relevant Slack commands, but it’s an interesting way of providing users with documentation when and where they need it.

See also: Advanced technical writing & new trends in technical communication training course 20th October

Documentation as Code

Tom Johnson has written two interesting posts on his blog on the “Documentation as Code” concept:

Documentation as Code can be interpreted in a few ways. Tom describes it as being able to store the documentation with the code:

From a technical angle, Etter argues that one should embrace lightweight markup languages, use static site generators, and store content in version control repositories with engineering code.

An other interpretation associated with this is that documentation should be seen as a design problem; it should be seen as part of the product (and seen in a similar way to the software code), rather than an add-on. If the documentation is stored with the code, it can mean that the requirements for documentation can be more closely linked to the code. When a requirement for a new feature is raised, so can a requirement for the related documentation. It can also mean that content that’s embedded in the UI, presented as on-boarding screens or presented as online Help, can be considered as different potential solutions to each user need.

Documentation as Code is a topic we touch on in our advanced technical writing training course. It’s an approach that we may see growing in popularity.

General Data Protection Regulation – will this affect online Help?

Yesterday, I saw a presentation by Hazel Southwell on the EU’s General Data Protection Regulation (GDPR), which will be implemented on the 25th May 2018. The impact in its data privacy and protection rules seem likely to affect pretty much every website, with the threat of hefty fines for those that do not comply.

Organisations providing personalised Help content, by storing information in cookies or monitoring the behaviour of users living in the EU by tracking their digital activities, will need to comply with the GDPR regulations. In particular:

  • Businesses will have to adopt governance and accountability standards and meet their data privacy obligations.
  • Clear and affirmative consent to the processing of private data must be provided, and the relevant information must be laid out in simple terms.
  • Organisations need to consider the risks of transferring data (such as the storing of cookies or IP addresses) to countries outside of the EU.

One solution is to require users to log in to see information. However, this may be an unpopular and impractical solution for many users.

How technical documentation helps the customer journey

Here is a diagram that shows the different types of User Assistance that can help users as they progress through the customer journey:

how user assistance helps the customer journey

Supporting the user through the customer journey has become more important, partly because the subscription, “try before you buy”, sales model means users can stop being a paying customer at a moment’s notice. Today, all of the information you provide, both pre- and post- sales, needs to provide the same consistent, high quality, experience to the user.

Have we missed anything out? Let us know if you think the image should be changed in any way.