A new way to begin conversations with Bots.
Facebook recently launched their bot platform where people can chat with bots. The platform offers people to read and discover news, get weather updates and even play chess inside their messenger application. A single Facebook conversation with a bot will let you accomplish a single task which has no relation with any other bots in the ecosystem. When you enter a conversation with a news bot you ask it about todays headlines and not about the traffic conditions on your way to work. The problem arises when you have multiple bots inside the same chat. Instead of a single focused goal the user can begin a conversation in an exponential number of ways. But without the right context bot aggregators are less than helpful. So how do we make sure the user sets the right “context”.
We are a conversational commerce company which offers users multiple bots to the users inside a single application. So naturally modality of conversation is very important for us. Over the past few months, we have been working very hard in figuring out how users will start conversations with bots, especially considering the fact that none of our user is trained to do such conversation.
Before I begin there is one thing for those who haven’t previously interacted with the App should know. A single application has multiple bots living inside it. These bots can be initiated by typing out the right words or setting up the right context. Unless the app can set a “context” to the input, the conversation is rendered frivolous. Better to imagine it like a main folder which leads to sub folders with plethora of interactions(Open Sesame) but the wrong words lead to a folder containing nothing but disappointment and useless small talk.
So, here is our story documented over the past few months:
Who are our users: lessons from the Mechanical Turk
Before MagicX had automated bots, people interacted with an army of humans who responded to individual user queries (over our previous platform — MagicTiger). The previous platform provided us a chance to engage directly with users on a regular basis. Interacting with hundreds of users over the months we were able to distill new users into two broad categories.
The users who have probably heard of the the application in a general context. These users did not come in with the objective of doing a particular task but rather explore the possible tasks which could be performed.
These users came in with a clear objective of what to do. They know how the app works and simply prefer to type out what they want. They probably had a previous idea of the apps affordances helping them to navigate through a minimalistic interface.
The Previous Design
Keeping in mind both the type of users we adopted material designs popular interaction element called FAB(Floating action button). It sat on the right top corner on tapping which the users could see complete list of our bots. The solution fit the problem we were trying to solve, it allowed the Explorers a way to know our offerings while it gave freedom to the knowers to interact with the app in a free form text.
While fulfilling the needs of both types of users with time we realised this was a necessary step to begin with due to two reasons.
- Rise of chat based applications over the past few years has enabled conversations between two people very easy. The ease has given people a chance to personalise the language they share which has given rise to abbreviations(I still keep getting a new way to write the word friend every other day, gng 2 mvee wth frndz! :P). Also, as humans we are able to extract meaning out of half formed sentences, but it poses a harder challenge for the bots to comprehend the nature of the conversation. The Utopia of conversational interfaces would be to be able to make sense of the inputs and talk back to the users like their own best friend. Until we reach there we are stuck in the Biblical tale of the Tower of Babel where gods cursed men with different languages unable to comprehend each other.
Utopia of conversational interfaces would be to be able to make sense of the inputs and talk back to the users like their own best friend.
- In major chat based applications the user typically interacts with one part of the screen most of the time — The typing bar. It has a clear space for users to type in and a send button to complete the action. Well, the users can begin conversing with us at the same, but this conversation lacks a context, leading to small talk. (It is similar to when you get a match on tinder and go check out the girls profile, you see nothing but her name and age, you are flying solo. But if she has mentioned she is a ardent Game of Thrones fan you can begin the conversation by simply asking how she liked the previous episode, thus setting up the context). Having a floating button helped the users set up a context to the conversations thus making them more fruitful.
Over the course of few months we identified a few flaws with the design as well as in terms of our initial hypothesis.
- One of the problems was that the FAB was far away from the typing panel. The current paradigm of chat based apps have the typing bar at the bottom. As a chat application it is a vital part of user interaction. The typing bar still was the core of user interaction and we were moving away from it leading to a disconnect between the two ways to interact. People eventually formed an understanding that this feature is an OR case and not an AND case like we had intended it to be.
- When the FAB was in it’s active state it blocked the previous chats or more notably the last 3–4 messages from the previous chat. These were the messages pertaining users last interactions namely the payment and order status messages, making it hard for the users to be notified.
- And with the increasing amount of vertical real estate allotted with every new bot released,we simply ran out of space to show any more bots.
So, why not just show a Grid?
The most common feedback we get when we talk to users is, “Dude! all of this is good but, where’s the menu at?”
Traditionally commerce applications have a list/grid view with a broad category of their offerings. If a user is exploring options he/she has to sort through a multitude of options. But, does having a large menu help the user to take a decision easily. In his book, “The Paradox of choice — why more is less”, Barry Schwartz argues that eliminating consumer choices can greatly reduce anxiety for shoppers, i.e. giving people less to choose from means they will be able to decide easier and do more.
Parallel to this train of thought, we observed something similar with the way people were using our app.
Our most loyal users were engaging in upto 2–3 bots on a regular basis. We were showing users all of the possible options but the users were simply using the ones which fit their needs.
With these insights in hand we went to the drawing board and began racking our brains up for new ideas.
The Design Solution,
Still inspired by the core concepts behind the FAB which represented the most common action
- The status of the order weather successful or unsuccessful is the final feedback for the user is an e-commerce flow. With this Design the final messages from the previous conversation are readily available to the user in the upper half. While the lower half readily prompts the user towards newer conversations.
- As lower half is seen only when the app is not under any context it can be helpful in driving conversations in the right direction by setting up the right context(Open Sesame).
- By bringing the inputs along with the in the lower half we are trying to make the chat experience more natural and usable as the most accessible part of the mobile screen is the lower half(closest to the fingers). Making the overall experience like the traditional chat paradigm where new information flow from bottom to top.
- By reducing the number of options we wish to reduce the users cognitive load which will drive to quick actions into meaningful conversations, as well as reducing a click making it a single step process.
Metrics & Goals
Yes we did all this so what was the the motive behind all of this?
The new design paradigm was focused on the top level of the user funnel, the part where users discover if the product is solving what I need? It is meant to educate users on the various bots we have. The patterns we wish to observe with this is to reduce the number of ad-hoc requests which we cannot satisfy.
The new design with a limited number of options give us a huge opportunity for user personalisation based on user habits, time and location, a user repeatedly pays bills every month, the pay bills options can be on top at the beginning of the month. Lunchtime? The assisted text can prompt you to order lunch, etc. Booked a flight ticket for Friday evening? A push notification for a Uber to take you to the airport is ready.
The possibilities are endless!
We would like to hear your thoughts and appreciate any feedbak you have for us. You can check out the MagicX app here.