Conversation Design and breaking from shackles of App mindset

By Siva Sai N, SVP AI Product

Conversational Interfaces are relatively new. Facebook was one of the earliest to popularise it and this was a little over 2 years ago. The last 4 decades have seen human computer interfaces stabilise around point-and-click GUIs evolving all the way from Apple Macintosh introduced in 1982 to the iPhone (that introduced multitouch and swipes to the masses) launch in 2007. Massive leaps has been made in those 4 decades in defining usability standards and guidelines for all platforms like desktop, web and mobile applications. Conversational interfaces require a whole new mindset to realise its potential to the fullest.

As you read the rest of this article, you will find that a lot of examples are provided in banking context, which is where most of our experience and audience lies. But I see no reason why most of these principles cannot be applied to pizza ordering, for example.

Application interfaces had one requirement that drives its design and all usability guidelines around it. If you make an application module, for example, to do a bill payment, the best way to manage this is to automatically present the options on screen. Even those requirement settings that rarely changed, like for example, the source account for making payment, or the payment date set as default to a certain day and time, or even optional elements, like comment.

What defines the application design is the fact that, unless the options were presented on screen, it cannot be used. Users have also developed a sense of selective blindness overtime as they got more familiar with the interfaces. So they come online, just select the biller, enter the amount, just glance if the other default fields are correct and complete the transaction.

Moving to conversations. The first instinct of an experience designer is to look at current design of mobile/internet banking apps and design the conversation based on that. That is one of the most terrible way to start. Once you have seen the mobile/internet banking screens, it is very difficult to un-see it. We have some cases where a complete form in an internet banking experience is replicated into the conversation.

This is what we say to all our customers. When designing a conversation for any given use case, close your eyes, imagine your smart and intelligent secretary/spouse just walked into the room and you asked him/her to remit the rent. He/she already knows who your landlord is and how much the rent is. The response you would expect is “Sure, I will do that right away. Can I get you a coffee or anything else?”

Now imagine he/she asks “To whom do you want to pay? How much? From which account? When?” You will probably look for another secretary. If he/she is your spouse, too bad. :)

The point is, your bank, unlike most organisations on this planet (save for Google and Facebook), knows you the most. Replicating that secretary scenario on a conversational channel is not even AI, it just requires simple historical look up against users’ past transactions. Yet, so few are thinking along such lines.

The guideline for a successful conversation is this. If the user cannot do it faster on a conversational channel compare to a mobile application, they wont don’t do it again. I transfer funds regularly to my wife for our expenses and measured the time it take to complete the activity on the conversation platform. It is definitely faster.

1. Go to bank.com
2. Open the bot
3. Type “Transfer 50000 to wife”
4. Authenticate
5. Confirm
6. Enter One-Time password (OTP) received via SMS
7. Done.

This is nearly perfect for a conversational channel. One small change I would make is to avoid the confirmation step if this is a regular pattern of the customer and jump directly to “Ok. I am transferring 5000 to your wife. Please enter the OTP to proceed.” If this is on another registered channel like Facebook Messenger, the authentication step can be skipped as well.

The idea is to design conversation for pure audio channel from the start. That keeps you grounded. Facebook did a great job in defining standard templates. The purpose of those templates such as cards, lists and carousels is to provide information and avoid typing as much as possible. Opening a design tool like Sketch/Balsamiq to design the conversation flow for a usecase is a sure shot way to derail the thought process and may end up too app-like.

Conversation designer should be more like a playwright than a UX designer. Once the playwriting process is complete, you can then add lists and cards at appropriate places within the flow if the channels allow it.

Another key aspect of designing good conversational applications is the 80–20 rule and ability for users to change the assumptions. I will illustrate via an example below from a recent experience.

Recently when we designed a flow for opening a term deposit with a bank, one thing lead to another and the proposed flow ended up with 15 steps that was replicated based on its other channels.

It goes like this:

1. How much you want to deposit

2. One time / Recurring

3. What Tenure

4. What happens on maturity… and so on.

One of our co-founders threw a challenge. Why can’t we do it in one step?

And this is how we did it:

1. What is the information that we really need from the user? It is just the amount that he wants to deposit.
2. Now the bank knows that 80% of the users who do recurring deposit, the amount is less than INR20,000. Therefore, it is quite fair to assume recurring or single deposit based on that amount.
3. Now, the bank also knows that for a recurring deposit, what the most common tenure chosen by 80% of the users will be or if it is one time, the bank can assume the tenure is to get the best interest rate possible.
4. The bank also knows what the behaviour will be for the majority upon maturity.

So, essentially, the flow goes like this.

User: Open a deposit for 50k

Bank: Sure. The best I can offer you is 7.6% for a 11 month term. Proceeds will be credited back into your account after 11 months. Interest of INR 767 be credited quarterly into your account . Shall I proceed?

User: Yes, Please.

In Summary:

Design the conversation so that it is extremely fast for 80% of the users. Its not fair dragging the conversation just to cater for the other 20% outliers.

Now comes the beauty of conversational channel. Although the flow was designed with the 80% in mind, it does not mean we are ignoring the remaining 20%.

As an example, those 20% of users can simply ask “Can you make the tenure 5 months please?” and customise any assumption that the system made for them. And over time, if a user always tends to change his tenure to 5 months, the conversation system should start assuming 5 months tenure for that particular user. Or if the user has no fixed pattern of deciding tenure, it makes sense for the bot to ask for the tenure every time.

This is true personalisation. That is what your secretary/spouse would do. This allows the conversation system to be extremely fast for the 80% on day 1 going live. And it evolves automatically for the remaining 20% to be fast for them too, based on their patterns.

Before signing off, I would like to highlight that not every usecase fits well into a conversational interface. Apps and websites will not fade away. Try not to fit every usecase into a conversational journey. Any usecase that is too long (like opening an account and begin a brand new relationship with a bank, or apply for a home mortgage) are not naturally suited for conversations. Although conversations is the in thing now, users are better off filling a form on a website or mobile app where he can go back and forth, changing inputs etc.

Conversational interfaces provide a very powerful way to interact with your users. Design the system that can leverage the knowledge you have about your customer base and create journeys that wow them.