.png)
As we have already written, CUI (conversational user interface) is a user interface conception which speaks the same language with a user.
The specificity of the CUI for a chatbot is that at its creation a vast number of scenarios are written down, which should take into account the limited capabilities of the bot interface. The detail and forethought of these scenarios determine the future of this bot. If the bot doesn’t understand and doesn’t respond to requests properly, it will never become popular and won’t yield the desired effect to its owner. Who will again turn to the bot, which asks the same question indefinitely, and can’t move out of the impasse?
When creating a convenient and productive chatbot, based on the concept of CUI, we have identified several important principles. We will discuss them and their role in the life of the bot further.
Communication with the chatbot always happens in one channel, and it restricts the choice. A small screen in the messenger doesn’t allow displaying a huge amount of information, including providing the user with a full choice. It can provide information in turn, but it will be difficult for the user to browse through a large number of outputs. Since the user can’t make multiple choices and click on the buttons inside the dialog, the CUI should be well thought out, taking into account the limitations of the messenger.
Here is the bot case for the site https://pulti.ua, where the bot helps to select and buy the console. And when a request needs to give out a large amount of information, the messenger interface can’t do this. CUI solves this problem by proposing the user to get search results through the website page or to clarify the search details.
Traditionally, when entering the necessary information in the browser forms, the user has some prompts. It is a drop-down list of autocompletion, prompts near the form, and the impossibility of moving to the next stage in case that incorrect values are assumed. The messenger capabilities don’t allow it to be done in the input line, so CUI should get around this limitation and help the user provide the data correctly.
This is the type of auto-renewal on the site:
And in this way we realized the analogy in the chatbot:
In this case, we see how the problem of identifying settlements is solved, for settlements with the same names. What are we doing? We give the bot a chance to ask again if the user doesn’t exactly enter the data: “select one of these options”, or “maybe you meant it …” and set the answer with the buttons. Then the probability of sending the wrong address to the bot is reduced. And it applies not only to addresses. Similarly, you can set the parameters for the user’s response: “enter your phone number in the format + 380…”. The bot may not accept the answer, which doesn’t fit the format. But not all data can be validated.
When a failure occurs either in the network or in the bot, it is important to provide the ability to “revive a hanged bot”. In order not to cause a “rabies” state in a user, a bot must be able to recognize an emotional impulse.
For example, if a bot provided a choice in the form of buttons and because of user’s problems with the network they weren’t displayed, the bot can’t go on until the user makes a choice. He will insist on the choice of the proposed buttons and will hang up.
How do we solve this issue using CUI? We put the bot “code words” or “stop words”, which provoke an urgent scenario. The bot understands that something went wrong and can offer the user solutions to the problem (e.g., go back a step, or start newly). These can be any words with which users in everyday life express their dissatisfaction, including “stop”, “back”, “don’t be stupid”, “hang up” and so on.
The ability to go back to a step or to a block, without losing previously entered data is very significant, especially when it comes to filling a great number of important data.
The same is with the situation when the scenario reaches an impasse due to an unreasoned case beforehand. If it can’t cope with the situation, doesn’t know or can’t display the data or even react to the request, a “backup plan” should be provided. In such a situation, the chatbot will offer to leave its callback number, or switch to the operator, or write a request for mail, and so on. But the most important thing here is to save the information entered by the user. Then the manager processing the request will already have partial data about the client, and there will be no need for the user to repeat.
For the bot, all the standard buttons and capabilities are different from those of the web. The same is with filling forms.
In the browser, if an error occurs or if incorrect values are entered, the next step doesn’t happen, and errors are highlighted. The user has many points of contact with the interface, and it’s possible to enter the information in any order, change and check it until you submit the form.
In the chatbot, the user can correct the accomplished mistake by calling for a step back. But the user doesn’t know in advance how to do it, that’s why the bot must have a wide range of indicator words to simplify the interaction to the limit. Or another variant is to warn the user preliminarily how to go back or to restart.
For the convenience of user interaction with the bot, you need to help the user “not to get lost”. It is most easily implemented in “application” type bots. In such bots, the user mainly interacts with the help of buttons which are very similar in design to the application buttons. When the buttons logic is properly constructed, it will be very difficult for the user to get lost.
Here is an example of two push-button bots, and how you can make a convenient bot with the same tools or bring users to a “nervous breakdown”.
On the left, you see the FC Barcelona bot which is a convenient and understandable one. And on the right, there is the bot of the Kiev water-pumping enterprise, which has “points of no return”. You can’t return or go back to the menu. You need to delete the dialog and start all over again.
Many bots accept and process personal information of users, but they don’t contain user authorization and data security.
And that’s what we have found – one well-known bot (let’s not mention it) takes data using only the contract number. It is enough to enter the contract number, and the bot perceives you as the true user, without requiring additional data or confirmations. Moreover, it stores in itself a certain base, which becomes available. As a result, by entering the contract number at random, you get information about the other person and his data. And besides, you can make changes and “mess things up” for him if you wish.
Such a problem is solved by any of the authorization methods like password, keyword, confirmation code from SMS, or at least request additional data (e.g., surname or phone number).
The specificity of a session with a chatbot lies in its limited time. It means that bots don’t wait for an answer forever, and it wouldn’t make any sense. The logic of the bot sets the time for a response. After the time is up, the bot session algorithm ends, and the bot returns to the starting point. Here it is important to remind the user that the bot is waiting for his message. Then the user won’t have any claims that on his return the bot doesn’t remember what their conversation stopped at.
Not always sociable interface is enough for user needs. For example, it is better to use GUI for data entry of a bank card. The CUI boundaries are there where the opportunity to resolve the issue conveniently through ordinary communication ends. The best option is to combine different interfaces in one bot, using the most convenient elements from each.
Sociable interface CUI plays a key role in creating chatbot. But using it reckless doesn’t make it possible to create a high-quality bot automatically. You should always think about the maximum number of development scenarios for each event, take into account the nuances and needs of users, test and double-check the logic of the decision branches to avoid impasses.
We have considered several cases of solving problems which arise when creating chatbots. We have solved them by applying the CUI principles formulated by Paul Grice.
In order to communicate normally with the bot, there is no universal template. The chatbot should use different algorithms, making communication as close to human as possible.
Despite the fact that while natural speech recognition systems are still not so developed and rarely used in practice, we have already been applying some principles to make your bots better.
