This is the last post of our Software Support and Artificial Intelligence series. You can find an overview on our introduction post.
If you want to be notified when we publish more articles about AI and documentation, make sure to sign up for our mailing list.
Artificial Intelligence for documentation and support: how it could be done
AI is a game changer, and is slowly but surely transforming every possible industry. While smart automated proactive support might sound like a pipe dream on first sight, I believe that the technologies needed to make AI work for documentation are already available today.
The same type of technologies that have been developed to personalize shopping experiences can also be used to deliver personalized and contextualized documentation. As in personalized marketing the system will need to identify users, differentiate them, figure out how to interact with them, before the UI is customized for them.
Wikipedia: Personalized marketing, or one-to-one marketing, is a marketing strategy by which companies leverage data analysis and digital technology to deliver individualized messages and product offerings to current or prospective customers. Advancements in data collection methods, analytics, digital electronics, and digital economics, have enabled marketers to deploy more effective real-time and prolonged customer experience personalization tactics.
You could argue that the differentiation process will be harder when you use this technology for documentation purposes because the interest profile of a user will depend on what they don’t yet know about a system and what they are currently doing, rather than their demographic and long-term interests. So it will be evolving much faster than the kind of profiles marketing personalization have been developed for. Currently marketing personalization uses market segmentation to create profile groups that get a certain experience. In a documentation case I think it won’t be possible to create a fixed group, we hypothesize that we will need to create a sliding window of users that benefit from a given type of documentation.
So the problem is more complex, but several technologies already allow for fluid triggering mechanisms. News magazines have implemented technologies that allow them to change site content based on behaviour. Graph databases like Neo4j are being used to personalize experiences without the need for data analysts to reduce customers to discrete segments. Instead relationship patterns are deducted by an algorithm.
Recently there also has been a string of announcements of larger AI players that intend to open source their Artificial Intelligence tools. Tools like
Google’s TensorFlow allow us to build neural networks that can find and react to patterns without ongoing human intervention at a fraction of the previous cost of similar technology. With these technologies it will become possible to differentiate groups of users that the product owners might not even realise to be distinct groups.
Personalized documentation as a message
Any personalized help will need to take the form of messages that are triggered when relevant documentation content is available in a given context. To some extend walkthroughs already work that way, that is why they function really well in an onboarding context, where customer requirements are more predictable. But especially for on-going education purposes, there is an opportunity to personalize help interventions instead of always showing the same content when a learning context is recognized. In addition to the environmental context, past behaviour and profile information could be used to build a probabilistic model that predicts the likelihood that a customer will want to interact with a specific piece of content.
Personalized embedded documentation requires new form factors
Depending on the likelihood of interaction, different form factors could be used for the embedded documentation. If a user rarely interacts with messages, but a message is very important, a more intrusive format could be used. If it is likely that a user will take offense at being interrupted, a less intrusive message format that leaves it to the customer to initiate a learning interaction could be chosen instead.
The following are a few interaction formats that we are considering for our system:
A help center is an expandable widget, typically embedded in the bottom right corner of a web application. While its primary purpose is to give a visitor contextual help, a help center can also be used to add other support features like chat and documentation search without cluttering the interface.
In a previous blog post we described how WalkHub can be used with Drupal 8 to create an embeddable help widget. With a smart targeting system it becomes possible to add contextual help links into a predefined help grouping. For a given page and user context this would result in a personalized documentation list. e.g. if you are an admin you get to see configuration help.
- Intrusiveness: nearly invisible, there when a user needs it
- Persistence: ideally the links in the help center would remain the same between page loads
A widget similar to the help center could also be used as a message tray in which a chat robot shares possibly relevant content. Any new messages could be indicated with a grey dot, the arrival of an important message that needs to be read could be indicated with a number in a red circle. This model would be especially interesting for content that a visitor needs to see that is less context sensitive. For example when a new set of documentation has become relevant to a user after they enabled a new feature.
Chat infrastructure could also be used to provide personalized and contextualized search functionality. While a search result page makes it easier to compare and evaluate hits, a smart search engine with sufficient information about the visitor should be able to return a single most likely relevant result, much like a human would answer with a single result with the option to expand into more answers when necessary. You could imagine that such a chat function will replace the search box most websites currently have.
- Intrusiveness: the red circle with a number is a UX pattern used across mobile platforms and applications. Because of its ubiquity we have been conditioned to open message trays with the red icon. Users keep control, but are being nagged to open the tray to read their messages.
- Persistence: ideally messages should not be removed until a visitor reads them.
Slack is widely praised for its onboarding. When product owners ask their UX designers to create a conversational UI, it is almost a given that Slack will be mentioned as an example. Slack used to have slowly blinking highlights next to elements that users could expand into a tooltip. Recently these highlights were removed, you can find a theory why this happened on this blogpost about the evolution of Slack’s onboarding experience
. Slack later switched back to more conventional Walkthroughs for onboarding. But Slack is a single page app, with a very focused UI. When you are not as slick as Slack, you might need a bit more ongoing education. That is when the slow blinking icon could be of use.
- Intrusiveness: highly visible, somewhat intrusive
- Persistence: highlights could be added and removed as the user’s context changes
Walkthrough tutorials - also known as “Guided tours” - are onboarding mechanisms that use a sequence of tooltips - text bubbles that point to an element in the UI - to explain how a web application works. A guided tour works as a demo, showing users the process first and then letting them follow it, while a walkthrough takes the users through the process step by step.
We’ve covered Walkthroughs extensively in previous blogposts, because WalkHub - our product - was developed as a Walkthrough recorder.
- Intrusiveness: In most cases highly intrusive, but it depends on how they are triggered. If the user has control over when they are triggered and if there is a way to exit the walkthrough this can be somewhat softened.
- Persistence: Walkthroughs are ephemeral, often users don’t have any control over when they will be triggered. They start when a trigger event happens and users are expected to follow them through. Once they are finished, they are gone.
The same infrastructure can also be used to trigger custom snippets of Javascript that implement a more complex interaction. Especially on maps, sliders, and other non-standard UI elements this could play an important role.
From manual personalization rules to AI driven interventions
We think that the quality of documentation interventions could be significantly improved if we can model how likely a user is to interact with a message and how likely that interaction will result in a positive outcome. This would be (nearly) impossible with static rules, there are too many interdependent factors, but a neural network might be able to integrate all the information into an optimal interruption strategy, much like a helpful co-worker would.
Making AI a reality for documentation
We are preparing a pilot project for an established SaaS company that would like to test proactive embedded help on one of their products. Technically we are exploring what our options are to implement an AI driven embedded documentation / proactive support system. Ideally we would like to build this as an open source solution stack that allows our customers to build a system for their SaaS packages that they can own. If you would like to stay informed about our progress or if you would like to run a pilot study, get in touch!
Other posts in this series:
Part 1: Documentation at a crossroads
Part 2: The Helpful co-worker model
Part 3: Clippy: misunderstood brilliance before its time
Part 4: Repeating Clippy’s mistakes with Walkthroughs
Interested in AI for Documentation? Sign up and we’ll email you updates on our research.
