Usability rules for bots

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

Standards and advanced methods of creating bots will continue to appear. But so far there has been a certain chaos and lack of uniform standards. Are Nielsen heuristics applicable to bots? Let's see which of them have not lost their relevance, and check them on the example of three popular bots.

Ten Nielsen Heuristics

1) Awareness of the state of the system. Users should always know what is currently happening with the system. This requires full and fast feedback.
')
The working environment of the bot is a dialogue, and it is governed by the following fundamental factors:

1. Quick conversations. Messages are an inexpensive, one-time communication tool; over time they lose their relevance. A message sent a day ago becomes less important than a 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 strictly limited, and there are also more flexible limitations regarding the number of words that the user can understand and comprehend.

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

Here is what I propose: the system should allow the user to request current information through quick feedback. If we give the user the right to request the system status information himself, then we will be able to avoid overloading with potentially unnecessary information.

In addition, good and fast feedback is a matter of course. Bots must respond quickly, and if the network request takes some time, the user should not just sit and wait. A great idea is a badge that shows the other person that you are responding. And phrases such as “we are working on it ... give us a couple of minutes” say that you care about your users.

2) The similarity of the system with the real world. The system should communicate with the user in a language he understands. It is better to use words, phrases and concepts with which the user is familiar, and not some highly specialized terms. Everything has to happen, as in the real world, where information appears naturally and logically.

Learning to speak the user’s language can only be done by starting it.

The problem is that understanding the language is really not an easy task, and the bots will not have enough intelligence to do it, at least in the short term.

Chat bots, in fact, do not know how to communicate. Even those created using the latest technologies can understand only a limited set of phrases and apply a limited number of answers. At the moment, a conversation with a bot is communication with a machine. Therefore, conversational commerce has so far made 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, while others expect to speak with them in a normal human language. Others prefer to speak slang and abbreviate everything. Bots should be created with a clear understanding of the target audience.

3) Freedom of action and control. Users often select some functions of the system by mistake, and they need an “urgent exit” button to restore the previous state of the system without engaging in a long dialogue. That is, be sure to provide the user with the ability to cancel and restore.

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



We must understand that the problem of "fat finger" leads to all sorts of typos and misunderstood messages. Dialogues with bots should have a “emergency exit”, and the user should know that he has the opportunity to choose another action at any stage of interaction.

4) Uniformity and standards. The user should not sit and wonder whether different words, situations and actions mean the same thing. Follow generally accepted rules within the platform.

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

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

5) Preventing mistakes. Better good error messages can only be thoughtful design, which, first of all, prevent the problem. Either eliminate the conditions that lead to errors, or identify errors and provide the user with the option to confirm before he performs the action.

Confirmation is important for any type of interaction. Designers should develop interactions, bearing in mind that errors occur quickly and often, and the user in this case should not lose the feeling that he is communicating with the person. During any critical moment, ask for confirmation of the user action.

6) In plain sight, not from memory. Do not load user memory, let all objects, actions and options be visible. The user should not memorize information while moving around the system. All system instructions should be visible or easily retrieved when needed.

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

When we wrote our Emojinary bot, we checked usability, trying to understand why we cannot keep users at the onboarding stage. As it turned out, users read the first message, and then they were distracted by something else. They missed all other messages. When we ask them to re-read the messages more carefully, all their absent-mindedness evaporates.

This is a good example of bot development. If users do not read and do not understand our messages, then it is 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 hand, we must tell about the main options at each stage of interaction.

Facebook found a great solution and created structured posts. 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, why, I will tell in the next section.



7) Flexibility and efficiency. Accelerators, which novice will not notice, can significantly optimize the interaction of the experienced user, so the system should be convenient for users of any level. Let users have the opportunity to customize often performed actions.

Many bots written for Slack can be invoked with the help of some such commands:

/ giphy hotdog

And the corresponding gif will be loaded on the channel.



Bots have a huge potential for providing such accelerators to advanced users. While one user asks: “Hello, Giphybot, can you find a picture with a hot dog?”, Another user will immediately get to the point of the matter and set the command.

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

