Voice design & innovation at Eurostar

Image: Brother UK

The problem

Eurostar wanted to promote innovation, so the organisation created an ‘innovation team’ and tasked the team with creating an Amazon Alexa skill. I was brought in after the team had already begun its work; my goal was to help them create the most useful Alexa skill possible, as well as encourage a more user-centred and problem-led approach to innovation in future.

The outcome

Working closely with a product owner and two developers, I ran a rapid discovery phase to help us find the right use case for the skill, then prototype and test it; over the course of a month, we had validated a promising use case for our skill, and designed our first iteration.

The skill we went on to release is the first to allow users to search for travel dates flexibly by voice. It’s been extremely well-received and others in the Alexa community are reusing our search patterns. I worked with the team to turn our story into a talk that we have now given at multiple events. 

---

Listen to the Voice for Voice podcast trying out the skill.

Or try it out on your Amazon Alexa device. Say “Alexa, open Eurostar”. Or find it in the skills store here.

---

I went on to run workshops to help Eurostar rethink its technology-led approach to innovation and improve ways of working on the innovation team.

My process

---

I’ve told the story at a number of conferences and meetups:
- UX Crunch, London, UK
- London Alexa Devs Meetup, London, UK (write-up here)
- Edge Design Talks, Cluj-Napoca, Romania
- TechNOVA Voice, London UK

---

Kick off - Helping the team focus

The team had already identified a long list of potential use cases, and started building one of them - a skill for checking train status.

Use cases identified by the innovation team 

I worked with them to capture assumptions and questions around the right use case, and we used existing research to narrow things down to two potential propositions, imagining how the skill could work in an ideal world to help people in the future:

1. Travel Day - A skill for Eurostar ticket holders, providing them with helpful information on their day of travel, including train status.

2. Fare Finder - A skill to help people find and purchase the right train tickets.

Though both concepts had a basis in real user needs, we were still skeptical. Would voice really be a useful method of checking whether your train was running on time? And why would someone use an Alexa skill to search for and buy tickets, when it’s so easily done on a laptop or smartphone?


Rapid research into voice assistant habits and use cases

We knew nothing about people who use Alexa and other voice assistants. It felt like we needed to understand their habits before we could be sure of the right use case for a Eurostar Alexa skill.

So I organised some rapid qualitative research sessions with Alexa and Google Home users on Usertesting.com. I had them talk about what they use voice assistants for now and why, and react to two fake proposition adverts.


‘Advertisements’ to bring to life two potential skills, created in Google Docs

We learned a lot about people’s existing habits, but the learnings provided no clear direction for the skill. It’s early days for voice, and these particular participants didn’t use Alexa for many things; based on their reactions, our skill propositions seemed more like an interesting novelty than something these people would genuinely use.


Designing the right personality for our skill

We still weren’t sure what the right use case was, but we could define a personality for our skill to inform how it would ‘speak’ to users, and some principles for keeping its voice in line with the Eurostar brand. I arranged a quick workshop where our team partnered with marketing on this.



Competitor analysis

To help inspire the design of our skill, I tried out examples of other travel skills, as well as well-designed skills of all kinds. It seemed like there was a big opportunity for us to create a travel skill that worked well.


Prototyping conversation through role-playing

We then began prototyping our two propositions. We did this through role-playing: I played Alexa, working off a loose script. 

Part of a very early script that I used for role-playing conversations

I had conversations with people who were looking to travel in the near future, and had them imagine they were booking their trip and getting information about their train through a conversation with me.

The idea was to see where the conversations went, and use what we learned to help us design our skill as conversationally as possible.

The biggest takeaway? If we were going to help people search for tickets by voice, we really needed to provide them with a flexible way of searching for their travel dates.

When I, as Alexa, asked people “When are you thinking of going away?”, they gave all kinds of answers. Some gave exact dates, some were more flexible, and some couldn’t even give an answer because they were confused without a calendar in front of them.

Findings from role-playing

It felt like we really needed to cater to this in our conversation flow, to keep our ticket search easy to use and conversational.


Designing our ideal conversation flows

I used the learnings from our role-playing to finalise scripts for two different flows:

1. Plan a trip - Let Alexa know where you want to go and when you’re thinking of going away (whether you have exact dates in mind or not); she’ll surface the lowest priced ticket, and email you a link to book when you’re ready.

