Banking with bots
Our designers are curious people, so when new tech comes along with promises of new, better UX solutions, there’s at least a handful of us who are willing to swallow the red pill see how deep the rabbit hole goes. Typically this means investigating the technology optimistically and with an open-mind, with the goal of establishing an informed opinion (recently our summer interns did this with Peer). The goal of these explorations is to encourage healthy criticism of new technology, and question the legitimacy of the design patterns that compliment it. The goal is to scrutinize the new technology as much as we praise it, and to be selective about which elements we choose to endorse.
Lately our attention has turned toward conversational interfaces. The promise of this tech is that it helps us tackle user experience problems better than a traditional graphical user interface (GUI). These claims are possible because of the surge in progress in natural language processing technology (Amazon Alexa, Google Home, Siri, etc.) and the ubiquitous adoption of chat platforms like Slack and Facebook Messenger. Bots on these platforms aspire to reduce the friction of using complex products by replacing complex navigational structures with natural conversation. We want to investigate how conversational interfaces are being used today and find out what qualities of this technology are most appropriate and exciting for digital product design.
Grand Studio designers have had years working in the financial services space, so we know the design challenges here offer the complexity to realistically exercise a bot’s capabilities. We also know that personal banking products are an excellent candidate for a true conversational interface, so we set out to explore the current landscape of conversational interfaces and challenged ourselves to create our own bot to test the theory ourselves.
Today, if a product is built in a conversational framework like Facebook Messenger or Slack, we call it a conversational interface regardless of where it falls on the spectrum between parameter collector and intent interpreter. But classifying any interaction that takes place in a chat window as a conversational interface doesn’t help us distinguish between bots that solve user experience problems in a new way and bots that solve user experience problems in a better way.
As of today, most bots fall somewhere on this spectrum:
On the left, parameter collectors converse with users by sending simple questions one at a time, processing the users’s verbatim responses as an input to a query (often a search) before messaging back the results. This type of bot is like a repurposed web form or search field in bot form. You’ll find examples of these in shopping and travel bots like 1–800-flowers, Kayak, and Hipmunk.
1–800-Flower’s bot is a re-imagined form field adapted for Facebook Messenger. It can request information from the person it’s messaging, but ultimately it’s just filling empty fields with whatever data the user sends. It doesn’t really know what that information means.
Bots on the right side of the spectrum are flexible and capable of understanding a wider variety of user messages/requests. I call these “intent interpreters.” They have contextual awareness and ambiguity resolution capabilities that give them advantages over a traditional graphical interface. When people get excited about bots, this is usually the kind they’re thinking about. Hi Poncho is a lot better than 1–800-Flowers at interpreting meaning and context in a conversation:
The user doesn’t need to think about formatting restrictions or order of operation when talking to Hi Poncho. Poncho is an intent interpreter so he’ll do the work of matching human language with his robot capabilities.
To learn more about using bots to solve UX problems in better ways, we took an existing complex product and evaluated its features in bot form. The question we want to answer is: “Which features are made more user-friendly by a conversational interface?”.
We set out to build a real bot that would mimic the product offerings of a traditional banking product, but on Facebook Messenger. We chose Facebook Messenger because of Facebook’s massive daily active user base of 1.18 billion and the recent introduction of payments within the messenger platform. Upon completing the bot (which you can demo here) and iterating on its features, we were able to sort the bot’s capabilities into four categories that measure their effectiveness compared to app/web counterparts. The four categories are:
- Table stakes: Obligatory features users need that aren’t enhanced by a conversational format.
- Conveniences: Features that are made more convenient through a conversational format.
- Breakthroughs: Features that are a perfect fit for conversational interfaces, with obvious advantages over GUI alternatives.
- Flops: Features that are consistently less successful conversationally vs. graphically.
Features in this category include activities that are required of all banking platforms like checking your account balance, viewing recent transactions, and transferring money.
Using a conversational interface affords us a few small advantages here. Our bot can return a user’s balance or recent activity from a variety of commands and with awareness of whether or not an account is specified. The flexibility afforded by the bot’s ability to parse natural language makes it more flexible and user-friendly compared to a parameter collector type bot, but I’m not convinced that typing “what’s my balance?” or even “balance” is an easier, faster, or better user experience than simply launching a bank app. These features aren’t enhanced much by a bot which is capable of conversation, they’re just table stakes of any banking product.
Conveniences are features which show potential for outperforming their traditional web, app, or even customer service counterparts in certain situations. Features like reporting a lost card and finding ATM/branch locations fit into this category.
What makes these capabilities unique is that they’re typically handled by customer support over phone or text chat, but aren’t so complex that they can’t be handled by a well designed conversational bot that can parse human language. It’s easy to see a situation where a user would prefer to send the message “I lost my card” or “I need a new card” over digging through tiers of product navigation to find this edge-case feature.
Features that perform better than GUIs are considered breakthroughs, and they highlight the true advantage of conversational interfaces. Tasks like changing travel settings and investigating nuanced spending history can be easily verbalized by users but are made more complicated by a graphical user interface. This makes them a perfect fit for our bot.
Whenever I travel abroad I spend five or so minutes on the phone waiting to be connected to a customer service rep so I can say “I’m going to be in ____ for ____ days.” The pain in this exchange doesn’t come from the complexity of the feature but in waiting to talk to a human so that they can confirm that they understanding my intent correctly. But today’s bots can understand intent, so we can replace a customer service call that’s costly to the bank and time consuming for users with a bot conversation that achieves the same thing with low friction in a fraction of the time. (The above conversation isn’t a scripted response, the bot is made to converse with a user about travel settings until it knows where they’re going and for how long, the above example is just the shortest and most natural means to that end. Test it out for yourself with other destinations and durations.)
This is as good as our bot gets. A feature like budget tracking is perfect for conversational interfaces because a question like “how much did I spend last month on food?” doesn’t take any knowledge of the product or technology to construct. Users can form the question according to their understanding of their money, which places the burden of translating user need into product vocabulary entirely on the product (where it should be). This is the kind of enhancement we were looking for when we started this project, and it’s a perfect example of a conversational interface that’s better than its graphical equivalent.
Flops are features that are made worse by adapting them to a conversational format. The best example in our bank bot is the “dispute a transaction” flow.
The process of disputing a charge is complicated, and it’s something that users don’t think about regularly enough to be able to summarize their problem verbally with all of the required variables. Additionally, it’s beneficial for users to see more information at once in this process as it involves identifying patterns and outliers in spending history and grasping the complex requirements/processes involved in submitting a claim. The flow in the messenger conversation is awkward and I would argue that this is something that is better handled on a traditional app or website. While it’s possible to complete the flow (as you can see above), the conversational form doesn’t compliment the feature. When disputing a charge, users should be able to see a birds-eye overview of their account activity that enables them to identify anomalies in their spending. Additionally, because the web equivalent of this flow is often peppered with conditional tangents and case-specific legal details, so it’s critically important that users are able to see a lot of information at once as opposed receiving it piecemeal in conversation form.
Studying our bot feature by feature shows us glimpses of some pretty special user experience solutions afforded by our interface. The bot excels at addressing user needs that are simple to express in language, but hard to simplify graphically. Personal finance management questions like “how much did I spend on food this week” stand out to me as the most promising type of interaction that conversational interfaces can enhance. Instead of asking users to translate their needs into form-fields, filters and sliders, bots enable users to ask a question as it already exists in their head. The bot does a lot of work behind the scenes to make sense of each request, but to the user the conversation looks very straightforward, human even.
For those of you who are curious about what goes on behind the scenes of something like this, here is the basic route that a message takes after it’s received, interpreted, processed, formatted, and sent back to the user as a response.
The keystone that makes this possible is the natural language processing done by API.ai (orange). Products like API.ai are now really good at allowing designers and developers to train bots to understand user intent correctly and they have the power to turn parameter collectors into intent interpreters. This technology in the mainstream is still new and imperfect, so I was surprised that API.ai’s capabilities weren’t the limiting factor in this project (they’re actually shockingly straightforward and fun to use). Instead, the biggest challenge was designing effective responses under the constraints of Facebook Messenger. Those limitations include limited message template options and lack of customizability (especially compared to Slack), unpredictable inconsistencies between message formatting between Messenger.com and the mobile app, and the reliability and consistency of the messenger interface in general.
Another frightening realization: Because this product is a conversation, there’s a persistent archive of all interactions that users have with a service. That means users can scroll up through months worth of messages and not only read them but click the buttons that were sent along with those messages. What happens when a feature that is thought by a product team to be deprecated is still visible and clickable by users? This is something that designers and developers could and should account for, but some mistakes are bound to slip through as this archive of interact-able elements isn’t something that exists anywhere else.
I don’t want these concerns to sound like a rant against the Facebook Messenger Platform, but I think it’s important to remind aspirational bot designers that Facebook Messenger is an immature platform with a lot of room for improvement. Improvements are probably right around the corner for a lot of these issues, but until then, they’re something designers and developers should take into account both when choosing a bot platform and designing conversations.
Our hunch that personal banking products are good candidates for conversational interfaces turned out to be right. Banking products are necessarily complex in their feature set, but a lot of the challenges we face when designing for them are IA and navigation solutions that help users navigate around features in search of the small handful that are needed in the moment. In short, simple tasks are made complicated by the presence of potential tasks, access to features are obscured by other features, and users are left to navigate through a sea of capabilities when they often know what they’re looking for.
Conversational interfaces should handle the translation from human thought to product features, eliminate the hunt for those features, and open up the product to be more flexible to the way the user understands the features. This is the strength of natural language interfaces that are concerned with understanding user intent, and it’s why we should take the medium seriously. It’s the point where we stop thinking about how a product’s features are categorized or organized, and instead, empower users to express for themselves how they understand the product and their own needs. It also illustrates the need to be concerned about holistic user experiences and relationships across all of a company’s services.
This post was originally published on Moment’s website.
Originally published by Grand Studio contributor/freelance designer, Steven Bennett, at medium.com on December 8, 2016.
