2

 

Imagine... 

It is peak work hours, and you’re in need of a cup of fresh roasted coffee from the artisanal coffee shop around the block to continue grinding, but you are wasting precious time waiting in long lines. What if you can preorder anything you want in a fast and enjoyable way and then pick it up or get it delivered to you? In order to make this happen, we aim to create a chatbot-building framework for local, artisanal shops or restaurants to handle questions about hours of operation, reservation options and so on. We also want it to handle contextual responses and more complex inquiries such as ordering and pizza delivery.

Designing a AI Chatbot Framework is destined to fail, according to this article on Technology Review: “there have been no fundamental breakthroughs in training computers to process and respond to language (a field known as natural language processing) in recent years.”

However, this did not stop me from jumping into the project when I was assigned the task to design the framework for building a conversational chatbot. In fact, I was beyond excited to tackle the challenges and to create a human-centered, loveable bot-building experience for non-technical users.

 

 

Challenges

  • Chatbots are incredibly complex. Configuring chatbots require people to know technical jargons such as intents and entities
  • Most chatbots lack conversational context 

   

 

Creating chatbots is time consuming, cloud services and datasets are very costly, and barrier to entry is high. How might we enable local boutiques and artisanal shops to access this technology without writing a single line of code? 

  


Goals

  • Automation of the chatbot building process by letting small shop owners use an existing template chatbot and customize on top of it
  • Simplification of the chatbot-building user journey by letting users focus on completing only one goal at a time

 

 

Research

I had many discussions in the break room with the project lead about designing for AI and chatbot. Out of curiosity, my colleague and I were tinkering with some popular NLP as a service platforms. We also tried creating chatbots on these platforms - creating an Alexa skill was pretty fun. This gave us a few months headstart on conducting extensive competitive research on existing chatbot platforms prior to getting started on this project:

  •  LUIS.ai — By Microsoft 
  • Wit.ai — By Facebook
  • Api.ai — By Google
  • Watson — By IBM

Having to meet the 2 week deadline, we could not follow through with our research guidelines and methodologies. Having had more time, we would have sat down with our users to learn and understand their needs and pain points.

We wanted to learn about our users, see the world from their perspective, and hopefully investigate how this product would make their lives a little easier. Unfortunately the internal release of the product took priority. 

  
features comparison

 

Ideating

We had a two day what-i-call “concept and the ambitions” workshop with our PM and engineers. This was an endeavor to visualize and map out the core features and the main capabilities of those feature. 

How do we enable people who have no technical background or deep learning expertise to build conversational chatbots quickly and easily? The strategy we utilized was to do extensive competitive research on exiting cloud platforms where users can create alexa skills, finding out the most challenging and confusing part of that user journey, and then simplifying the process without taking out the core features required to create a chatbot. The most difficult part of building a chatbot turned out to be establishing the context in the dialogue from one intent to another, so we created the feature called “logic flow,” where users can map out the basic conversation logic directly from the flowchart, and then further specify the content of the conversation including the intents and entities in the next tab called details. We decided that tab controls are a good pattern to use here because our users can switch back and forth between thinking fast and slow, and between mapping out the logic and working out the details.

  
Image from iOS (7)

 

Design

We presented our initial solutions using the Dot Voting Methodology during the UX Design review meeting. We had been working on the flowchart part of the platform, and we wanted to get feedback as soon as possible to ensure the design was aligned with the technical aspirations. We iterated continuously throughout this project.

After a few rounds of working together to gain a better understanding of the intended solution and eliminating the differences from similar ideas, we each iterated our designs and eventually combined them in to a collective design. 

  
1

 

Launch and Learnings

The first iteration that we designed is more of an MVP than an MLP. An MVP is a cost efficient way of gathering user feedback fast, but a lot of assumptions were not tested. Given more time and budget, we would have conducted more user research and usability tests to create a MLP (minimum lovable product). The MLP emphasizes the emotional journey of customers from one touchpoint to another. We would be able to find and test our product market fit, learn about what makes our users happy or frustrated, and create a product that is both useful and lovable.

In order to satisfy the business goals, we need to strategically select and obtain dataset to train our NLP models on. I suggested limiting the scope of our product to focus only on small, local artisanal shops as it is better to have an extensive and thorough knowledge base in one field than to have general datasets on many fields. We’re still in the process of refining the business model before public release.