Usability rules for bots

Original author: Kevin Scott
  • Transfer
image

In 1990, Jacob 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 emerge. But while there is some chaos and the lack of common 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 quick feedback.

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, and 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 posts 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 restrictions on 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 at the same time, do not overload him with information. How to reach this middle ground?

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

In addition, good and quick feedback is a matter of course. Bots must respond quickly, and if a network request takes some time, then the user should not just sit and wait. A great idea is an icon 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 must communicate with the user in a language that he understands. It is better to use words, phrases and concepts that the user is familiar with, rather than some highly specialized terms. Everything should 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 indeed a difficult task, and the bots will not have enough intelligence for this, at least in the short term.

Chatbots, in fact, do not really know how to communicate. Even those 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 so far makes false promises. Although, perhaps, the problem is not at all in technology, but in promises . - Cade Metz, Wired

image

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 be spoken to in normal human language. Others prefer to slang and cut back on 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 entering into a long dialogue. That is, be sure to provide the user with the ability to cancel and restore.

Communicating in real life, we cannot cancel or restore what was said (very sorry), but when talking with a bot this is possible.

image

We must understand that the “fat finger” problem leads to all sorts of typos 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 interaction.

4) Uniformity and standards. The user does not have to sit and wonder if different words, situations and actions mean the same thing. Follow generally accepted rules inside the platform.

The rules for platforms are still under development, but we need to understand this heuristic so that bots must respect the internal uniformity: the bot must adhere to the same 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 highlight the commands in capital letters, for example, HELP or NEXT.

5) Prevention of errors. Better than good error messages can only be thoughtful design, which, in the first place, will prevent the problem. Either eliminate the conditions that lead to errors, or identify errors and provide the user with the option of confirmation before he performs the action.

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

6) In sight, and not from memory. Do not load user memory, let all objects, actions and options be visible. The user does not have to memorize information while moving around the system. All system instructions should be visible or easy to retrieve if necessary.

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

When we wrote our Emojinary bot, we tested usability, trying to understand why we can’t keep users at the onboarding stage. As it turned out, users read the first message, and then were distracted by something else. They missed all the other messages. When we ask them to read the messages more carefully, all their distraction evaporates.

This is a good example of a failed bot development. If users do not read and do not understand our messages, then this is only our fault.

And again we need to reach the middle ground. On the one hand, we don’t want to overload the user with a wall of continuous text, on the other hand, we need to talk about the main options at each stage of interaction.

Facebook found a great 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, one cannot blindly rely on structured messages, why, I will tell in the next section.

image

7) Flexibility and efficiency. Accelerators that a novice will not notice can significantly optimize the interaction of an experienced user, so the system should be convenient for users of any level. Let users have the opportunity to adjust frequently performed actions for themselves.

Many bots written for Slack can be called up with the following commands:

/ giphy hotdog

And the corresponding GIF will be uploaded to the channel.

image

Bots have enormous 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 go to the bottom of the matter and ask a command.

The question remains open for me: what is the best way to help users discover such magical actions? How to make their interaction more advanced so that they do not turn to the help tab every time?

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

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

image

“Hello. How are you?"

How can a bot respond to requests that are not related to its core competency? Should they adhere strictly to the case or can they allow some frivolity? If I am a bot and sell shoes, and you ask me about my life, do I need to maintain 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 makes up the personality of the bot. If you create a nice personality, this will distinguish your successful bot from everyone else.

Imagine that you pick up a pair of shoes on Zappos. The bot is friendly, talkative and very helpful. I don’t even want to go straight to the point. I want to get to know the Zappos bot better. And vice versa, if I talk with a lawyer bot, I expect a more professional dialogue, because lawyers will probably bill me for this conversation (just kidding!)

image

There is a difference between the content (information) and the environment (personality). Content may be minimal, but not necessarily restrict personality. If I am interested in how you are doing, I expect you to answer me. Bots that cannot make a user happy, inevitably disappoint him, and you 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 displays the disgusting phrase "error 500", you are doing everything wrong.

