An assistant does not have to be a chatbot

Last winter, after realizing that one of the super powers we had to offer was a productivity assistant, we worked hard to find the best solution to include this feature in our product To-Do Studio. As a recap, the purpose of the assistant is not only to provide a daily schedule, but also to coach and direct teammates’ commitments throughout the process.

It was a long and winding journey and, today, I am happy to share the solution we have chosen.

As soon as we ruminate about a feature that resembles an assistant, we immediately think chatbot. A chatbot is a software program that converses with humans in a natural language, such as English or French, rather than through a graphic interface or via computer-language commands. Mainly because they are cool, seemingly very smart, potentially a little dangerous, and everyone wants to get to know them, recently, chatbots were widely talked up as the future of human interaction with technology. However, it is important to remember that the goal of most chatbots is not to match the capabilities of a human — to pass the Turing test — but to help people achieve specific goals without needing another human to be involved.

Conditioned by the bubble hype around chatbots, we initially tried to create a user experience driven by human-to-machine conversation.

Since we do not need a very sophisticated solution, we quickly identified that a simple notification assistant could meet the needs. A notification is an act of bringing something to the notice of someone, so he can act upon it. In addition to having to notify, we also identified the requirement for a rule-based bot with a limited set of commands that represent the potential responses to the notification.

Through all our experiments we discovered two improvements to simplify user experience (UX):

1. No need for a chatbot: Interactions with a notification assistant do not behave like a conversation. The conversation is limited to a notification (the starting context) and a response (a choice limited to a set of predefined commands). In this perspective why use a significative part of the screen space with a chatbot.
2. Need to display answer choices: As most bot developers could tell you, giving end users a box to type in rarely ends up being just a simple question and answer. We must provide shortcuts in the form of commands and commands must also be displayed in the conversation area if you want them to be easily visible and accessible.

In the end, after several iterations, we abandoned the user experience based on a chatbot. Similarly, we abandoned the idea of displaying the answer choices in the conversation area.

We opted for something simpler and proven, a menu-based conversation. The advantage of the menu-driven approach is that we can highlight the presence of the assistant with an extremely visible button, floating throughout the screen (Floating Action Button), and we can guide the user with a notification area.

The user has no difficulty discovering the commands because they are displayed as a menu that also floats above the screen.

Now that the bot hype is dying down, we recognize that a bot is just another frontend for accessing software services. An assistant is not necessarily a chatbot especially if it aims to help users perform specific tasks within a software service. A menu-based conversation is as valuable a choice as a chatbot.