Why this use case? We knew that Eurostar customers have trouble finding low priced tickets on Eurostar.com. We hypothesised that people would prefer an email link rather than paying through voice, as people typically do a bit of research before committing to pay for a ticket.

Finalising a script for our ‘Plan a trip’ prototype

2. Check my train - Let Alexa know where you’re travelling to with Eurostar and when, and she’ll let you know whether your train is running on time, and what time to arrive at the station.

Why this use case? We knew that Eurostar customers often don’t know when to arrive at the station, and the company was keen to explore solutions to solve this.

Finalising a script for our ‘Check my train’ prototype


Creating a realistic prototype in the leanest way possible

We now wanted to create realistic prototypes of our two conversation flows, to test with users in the lab. We wanted to learn about the usability, and most of all see which of our two propositions was worth exploring further.

For our ‘Plan a trip’ flow in particular, we wanted to bring to life a smart ticket search conversation that would allow the user to respond to the question “When were you thinking of going away?” with either exact dates or flexible dates.

We also wanted our prototypes to be quick and throwaway so that we wouldn’t feel obliged to build out an idea that tested poorly. I tried various voice prototyping tools, but wasn’t satisfied with the results.

My devs came up with an amazing solution: they re-used some of their code to create a quick way for Alexa speak out our script, triggered by the user’s voice - the equivalent of a clickable prototype, broadcast over Alexa. As a bonus, a coded prototype like this would capture text of users’ responses, helping us understand how accurately Alexa parses what users say. 


Lab testing results blow our minds

I brought in participants  who were Alexa or Google Home users, who were also interested in travel. We wanted to learn about how they used voice assistants now, watch as they played around with Alexa, and test our two conversation flows through the prototype.

The biggest learning? It blew our minds how much people enjoyed the ‘Plan a trip’  conversation.

We thought people wouldn’t want to book tickets by voice, considering how easy it is to do this online. But the ticket search conversations seemed natural and easy. People expected to be able to surface the right ticket - and many also expected to continue the conversation and pay for it using their voice.

It emerged that this served a real user need. People do loads of research now when searching for the lowest priced ticket, exploring website after website. If they could find the right ticket through an easy, smart ticket search conversation, they told us, it would save them a lot of time.

One participant’s response after searching for tickets through our prototype

But there was a caveat - the conversation would actually have to be smart, and work.


Building a smart ticket search skill

We left the sessions determined to bring our smart ticket search conversation to life - we could see a big opportunity to help people if we got it right.

We began building our first working iteration to submit to Amazon. We wanted to release something quickly, that users could try out and that we could iterate on.

We knew we couldn’t perfect the whole skill in our first iteration. So we focussed on ensuring the most popular ticket search path would work smoothly - tickets from London to Paris. We also wanted to perfect our flexible dates search - asking users “When were you thinking of going away?” and adapting the search to whether they had exact dates in mind or not.

I create a flow and final script, and the devs started building.



But we hit a hurdle. Through our research, we’d collected many different types of responses to the question “When were you thinking of going away?”, so that we could build the skill to recognise these. But Alexa’s built-in date search library didn’t support all of these phrases.


All of the phrases we collected...so many it broke our skill

The devs solved this by creating our own more advanced date search library; this allowed us to build the skill in the way that provided the best user experience, and our date search library is now being shared in the Alexa community.

Our skill is now in the skills store, and we’re seeking feedback from real users. We’ve also adapted it to Google Assistant.


Our skill in the Amazon skill store


Rethinking Eurostar’s innovation strategy

After the launch of the skill, the innovation team wasn’t sure what to do next. We wanted to keep iterating on our skill, but the business had different expectations.

It emerged that the team had never had the chance to establish a vision or process; our product owner had been handed a list of technologies to explore from the business. But, he wanted to shift to a user and problem-led approach to innovation.

To help, I ran an “Innovation team ways of working” workshop. I planned carefully with the team, even storyboarding the day so that it would be a great and productive experience.

On the day, team and stakeholders got together to agree on what innovation means, agree on a team vision, and figure out how to get there.



We came away with a vision, principles, and actions to take to help us lead teams around Eurostar in problem-solving; this helped the team start its next project and maintain a focus going forward.