How to evaluate a conversation design solution before you build
Conversation design solutions (chatbots and voice user interfaces) are becoming more commonplace. I discussed this trend with Sid, one of our Technical Solution Architects in a past blog post, so now I’m going to go over how we evaluate if a conversation project solution should be pursued.
Generally speaking, people have become accustomed to graphic interfaces, and understand how websites work. Voice applications shake that up a bit – we don’t yet have common mental models for interacting hands-free and eyes-free. We need to ensure that a conversation interface will indeed be easier to use for our audience, taking into consideration their context of use and accessibility needs.
The 4 steps to a pre-build evaluation of a conversation solution
1. Discovery Phase
We recommend holding a discovery phase for any new build project, whether that’s for a website build or a conversation project. A discovery phase allows the team to understand who your users are, talk with your stakeholders, and explore the competitive landscape. We want to make sure we’re on the right track with solving the right problem in the right way.
A user-focused discovery phase is especially important when we’re dealing with newer technology like voice interactions. Sometimes a conversation interface emerges as a solution because of the discovery research. Other times, clients come to us wanting to build a conversational interface, and we start with the Google checklist (next section) before proceeding with our discovery phase. We might find that a voice feature meets most of the checks on the Google list, but it’s still not right for a client’s users. If we don’t get this insight up front, we could end up designing and building something a set of users don’t actually want to use.
2. The Google Checklist
Google is one of the leaders in establishing conversation design best practices, so we rely on some of their advice as we work on projects in this new space. They’ve created an 8-point checklist that allows the team to evaluate whether a conversational approach is an appropriate solution for a design problem. It’s easy to walk through with our product owner and our clients – one short meeting is all it takes before deciding if it’s worth exploring with both users and the development team.
3. Feasibility Check
Whenever we design a solution, we always want to work with our development team to make sure that what we’re envisioning is technically feasible. No one wants to disappoint a client by sketching out a sparkly unicorn, only to have your development team bring forward a reality check that the time and budget will only cover a cute mini horse.
For a conversation design project, the development team need to review the data requirements if we’re going to be integrating with any systems – What data do we need to pull? How is it structured? Do we need to do any user account linking? Are there permission levels? All of these inquiries will affect how long it will take to build a product.
In addition to these requirements, we need to make sure that the interactions we’ve planned will indeed work on the hardware we’re working with. This is especially applicable for smart speakers, which have restrictions built into them – for example, Google speakers don’t allow actions to push notifications to users, but you can push notifications to the mobile application.
4. Discuss KPIs
Depending on the solution, we work with our clients to determine KPIs for a project at the beginning of the process. For example, if we’re building a customer service chatbot to handle a type of inquiry, we can measure both the usage of the chatbot for these questions, as well as monitor the calls coming into a client call centre. If agents are freed up to answer other queries from customers that are too complex for a chatbot, then we can rate the success of the chatbot and make adjustments going forward.