Facebook

Messenger Bot Navigation

Exploring alternative bot navigations for better feature discovery and navigation

During my 12 week internship at Facebook, I worked on the Mobile Financial Services team that aimed to make financial services ubiquitous to everyone.

Role product designer
Team mentor and PM
Tools Sketch
Timeline 2 weeks

Background

Accord to World Bank data, In the Philippines, only 28% of the population have an account with a financial institution. Through user research, it was found that paying a bill regularly takes people 40 mintues.

Facebook partners with local payment service providers, such as PayMaya in the Phillippines, to build bots that make financial services ubiquitous, giving people back their time for more value generating activities.

Problem

Conversational user interfaces leverage people’s familiarity with texting messaging to create intuitive interfaces that require no additional learning to use. However, the single threaded nature of conversational UI makes discovery of features difficult. The true value of the MFS bot lies in that it’s a comprehensive set of financial tools that makes the lives of its users easier, not just the first feature that is exposed in the conversation thread.

How can we make our whole suite of financial tools discoverable and understandable?

Approach

The current bot guides new users through the bill payment process. To access other features, a user needs to tap on the hamburger menu at the bottom of the screen.

Existing Menu

The current menu is limited in a few ways:

1. The features listed in the menu seem independent and disconnected, and there’s no logical to how they are ordered

2. It's hard to distinguish between features at a glance due to lack of visuals

3. There’s little user education on what each feature does

4. The menu is not scalable to more than 5 items

We can create a custom menu to alleviate these problems and establish a clear mental model for users to access and discover features.

Solution Exploration

Before putting down any pixels, I thought of all the different approaches we can take. Architecture wise, we can have a multi-level or single-level menu, it can be static or dynamic. Depending on the architecture, the mechanic of the menu can be a horizontal scroll, a drop down, a spring board, or action sheet. During the early stage of the project, used these sketches to test out the viability of these ideas, and to get quick feedback from the team.

Based on feedback, I made higher fidelity mockups of the most promising ideas.

Option A: Ranked horizontal scroll

The first option is to display the features as a horizontal scroll of individual options. For a new user, the list would be ranked by the feature’s global popularity, where the most commonly used option by all users would be displayed first. For a returning user, the list would be ranked through a combination of frequency and recency of use.

  • Pros
  • Interaction is simple and well understood
  • Low eng cost
  • Cons
  • No clear, understandable mental model for how options are ranked
  • Difficult to search
  • Low usage of optins past the fold
  • Not scalable to large feature set

Option B: Shortcuts and hidden menu

The second way to display the features is to show the three highest ranked features in the horizontal list upfront, and display the rest in a springboard when the user taps on the All menu item.

  • Pros
  • Scalable to large feature set
  • Categorization aids serach
  • Frequently used options are easily accessible
  • Cons
  • Over reliant on user tapping on the "All" button
  • Springboard of all menu options can be overwhelming for new users

Option C: Top Level Categorization

The third solution is to display the top level categories upfront, and display the list of features when a category is tapped on.

  • Pros
  • Simple interaction
  • Static menu is more predictable and understandable
  • List format is for accommodating of longer strings
  • Top level categories give the user a summary of the bot's features
  • Sublists contain fewer items and are less overwhelming than a springboard interface containing all features
  • Cons
  • Every feature requires two taps to access

This option was chosen as the basis for the final design as it is simple to use and addresses the issue of feature discoverability the best. Users can quickly tap through the top level categories and browse through the feature set in a systematic fashion. The solution underwent one further round of iteration, and the final results are shown below.

Final Design

Helpful & Friendly

The menu is expanded by default when you launch the app, directing your attention to the starting point. Each feature is accompanied by a description, making it friendly even for those who have never used online financial services before.

Partner Friendly

Menu options can receive special treatments based on partner needs. For example, a discount promotion will have a visually salient badge, and premium features can have inline CTAs for account upgrades.