8) Aesthetics and minimalism in design. In the dialogs should not be too much information. Any unnecessary information in the dialogue will compete with the necessary information, making it less noticeable to the user.

Judging by their experience, beginners absolutely always talk to the bot as a person:



"Hello. How are you?"

How can a bot respond to requests that are not related to its core competency? Should they adhere strictly to communication in the case or can they allow some frivolity? If I am a bot and I sell shoes, and you ask me about my life, do I need to support this conversation? Or should I gently steer the conversation in the right direction? And if so, to what extent can I push you to talk about shoes? If I can poke fun at users, to what extent?

All this constitutes the identity of the bot. If you create a pleasant personality, this will distinguish your successful bot from all the others.

Imagine that you are picking up a pair of shoes for Zappos. The bot is friendly, talkative and very helpful. I do not even want to go straight to the point. I want to get to know the Zappos bot better. Conversely, if I talk to a lawyer bot, I expect a more professional dialogue, because lawyers will probably bill me for this conversation (just kidding!)



There is a difference between content (information) and medium (personality). The content may be minimal, but not necessarily limit the identity. If I am interested in how you are doing, then I expect you to answer me. Bots that cannot make a user enjoyable will inevitably disappoint him, and one can no longer expect that the dialogue will take place at the proper level.

9) Identify, understand and correct errors. Error messages should be written in simple language (no codes), clearly indicate the problem and offer a constructive solution.

Imagine this still exists! If your bot gives the disgusting phrase "error 500", you are doing everything wrong.

10) Reference materials and documents. It would, of course, be nice if the system worked without documentation, but sometimes it becomes necessary, as well as in reference materials. The user should not have any problems when searching for any useful information, it should meet the user's tasks, indicate specific steps to be taken and not be too voluminous.

And this also still exists. Reference materials and documents should be available directly through the bot. I believe that over time, uniform standards will be developed on how best to obtain documentation, but for now, just make sure that the user can get the information he needs simply and quickly.

Actual heuristics

Some heuristics are closely related to each other. For example, "Awareness of the state of the system" and "In sight, not from memory." Both heuristics suggest a balance between the amount of information and its sufficiency 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 regarding the confirmation and cancellation options. Finally, heuristics “The similarity of the system with the real world” and “Identify, understand and correct errors” imply unity in the language.

Thus, we have six current heuristics:

1. "Awareness of the state of the system" and "In plain sight, not from memory." Inform the user about the state of the system and possible options at critical moments, give the user the opportunity to request additional information at any time.

2. "The similarity of the system with the real world" and "Identify, understand and correct errors." Get to know your audience better. Do not change the style of communication.

3. "Freedom of action and control" and "Preventing mistakes." At critical moments, receive confirmation from the user and give him the opportunity to cancel their 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 / voice of the bot.

6. "Reference materials and documentation." Useful information should be contained in the bot.



Let's look at the most popular bots and see how they cope with these tasks.

I want to compare these three bot, as they first appeared in Facebook Messenger:

• Poncho

• CNN

• 1-800-Flowers

Poncho

Poncho immediately has to himself that gives a hint what to do, namely, to talk about the weather.



Well, that sounds good, let's talk about it, Poncho!



While there is a wonderful dialogue. Briefly list the advantages:

• There are no misunderstandings about what to do or say

• Poncho confirmed the information provided (my location)

• Poncho gives me the option to "cancel", that is, I can edit the information provided.

Let's see what happens if I say no:



Worth it, although I don’t really like the fact that Poncho asks completely identical questions (Is this the right city?). And I almost forgot that I’m talking to a bot, I won’t be so simple again.

Okay, now I will answer "yes."



I recognized the weather forecast and received the following call to action. So far I do not want to receive notifications, but thanks for asking, Poncho.



Great work has been done on providing embedded documentation, and Poncho even made me ask for help. Wonderful. This is a great example of structured Facebook posts to eliminate any possible ambiguity.

Let's see how clearly the information is presented:

Briefly and clearly

Poncho is also great at teasing, and when you get to a certain limit, he brings you back to the heart of the conversation:

Verdict:

1. "Awareness of the state of the system" and "In plain sight, not from memory." Responds to queries regarding system status. Provides structured messages to direct the user.

2. "The similarity of the system with the real world" and "Identify, understand and correct errors." Poncho speaks my language.

3. "Freedom of action and control" and "Preventing mistakes." I made a “mistake” when I entered my location data, and Poncho allowed me to correct it. Fine.

4. "Flexibility and efficiency." If I return, Poncho will remember my location, and I will not have to press the keys once again.

5. “Uniformity and standards” and “Aesthetics and minimalism in design”. Poncho is a fairly straightforward bot, structured messages: clear and sharp. Poncho is almost always a pleasure to chat with.

1. "Reference materials and documentation." An excellent example of when everything is done as needed.

Poncho did a great job.

CNN

The next bot is CNN.



CNN correctly uses structured messages. However, there is no longer a sense of dialogue, rather, it looks like a command line.



Although the CNN bot is definitely not the one with whom I would like to skip a glass of beer, he does his job when he needs to direct my actions. I am more inclined to think of this bot as a simple command line, rather than an interlocutor.

I get news, but I don’t quite understand what I can do here. In my opinion, this bot is too fixated on interaction through structural messages. The query “Ask CNN” also did not clarify anything.



This bot does its job, but it’s kind of mediocre. It's easier for me to go to the website.

Verdict

1. "Awareness of the state of the system" and "In plain sight, not from memory." Structured messages are very clear, but the bot does not manage to adapt to ordinary messages. In places, the call to action is not entirely clear.

2. "The similarity of the system with the real world" and "Identify, understand and correct errors." There is almost no way to interact outside of structured messages.

3. "Freedom of action and control" and "Preventing mistakes." It is almost impossible to make a mistake.

4. "Flexibility and efficiency." The CNN bot forces you to treat it as a command line, it makes no difference to it, are you a beginner or an advanced user.

5. “Uniformity and standards” and “Aesthetics and minimalism in design”. Consistency is observed, but there is no individuality. It reminds viewing of a tape in the messenger.

6. "Reference materials and documentation." There is a built-in help, although it seems that something is missing. For example, what is the “Ask CNN” button for?

1-800-Flowers

The dialogue begins with a structured message. Honestly, there is no desire to talk with this bot. Let's see what happens if you click the "Talk with support" button.



Heck! I do not want to talk to a man. Cancel, cancel!



Oddly enough, this is a good example of canceling an action.



This is also a well-used proof of action.



I didn't like this interaction. Users are forced to respond to structured messages, there is a feeling that we are somehow limited. However, it’s still good that they were able to encourage me to ask for help.



I left the bot alone for a while, and this is what happened next:



But this is nice!

Verdict

1. "Awareness of the state of the system" and "In plain sight, not from memory." Effective use of structured messages to guide the user.

2. "The similarity of the system with the real world" and "Identify, understand and correct errors." Here is a failure, especially at the end: when I tried to enter the exact date, the bot hung.

3. "Freedom of action and control" and "Preventing mistakes." Great work done, I was able to return and change my order.

4. "Flexibility and efficiency." It's nice that people replace the bot at critical times.Beginners will appreciate this individual approach, and advanced users can go to the order without further ado.

5. “Uniformity and standards” and “Aesthetics and minimalism in design”. It feels like I communicate with a web page in the messenger.

6. "Reference materials and documentation." Good built-in help.

Conclusion

Nielsen did an excellent job. But I think that for bots you can derive some more similar heuristics.

We made sure that all three bots coped well with their task, made it possible to prevent and correct errors, and all three bots provide built-in help. This greatly contributes to the formation of a positive user experience.

Pleasant and convincing communication is the main distinguishing feature of bots that can adapt, unlike bots that are not capable of it. Nielsen's heuristics are still relevant and serve as a starting point for assessing the usability of bots.