10) References 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 tasks of the user, indicate specific steps that need to be taken and not be too voluminous.

And that also still exists. References and documents should be available directly through the bot. I believe that over time, common standards will be developed regarding the best way to get documentation, but for now, just make it so 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 memory”. Both heuristics assume 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 confirmation and cancellation options. Finally, the heuristics “Similarity of the system with the real world” and “Identify, understand and correct errors” imply unity in the language.

Thus, we have six relevant heuristics left:

1. “Awareness of the state of the system” and “In sight, not 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 communication style.

3. “Freedom of action and control” and “Prevention of errors”. At critical moments, get confirmation from the user and give him the opportunity to cancel 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”. Respect the unity in the style of communication and personality / voice of the bot.

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

image

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

I want to compare these three bots, since they were the first to appear on Facebook Messenger:

• Poncho

• CNN

• 1-800-Flowers

Poncho


Poncho immediately disposes to himself that he gives a hint of what needs to be done, namely, to talk about the weather.

image

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

image

So far, a wonderful dialogue is taking shape. We’ll 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 opportunity to “cancel”, that is, I can edit the information provided.

Let's see what happens if I say no:

image

It’s decent, although I don’t really like that Poncho asks completely identical questions (Is this the right city?). And I almost forgot that I'm talking to the bot, I will no longer be so simple-minded.

Okay, now I’ll answer “yes.”

image

I got the weather forecast and got the next call to action. I don’t want to receive notifications yet, but thanks for asking, Poncho.

image

Great work was done to provide in-line 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:

image

Briefly and clearly


Poncho also does a great job with banter, and when you get to a certain point, it brings you back to the heart of the conversation:

image

Verdict:



1. “Awareness of the state of the system” and “In sight, not memory”. Answers inquiries regarding the status of the system. Provides structured messages to guide the user.

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

3. “Freedom of action and control” and “Prevention of errors”. I made a “mistake” when I entered my location, and Poncho allowed me to fix it. Excellent.

4. “Flexibility and efficiency.” If I return, Poncho will remember my location and I won’t have to press the keys again.

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

1. "References and documentation." A great example of when everything is done as it should.

Poncho did a great job.

CNN


The next bot is CNN.



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

image

Although the CNN bot is definitely not the one I'd like a glass of beer with, it does its job when it needs to direct my actions. I am more inclined to consider this bot as a simple command line than an interlocutor.

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

image

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 sight, not memory”. Structured messages are very clear, but the bot cannot adapt to regular messages. In some 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 virtually no way to interact outside structured messages.

3. “Freedom of action and control” and “Prevention of errors”. 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 does not matter for it whether you are a beginner or an advanced user.

5. “Uniformity and standards” and “Aesthetics and minimalism in design”. Constancy is observed, but there is no individuality. This is similar to viewing the tape in the messenger.

6. "References and documentation." There is built-in help, although there is a feeling that something is missing. For example, why do you need the “Ask CNN” button?

1-800-Flowers


image

The dialogue begins with a structured message. Honestly, there is no desire to have a conversation with this bot. Let's see what happens if you click the “Talk to Support” button.

image

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

image

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

image

Confirmation of action is also well used here.

image

I did not like this interaction. Users are forced to respond to structured messages, there is a feeling that we are limited in something. However, it’s not bad that they were able to encourage me to ask for help.

image

I left the bot alone for a while, and here's what happened next:

image

But this is nice!

Verdict


1. “Awareness of the state of the system” and “In sight, not memory”. Effective use of structured messages to guide user actions.

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

3. “Freedom of action and control” and “Prevention of errors”. Great job done, I was able to return and change my order.

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

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

6. "References and documentation." Good built-in help.

Conclusion


Nielsen did an excellent job. But I think that for bots a few more similar heuristics can be derived.

We made sure that all three bots did a good job, made it possible to prevent and fix errors, and all three bots provide built-in help. This greatly contributes to 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 heuristics are still relevant and serve as a starting point for evaluating the usability of bots.

Also popular now: