What are voice assistants?
A “voice assistant” is a software solution that outputs information in the form of spoken language. It does this based on speech recognition, which analyzes verbal input and interprets it using keywords to identify the message the user wants to convey.
The voice assistant selects between a number of predefined options and provides a verbal response. If anything is unclear, the assistant asks questions to find the right information. Essentially, it filters through the various possibilities, creating a back-and-forth conversation with the user. Apart from voice recognition and output, a voice assistant works much like a chatbot, so this term is sometimes used as a synonym.
Voice assistance: How does a conversation work?
In the best-case scenario, a dialog with a chatbot should work just like a conversation with a human. For example, you ask a question and the chatbot responds, ideally with the right answer or a query that moves you closer to a solution.
Basically, this involves the following steps:
- You ask a question.
- The chatbot uses your speech as input.
- It determines a relevant follow-up answer.
- It provides output and waits for new input.
Unless you are an insider, language analysis is an incredibly complicated process. So we won’t go into the technical background here. For our purposes, it’s enough to say that automatic speech processing and artificial intelligence have made significant advances on the road to satisfactory solutions.
Advantages of voice assistants in technical writing
A positive user experience is key for any technical writing team. These days, smart information is collected throughout the company and pooled in a central location to enhance the user experience. So why not create technical documentation that users can talk to?
The advantage of this is that you’re using a conversation to search for and take in information. This leaves your hands free, which makes it easier to work on the product at the same time. Users don’t have to switch back and forth between the instructions and working on a machine or device. Another big advantage of a voice assistant is the speed at which information is provided. People who have difficulty seeing or reading also stand to benefit from voice assistants.
From the service provider perspective, chatbots are a good way to free up capacity in the team, especially for time-consuming questions that get asked again and again. Voice assistants are also seen as innovative, which gives your brand image an edge.
What companies need to consider when using voice assistants in technical writing
- A voice assistant does not work perfectly in every situation, for example, with loud background noise, dialects, and accents.
- Users can become frustrated if a voice assistant struggles with speech recognition, asks pointless questions, or gives unsuitable answers.
- Safety and legal compliance are paramount in technical documentation, so it’s especially important to ensure that the voice assistant is providing correct and up-to-date responses.
- Because user data are processed when using voice assistants, data protection requirements also have to be met.
- Some users won’t be willing to use a voice assistant, as they still prefer speaking to a human.
- The technical documentation has to be modular in structure, and the information units need to be tagged with metadata. For some technical writing teams, the first step will be laying the groundwork before they can start using voice assistants.
How does the chatbot get its content?
This raises the question of, how does the chatbot come up with a relevant answer that moves the line of questioning forward and fits the asker’s situation and target group? And where does it get its information from?
Let’s look at the following situation: Someone is asking for information on replacing a valve, which means this is a maintenance scenario. The parts that are directly affected are the valve and powder coating system, with the valve forming part of the overall system. Both the valve and the system are available in different forms or versions, so the valve to be used depends on the type of system.
The chatbot can obtain certain information from the input provided by its conversation partner. If they don’t provide this information in sufficient detail, the bot needs to follow up (“Which valve do you mean?”, “Which model is your system?”). Certain keywords also provide an idea of the context (for example, “replace” is a typical keyword in the maintenance setting).
Other information has to be stored in the chatbot system ahead of time. This includes:
- Which system models are available
- Which (serviceable) parts they consist of
- That the pinch valve (type B with nominal diameter of DN 65) is one of these parts
- That it is installed at the extraction unit
- The technical data of the valve and, in particular,
- The size (nominal width) of the valve
If the asker hadn’t answered “No” to the assistant’s offer of “Do you need help replacing the valve?”, then they should have been given the corresponding instructions for this exact maintenance activity for this exact model of the system. If you know a bit about content, you’ve probably already noted the connection between these data and the data that are maintained for technical documentation: A chatbot can only provide accurate answers if the required data are available in modular, classified form.
Classified data for informed answers
A fitter who asks about a specific valve for a specific maintenance task needs different answers than an engineer who wants general information about the component for product development purposes. This is where metadata come in and control what information is selected for the specific situation by classifying the corresponding information module and providing information about application scenarios where it can be used (e.g., installation, maintenance and servicing, product information).
The process of selecting components – in the above case this includes both the valve and the corresponding system – often leads to questions, such as which subtype of a given category a product belongs to (Which system model is this in our product range? The system has a number of valves; which one is it?). Taxonomies, for example, can help to clarify imprecise input by mapping part-whole and quantity-subset relationships. This structure helps the chatbot ask increasingly detailed questions and zero in on the right content to output.
But the answers can also vary depending on the person asking the question. In this case, metadata can also be used to define user rights so administrators receive more specific information than standard users, for example.
While certain subtasks involved in the chatbot dialog are machine based, such as analyzing linguistic input, the technical writing department is still in charge of the content. This team’s job is to record, structure, and classify the content so answers make sense and live up to the chatbot’s promise of providing the right answer for the relevant user and situation.
A modern, XML-based content management system like SCHEMA ST4 is the tool of choice for creating and managing these information units. It offers all the options and functionality mentioned above, including creating modular information units that can then be used and combined as needed, categorizing content based on metadata (which can also be automated with the ST4 AI Jetpack), and creating and integrating taxonomies to map the relationships between the content. Thanks to built-in translation management, even multilingual chatbots are becoming reality.
Progress report: How Dokuschmiede put a voice assistant into action
Gerhard Glatz and Lara Krägel are technical writers at Dokuschmiede, a service provider for technical communication and information design. In this interview, they talk about their experiences and explain what technical writing teams should look out for when using voice assistants to output content for technical documentation.
Quanos: You have experience of implementing document content on a chatbot platform. I’m playing devil’s advocate here but, is that kind of thing really necessary?
Lara Krägel: Absolutely. A lot of people don’t realize how often we already use chatbots these days. Most people think it’s just about simple question and answer bots on websites.
Gerhard Glatz: Exactly! And they forget that Alexa, Siri, and co. are just as much chatbots as the voice-control systems in their cars. Chatbots are integrated into lots of other devices and contexts too. We separate chatbots into textbots that communicate with people via written language and language assistants that can even process and output spoken language.
Quanos: When does it make sense to use a chatbot?
Gerhard Glatz: Voice assistance is a particularly useful format when your hands are full. This might be when you’re doing maintenance work or using household appliances, such as cooking in the kitchen.
Lara Krägel: But, regardless of that, a chatbot is a great option for anyone who prefers to communicate by speech rather than reading long texts. It also offers a user-friendly alternative for people with a visual impairment or who have difficulty reading.
Quanos: You’re big proponents of chatbots, but what was the journey to develop the chatbot like? Did it all run smoothly?
Lara Krägel: Well, developing a chatbot takes some doing. That being said, it all went to plan. It’s probably down to the fact that we put a lot of design and planning work into the early stages. This paid off over the course of the project.
Gerhard Glatz: That’s right. We laid the main groundwork from the word go and split the project into two processes. Lara took care of the content. People tend to forget that preparing for the chatbot involves a load of content work.
Lara Krägel: There was a lot of work to do when it came to choosing the technical system and developing the bot too. Gerhard was responsible for that. But we worked closely with each other throughout the whole process, of course. Doing your own thing in isolation just wouldn’t work here.
Quanos: What had to be done on the content side?
Lara Krägel: We started with a target group analysis. This too proved that all the early design work was worth it. After that, we started editing the content. It helped a lot that the document data was already in a CCMS, because not all document content is suitable for chatbots. If the data are already available in topic-oriented form then they’re easier to identify. It also helped that a lot of the metadata were already tagged in the CCMS, so we were able to use them for the chatbot. After all, a content element has to know from somewhere what customer request it’s meant for. The dialog structure is another important aspect. It’s not enough if the bot just reads out a piece of text. In the event of uncertainties, it has to make inquiries, e.g., when there are preconditions for an action, or go through a chain of actions step by step.
Quanos: And what was it like on the technical side?
Gerhard Glatz: The first step was choosing the bot. There are now many systems that range in complexity from simple FAQ systems and script bots, right through to real, virtual agents. The more complex the solutions, the more options you have, but the more complex it is too when it comes to programming and editing content for the bot. Ultimately, we decided to opt for a solution with Google Dialogflow and have developed a voice app for the Google Assistant. The advantage of this was that we could use Google’s sophisticated speech recognition and output technology.
After that, we developed the bot. Lara’s content played a pivotal role here because it helps to give a better idea of how the dialog situation unfolds and how the bot will need to behave. We developed an interface that prepares content and partially reformulates it so that content from the CCMS can be reused in the chatbot. We needed a dedicated publication route for this. The document content that serves as answers to user questions in the bot is fed directly into the bot platform. As a result, the data doesn’t need to be maintained or managed at multiple points and the single source aspect remains. Then, when we were fairly satisfied, we evaluated the whole system from top to bottom and came across a couple of weak points. And finally, the bot had to be published. But now it’s here. Anyone who’s interested can watch a demo of our new, virtual colleague on our website.
Quanos: You’ve managed to implement an exciting project here. Last but not least, I’m interested to hear your opinion: Will we get all our documentation from bots in the future?
Lara Krägel: All from bots…I wouldn’t go that far. Like we’ve already said, there’s some content that isn’t as suitable for bots. And then there are people who just prefer to read. Bots definitely won’t be able to replace all output formats but I think that in future they will certainly play an important role in the world of documentation since they present a useful, supplementary format in many different contexts.
Gerhard Glatz: Without doubt. There’s already a wide range of applications. And people’s usage habits are changing. More and more people prefer to communicate through speech and dialog instead of reading long texts all the way through. So, in any case, bots are definitely on the rise.
