Terms of usability for bots

Communications / Contact / Chat

Terms of usability for bots

In 1990, Jakob Nielsen formulated 10 usability heuristics to evaluate user interfaces. These rules have passed the test of time, and now designers have a quick and easy way to evaluate the usability of software interfaces based on universal design principles.

Standards and best practices for creating bots will continue to appear. But so far there is a certain chaos and the lack of uniform standards. Are Nielsen heuristics applicable to bots? Let's see which ones have not lost their relevance, and we will check them using the example of three popular bots.

Ten heuristics of Nielsen

1) Visibility of system status The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

The bot's working environment is a dialogue, and it is governed by the following fundamental factors:

1. Quick Dialogs. Messages are an inexpensive, one-time means of communication, with time they lose their relevance. The message sent the day ago becomes less important than the message received a few seconds ago.

2. Old messages are not relevant. There is no guarantee that older messages accurately reflect the current state of the system. The older the message, the less confidence in its relevance.

3. Limited space. The number of visible characters is severely limited, and there are also more flexible restrictions regarding the number of words that a user can understand and comprehend.

Since messages are short-lived, we must constantly inform the user about what is happening, but do not overload it with information. How to reach this golden mean?

Here's what I suggest: the system should allow the user to request the current information through quick feedback. If we give the user the right to request information about the status of the system, we can avoid overloading with potentially unnecessary information.

In addition, good and fast feedback is a matter of course. Bots should react quickly, and if the network request takes some time, then the user should not just sit and wait. A great idea is an icon that shows the person you are answering. And phrases like "we're working on this ... give us a couple of minutes" say that you care about your users.

2) Match between system and the real world The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.

Learn to speak the language of the user can only start by doing it.

The problem is that understanding the language is indeed a difficult task, and the bots do not have the intelligence for this, at least in the short term.

Chat bots, in fact, do not know how to communicate. Even those that are created with the latest technology can only understand a limited set of phrases and apply a limited number of answers. At the moment, talking with a bot is communicating with a car. Therefore, conversational commerce is still giving false promises. Although, perhaps, the problem is not in technology, but in promises. - Cade Metz, Wired

The most important thing is to know your audience well. Some users will appreciate the style of interaction through the command line, and others expect that they will be spoken in normal human language. Other people prefer to communicate with slang and reduce everything. Bots should be created with a clear understanding of the target audience.

3) User control and freedom Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.

Communicating in real life, we can not cancel or restore said (very sorry), but when talking with a bot it is possible.

We must understand that the problem of "fat finger" leads to all kinds of misprints and misunderstood messages. Dialogs with bots should have an "emergency exit", and the user should know that he has the opportunity to choose another action at any stage of the interaction.

4) Consistency and standards Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.

The rules for the platforms are still in the development state, but we need to understand this heuristic so that the bots must comply with the internal uniformity: the bot must adhere to a single style in the language, be it a natural language, command line, or something mean.

In the case of the command line, it is important to distinguish between keywords and interactions in a natural language. For our bot Emojinary, we decided to allocate commands in capital letters, for example, HELP or NEXT.

5) Error prevention Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.
(Read full article on preventing user errors.)

Receiving confirmation is important for any type of interaction. Designers should develop interactions, remembering that errors appear quickly and often, and the user in this case should not lose the sensation that he is communicating with a person. During any critical moment, ask for confirmation of the action from the user.

6) Recognition rather than recall Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.
(Read full article on recognition vs. recall in UX.)

We did a little research and realized that users do not read very much or read at all. This is not a secret for those who have long been engaged in the creation of sites. But ironically, the bot interacts with the user through text.

When we wrote our bot Emojinary, we tested usability, trying to understand why we can not keep users already on the stage of onboarding. As it turned out, users read the first message, and then distracted to something extraneous. They missed all other messages. When we ask them to reread the messages more carefully, all their absent-mindedness evaporates.

This is a good example of an unsuccessful bot development. If users do not read and understand our messages, it's only our fault.

And again we need to reach the golden mean. On the one hand, we do not want to overload the user with an entire wall of solid text, on the other, we need to talk about the main options at each stage of the interaction.

Facebook found an excellent solution and created structured messages. They got rid of any uncertainty during the interaction due to a hidden set of options with a choice. However, you can not blindly rely on structured messages, which is why, I'll cover in the next section.

7) Flexibility and efficiency of use Accelerators — unseen by the novice user — may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.

Many bots written for Slack can be called up using about such commands:

/giphy hotdog

And the channel will be loaded with the corresponding gypsum.

Bots have huge potential to provide such accelerators to advanced users. While one user asks: "Hi, Giphybot, can you find a picture with hotdog?", Another user will immediately go to the heart of the matter and ask the command.

For me, the question remains: how best to help users discover such magical actions? How to make their interaction more advanced so that they do not turn every time to the "help" tab?

8) Aesthetic and minimalist design Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.

Judging by their experience, beginners absolutely always talk to the bot as a person: "Hello. How are you? "

How can a bot answer queries that are not related to its core competencies? Should they adhere strictly to the communication in the case or can they tolerate some frivolity? If I'm a bot and I'm selling shoes, and you ask me about my life, do I need to support this conversation? Or should I gently turn the conversation on the right track? And if so, to what extent can I push you to talk about shoes? If I can make fun of users, then to what extent?

All this makes up the personality of the bot. If you create a nice personality, then this will distinguish your successful bot from everyone else.

Imagine that you are picking up a pair of shoes on Zappos. Boat is friendly, talkative and very helpful. I do not even want to go straight to the point. I want to get to know Zappos. Conversely, if I'm talking to a lawyer bot, I expect a more professional dialogue, because lawyers will probably charge me for this conversation (I'm joking!)

There is a difference between content (information) and environment (personality). The content can be minimal, but not necessarily limited to personality. If I'm interested in how you are doing, I'm waiting for you to answer me. Bots that can not make the user pleasant, inevitably disappoint him, and you can not expect that the dialogue will be held to the proper level.

9) Help users recognize, diagnose, and recover from errors Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

Imagine, this still exists! If your bot issues an ugly phrase "Error 500", you are doing everything wrong.

10) Help and documentation Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large. And this, too, still exists. Reference materials and documents should be accessible directly through the bot. I believe that over time, unified standards will be developed, as to how best to get documentation, for now, just make it so that the user can get the information he needs easily and quickly.

Actual Heuristics

Some heuristics are closely related to each other. For example, "Awareness of the state of the system" and "In the mind, and not from memory." Both heuristics assume a balance between the amount of information and its adequacy so that the user can make a more informed choice. "Freedom of action and control" and "Prevention of errors" - these heuristics offer the same solution, especially with regard to options for confirmation and cancellation. Finally, heuristics "The similarity of the system with the real world" and "Identify, understand and correct mistakes" imply a unity in the language. Thus, we have six actual heuristics:
  1. "Awareness of the state of the system" and "In the mind, and not from memory." Inform the user about the status of the system and possible options at critical moments, let the user himself to request additional information at any time.

  2. "Similarity of the system with the real world" and "Identify, understand and correct mistakes". Learn better your audience. Do not change the style of communication.

  3. "Freedom of action and control" and "Prevention of errors". At critical moments, get confirmation from the user and give him the opportunity to undo his actions in the case of multi-step interaction.

  4. "Flexibility and efficiency". Provide accelerators for advanced users.
  5. "Uniformity and standards" and "Aesthetics and minimalism in design". Observe unity in the style of communication and personality/bot's voice.

  6. "References and documentation". Useful information should be contained in the bot itself.