This post summaries the process of building a chatbot called Chiara. It is an AI-enabled chatbot that support families during the referral period to the children hospice. Chiara is the first tangible output of a near-future service that utilises AI to support families caring for a child with life-limiting conditions.
Here you will get insights about the process and decisions that can go into a building a chatbot, and some references about the methodology and technology used.
We have divided our process into 3 different steps:
- Envisioning the chatbot
- Designing the chatbot
- Building the chatbot
1. Envisioning the bot
Before starting to think about the architecture, flow and the technology approach, we collectively defined the scope of the chatbot and which user segment it would serve.
The user segment
Based on previous research, we identified the user segment for the chatbot as 'families who have never been to a Children hospice'.
Chiara builds on an extensive research phase that the End-of-Life Care team conducted last year. This phase of work helped us to shape the problem space and identify the needs of families caring for children with life-limiting & life-threatening diseases. Some of the key insights from user research:
We shaped our research as job stories. Job stories ensure that the team is research-driven, that they understand their problem so well that they can capture it in a concise format. And that their summary of the problem is actionable for all the design and engineering effort. An example:
When parents get in touch with professionals they want them to remember their history so they can receive the most appropriate suggestions.
The chatbot scope
Defining the chatbot scope is making clear what people can expect from our virtual assistant. The team collectively envisioned and prioritised 3 goals for Chiara. In order of priority:
- Providing recommendations for support
The chatbot will make suggestions for support groups and resources which are tailored on family needs and context.
- Giving suggestions for Children hospices
The bot will match families to the most appropriate hospice for them and hopefully shorten their journey to it.
- Connecting users with professionals at the Children Hospice
Chiara acts as a connector between families and professionals, services and other families.
Any of the above goals are highly personalised –in user needs and context– therefore, they all would require two additional subgoals:
- Getting to know the family
The chatbot gathers information about the user's and family's preferences, and introduces its role and capabilities.
- Understanding disease and context
The bots digs deeper into the health conditions and issues of the child in need.
2. Designing the bot
It's a concept commonly underrated on interfaces, but it's one of the fundamental basis of chatbots. The personality of the chatbot is one of the most essential points to take into account if we wanted our assistant to succeed.
We wanted to shape Chiara's personality in a way that fits with the user and their context. The bot should be transparent in its intention, sound confident and show an understanding of the user
We build up a database so the chatbot could source content from. The database is basically a manually inputted spreadsheet in which we collect different resources:
- recommendation resources appropriately tagged according to their content
- a comprehensive list of all the Children's hospices in the UK
- a living list of Children's diseases
The chatbot flow
This is the most complicated part result of a very active collaboration between Jorge, the developer and myself. Together we framed the chatbot possibilities by following a model called Prometheus. In which, we ask why (goals) before how (functionality descriptors).
Following the Prometheus model, we have framed the chatbot functionalities through a high level tree-like diagram 'User Goal Map'.
While designing the chat experience, we needed to decide which information will be offered first, which interactions are required by the user in order to obtain help from our assistant. The 'User Goal Map' shows 4 primary goals (in red), and a series of smaller goals (in green). All goals are prioritised in a scale (1 > 3, where 3 is high priority) in order to be built.
The Prometheus model has been beneficial for providing context and user goals and motivations to the developer. Moreover allowed to break down the software engineering process in smaller pieces that could be easily tackled by the designer.
3. Building the bot
To iterate quickly, the developer leveraged the existing state of the art AI products and Web Services. We used Dialogflow, which comes with multiple benefits, such as its ability to integrate into various platforms, and the ability to analyse past conversations to improve future use.
Chiara required a visual interface to allow user testers to chat seamlessly and our team to experiment more quickly with different approaches. We chose for a web-based service called Kommunicate, which easily integrates with Dialogflow and provides some standard User Interface components – links, buttons, cards.
Learnings from user testing
In line with our Human-centred design approach, testing the chatbot with families is fundamental, so we can understand how it works under expected scenarios and test how it works in real scenarios.
We defined the things that we wanted to discuss with families. In our case, we tested:
- Chatbot personality: How well does Chiara express itself with language?
- Chatbot Capabilities: How fitting are Chiara's suggestions to the user? To which extent are Chiara's resources appropriate to the user and their context?
User testing sessions
At Helix, we run internal testing to get initial feedback on the user experience and tech system. Additionally, we planned two cycles of user testing with families, both apart of two weeks. This would have allowed us to improve the first version of the chatbot and test again. Unfortunately, when testing in end-of-life care not everything goes as planned.
To accommodate families' needs and reach out to more significant numbers, we tend to run remote sessions. Each interview is carefully recorded and documented.
Then we produce a User Testing Report, in which we gather –alongside with our goals, list of participants, methodology, and results:
- Product Feedback
This section is talking about the response of the participants about the prototype that we are building. The feedback is going to inform the whole team and lead the direction of the prototype. We often include visual materials (screenshots, video snippets and photos) from the testing and pulled quotes of the participants.
- Key Observations
We gather inputs and observation on and around the prototype. The information could come while testing the prototype or having a discussion, and it helps us to create a collection of ideas on how to move the product (prototype) forward.
After the whole team gets an understanding of the research report, we sit together and decide how to move forward. We note down changes and improvements on a kanban board that lives usually in Trello.
Chiara could be that one entity that helps family navigating everything. We have learnt that families could find useful a virtual assistant in the referral process to the children hospice.
Despite some minor language friction, participants had no problem understanding Chiara's request. On the opposite side, the chatbot requires a bit more training and fixing to understand users.
Designing a chatbot was a completely new challenge to me, which I enjoyed. I feel more aware of the level of details and amount of decisions that goes into building a bot.
Amongst the challenges of this project, the most unexpected was finding the 'right' process to collaborate with Jorge, the developer.
Designing and building chatbots it is still a really new field in which the majority of the great work is done by developers. There are not that many examples out there of collaborations between designers and developers we could take inspiration from, so Jorge and I tried new approaches to come up with a development process. We still haven't defined a clear process in which is clear who should be making design decisions and how those decisions should be taken.