ACC VOICE ASSISTANT
ACC + Springload, 2019 • 4 Weeks • Team: Rachel Bolt, Joris Rotteveel
How might we build a humane voice assistant prototype that helps injured people in New Zealand get better, faster?
“In the space of a week, we were able to design, build, and test a prototype that will aid ACC in exploring this technology further with confidence.”
— UX Designer, ACC
The Challenge
__
The Accident Compensation Corporation is the New Zealand Crown entity responsible for administering the country's universal no-fault accidental injury scheme. The scheme provides financial compensation and support to citizens, residents, and temporary visitors who have suffered personal injuries.
In 2018, ACC wanted to explore what New Zealanders might expect the post-injury recovery journey to be like in five years time. ACC faces the challenge of making sure their online services continue to meet their customers’ needs and expectations – now and in the future. They need to be accessible, easy to use, and meet New Zealanders’ growing preference for getting things done digitally.
In the future, voice assistants are expected to be a widely used medium for accessing digital services. ACC wants to use this emerging technology to enhance their customers’ experience when seeking medical help after an injury.
A five-day human-centred design sprint
__
As part of Experience Week 2018, I led a cross-agency team from Springload and ACC for a week-long human-centred design sprint. We designed, tested, and presented a working prototype capable of assisting injured people in New Zealand. It also aimed to increase ACC stakeholder engagement with their broader digital strategy.
Day 1: Aligning with ACC's digital strategy to create a meaningful prototype
__
To kickstart the sprint, we first got to know each other better. We shared what makes us thrive at work, our individual goals for the week – and our favourite drinks.
We took time to collectively understand the scope of the project and how we could align the prototype with ACC’s digital strategy. From this discussion, we created a list of assumptions to work towards clarifying by testing with users.
We set a goal of creating a working prototype by the end of the week.
Day 2: Empathising, prototyping, and iterating through user testing
__
On the second day, we conducted user research with people who’d experienced making an ACC claim following an injury. We interviewed them to find out the kinds of words they used to describe their injury.
Our user testing needed to be time and cost-effective, so we prototyped the conversation flow using a ‘Wizard of Oz’ technique. We ran a voice simulator on a computer hidden behind a stool fixed with a picture of a Google Home – giving the illusion of a voice assistant.
Through user testing with a diverse range of people, we discovered that we needed to make the conversation flow more adaptable. Some people started the conversation with ‘I want to book a doctor’s appointment’, whereas others started by saying ‘I’ve hurt myself’. By increasing the flexibility of the conversation flow, people could start where they felt most comfortable yet still be asked for all the information ACC need.
We synthesised our findings from user testing to turn themes and insights into actionable ‘how might we’ questions.
How might we design a tone of voice that is empathetic yet sincere?
How might we direct dead ends in the conversation back into the flow?
How might we structure the conversation so the most important tasks can be done first?
These questions helped us turn challenges into design opportunities.
Day 3: Building the refined conversation structure into the prototype
__
The refined conversation structure with multiple starting points.
Using our findings from the first round of user research, we refined the conversation structure. We then started coding the prototype on ‘Actions on Google’ – a platform for developers to build voice assistants on Google Home devices.
We continued to refine the conversation flow to make sure the prototype requested specific information for completing tasks in a logical and natural sounding way.
We also provided shortcuts for otherwise time-consuming tasks by putting those most important to the user first. These shortcuts helped the user follow what we call the “Happy Path”, which is the best user interaction possible.
Day 4: Refining the assistant’s voice and putting it into code
__
On day four, we continued to build the prototype’s code. We had it running on a Google Home by lunchtime, so we tested it with the same group of people as day one.
We asked users to describe what the voice assistant should ideally sound like – they told us simple, clear, efficient, and succinct. The assistant also needed the right degree of formality, balancing a professional and polite tone yet relatable and friendly.
We used these findings to refine the assistant’s tone of voice, and continue developing the prototype.
The coded conversation structure running on the ‘Actions on Google’ platform.
Day 5: Finalising code and presenting the working prototype to ACC
__
User testing the voice assistant prototype on the Google Home.
By day five, we’d completed development and were ready to present the voice assistant prototype to ACC.
We exceeded not only our own goals and expectations – but ACC’s too. So much so, that they want to invest in further development of the voice assistant.
“We approached Springload about prototyping a conversational experience. Together, we created something that leaves people with a smile on their face.”
— Digital Delivery Manager, ACC
The Results
__
A simple, efficient, and authentic voice prototype. By the end of the sprint, we’d designed and coded a working voice assistant prototype on a Google Home device. We used it to successfully demonstrate how a voice-controlled assistant might help ACC customers in the future. It can:
help book a doctor’s appointment,
arrange a taxi to the appointment,
listen to details about the injury and give advice,
inform friends or family about doctor’s appointments,
create a calendar event for people’s appointments.