Chiara, the chatbot, is one of the prototypes developed as part of the work that our team at Helix Centre is doing in end-of-life care for children. You can read more about the whole project.
MAIS Family Office.
Helix Centre: Ivor Williams (Design Lead), Chris McCormack (Project Manager), Jorge Alexander (AI Software Developer).
User Experience, Visual and Interface Design, collaborating wit engineers, planning and running user testing, analysis & synthesis.
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 at home.
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 users' problems well enough so to capture them in a concise format. Their short format, helps the team breaking up the work into actionable chunks.
One of our stories: When parents get in touch with professionals they want them to remember their history so they can receive the most appropriate suggestions.
Defining the chatbot scope is making clear what people can expect from the 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 preceding steps:
- 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 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, should 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
This is the most complicated part result of a very active collaboration between Jorge, our 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 called '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 Chiara, the chatbot. 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 Helix Centre's 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. With user consent, each interview is carefully recorded and documented.
Then we produce a User Testing Report, in which we gather: our goals, list of participants, methodology, and results:
- Product Feedback
This section shows 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 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.
We found out that Chiara could be that one entity that helps family navigating everything: families finds 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 the 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 chatbot.
🤝 Amongst the challenges of this project, the most unexpected was finding the 'right' process to collaborate with Jorge, our developer. Designing and building chatbots it is still a new field in which developers do the majority of the great work. As far as we have explored, there are not that many examples of collaborations between designers and developers in building chatbots. So Jorge and I tried new approaches to put a process in place. We structured our semi-solid development process, but we still haven't found a clear way to operate and own design decisions.