Problem/Challenge: The insurance application process is entirely designed for a chatbot, as the process of filling out a traditional auto application could be a simple series of standard questions and answers. As this association's mission is to promote and deliver leading-edge technology solutions within the broker channel, it would make sense for the association to build a Facebook Messenger chatbot of its own to demonstrate to broker members the value of this emerging technology.
Goals: Questions and answers relating to the network were all listed on one long, static FAQ page that could take time to scroll through and find a specific answer. With a chatbot, one UX goal was to speed up this answer search-and-delivery process, i.e., instead of having to scroll through a long FAQ to find an answer, users could use the chatbot to instantaneously provide a relevant answer after typing in a certain keyword/phrase. To gather initial ideas on the design strategy and usability criteria, I used these templates:
Research & Process: I started with a competitive analysis of some major chatbot builder platforms: Chatfuel, Flow XO, Motion AI, ChatterOn and Gupshup. I also conducted research on chatbot design best practices and read up on the FB Messenger chatbot platform documentation. I ultimately chose Chatfuel because it's built specifically for FB Messenger, is free until 100,000 conversations/month, has a user-friendly interface, and 360,000+ chatbots were already built using Chatfuel.
I created a Project Charter to get the team on the same page and clearly define the scope of this chatbot – research told me the more narrowly defined your chatbot is, the more effective it will be; we therefore decided to focus the chatbot on one aspect of the company: the platform connecting over 36,000 brokers with their carrier partners daily. This platform is the “bread and butter” of the association, representing the majority of tickets submitted and customer service done at the company.
First step in the user-centered design thinking process was writing down characteristics for the user profiles – users who would find this chatbot most useful. This information came from knowledge I already had from being with the company since 2012, as well as from discussions with internal stakeholders, e.g., receptionist who interacts with customers on the front-line. I got her feedback on the most common network-related calls that come in. I also looked at tickets submitted in Zendesk to get an idea of the most common questions that arise, and consider how some of these questions could be addressed by a chatbot.
It was then important to think about the high-level tasks and content that had to support users of the network's chatbot. These tasks would help determine the conversational abilities of the bot:
Once the main tasks were determined, they had to be sorted and prioritized somehow. I did this using a task prioritization diagram:
Important design insights can come out of thinking critically about your user's environment. Environmental factors can impact how tasks are completed or content consumed. I therefore wrote down an environmental profile for each main market segment identified:
I now had enough information to form a realistic snapshot of the primary user of the network chatbot. I wrote this information down in an initial persona template:
Initial persona sketches are likely to have gaps, so direct user research in the form of interviews is often necessary. These questions should capture information to fill in those gaps and provide additional insight into the users' mental model:
Once you have fleshed-out personas, it's important to think about when and why a task would be performed by writing down scenarios, so those not familiar with the task and persona will understand the situation. These scenarios can also assist with developing a journey map, which is an effective deliverable for building empathy among the team for your key user groups.
Scenarios can be used to create a task flow diagram, which should meet the user's mental model. At this stage, I'm thinking about what it takes users to do something, researching it with them and adjusting or modifying the flow. This diagram was the starting point for the conversation flow chart. Before you start working with one of the bot platforms, spend some time thinking about how you expect the conversation to flow. You can leverage one of the many flow chart tools out there (I used Lucidchart) to think through when to branch, when to have open input vs. forcing the user to select options, when to show results and what those results should include, what the calls to action should be, and how you want an interaction to ideally resolve itself.
After mapping out your chatbot's core conversation paths ahead of time in a conversation flow chart, it's a best practice to then write your chatbot's wordings (questions & responses) in a separate script document before building your bot. Writing a full chatbot conversation script before building your bot will save development time. It provides a "bird's-eye view" of the bot's conversation flow, enabling good decision-making before building the bot and hopefully preventing the scenario of heavily revising your bot's language post-launch.
After writing the bot conversation script, I began the process of building the chatbot using Chatfuel. I created blocks for each main question/answer topic and used Chatfuel's built-in AI engine to link anticipated user input language to the bot's responses.