VUI design review — Atom Tickets
There are a lot of materials how we should design voice applications — articles, guidelines, conferences’ reports. But how actually is it going in real life?
In this article, I’ll review Atom Ticket application for purchasing tickets to the cinema from the design point of view. I’ll try to highlight both the good and bad sides. Have a nice reading.
About the author
Before I start the review, I want to introduce myself. I have been dealing with the voice application design for two years. For this time I have already participated as a speaker at 4 conferences, learned a lot of materials, and even written some my own. Also, I’m creating my own VUI designing tool. As a VUI-designer, I communicate a lot with other VUI designers and every time I try to learn something new from them.
This review is not the ultimate truth. I just hope my experience is enough to highlight obvious issues in design and to give some useful advice. In case I miss something or did a mistake, I’ll be glad to discuss it at commentaries.
The application review
For my review, I chose Atom Tickets Alexa skill. This app lets people buy tickets right from the smart speaker. I chose this one because I wanted to consider the scenario which often occurs with regular users of smart speakers. The ticket buying scenario seemed to me as a suitable variant.
Conventionally we can divide the app into two basic parts:
- The ticket purchase. It consists of location’s specification, the choices of film, cinema and time.
- The film’s release info. The app lists films, those are released at a cinema or gonna be released soon.
Happy path script
Me: Launch Atom
Atom: Welcome to Atom Tickets, the best way to go to the movies. You can buy tickets or browse movies. What would you like to do?
Me: Buy tickets to “Green Book”
Atom: Let’s find theaters near you. What’s your ZIP code?
Me: 94102
Atom: Do you want to see the movie today?
Me: Yes
Atom: Okay, there are 5 theaters near you. Say the name of the theater you want or to hear more say “next”. AMC Metreon 16, AMC Van Ness 14, AMC Kabuki 8. Which theater?
Me: AMC Metreon 16
Atom: Okay, now let’s pick a showtime. Available showtimes are: 11:55 AM, 3:25 PM, 7:05 PM, 10:25 PM. Which showtime?
Me: 10:25 PM
Atom: Please check the Alexa app and enable permissions for Amazon Pay. To return to this point relaunch the skill by saying “Alexa, ask Atom to buy tickets”. Goodbye!
*End of the conversation*
Yes, I don’t have Amazon Pay, and I didn’t want to buy tickets, so that’s why I gonna do the app review till this part.
All my journey through the application I put at Tortu. You can launch the app’s prototype, watch the flowchart or look through the utterances here.
Problems
Problems with confirmation
As it told at Google Conversation Design Guidelines — “Confirmations give users feedback on how their input was understood.” The application has a lot of such problems, and since it is an ordering movie ticket so a user must be 100% sure the app understands his order right.
Let’s review the problem with the following examples:
Atom: Let’s find theaters near you. What’s your ZIP code?
Me: 94102
Atom: What movie do you want to see?
or
Atom: What movie do you want to see?
Me: “Green Book”
Atom: Do you want to see the movie today?
In this case, the user is not sure, has the application understood him right. The correct example could be like this one:
Atom: Let’s find theaters near you. What’s your ZIP code?
Me: 94102
Atom: Okay, San Francisco, California. What movie do you want to see?
or
Atom: What movie do you want to see?
Me: “Green Book”
Atom: “Green Book”, nice choice! Do you want to see it today?
The problem occurs not only in cases where we specify the location or choose the film but also in another case such as when the user choose the date, cinema or showtime. It’s impossible to know the details of your order or ask something like “What film have I named?” therefore the problem becomes more important.
Excessive confirmation
At some moments the application grants a user the redundant choice or asks him an open question without any context.
Example:
*I told the app I want to buy tickets. The app specified my location*
Me: I’m in San Francisco, California.
Atom: Okay, I’ll use San Francisco as your search location. For the next step say “continue”. What would you like to do?
Me: Continue
Atom: Do you want to see the movie today?
I have already been in the purchasing tickets scenario and actually, it isn’t clear why the app aborted the flow with the phrase “For the next step say “continue”. It’s not enough that this phrase is like an obvious tip (to buy something, say “buy”), but it leads astray.
The correct variant:
*I told the app I want to buy tickets. The app specified my location*
Me: I’m in San Francisco, California.
Atom: Okay, I’ll use San Francisco as your search location. Do you want to see the movie today?
Thus, we got rid of the unnecessary step and open question, which could potentially lead us to unintended consequences.
Wide-focus questions
In general wide-focus questions are actively used at the application. There are cases where such questions are absolutely appropriate, for instance at the welcome-flow, but in another case, we should use more narrow questions.
The bad example:
Me: browse
Atom: You can browse movies that are playing or coming soon, or I can give you a recommendation. What would you like to do?
or
Atom: Okay, I can walk you through buying tickets for “Green Book”. To start the process say “buy tickets” or to exit say “stop”. What would you like to do?
The problem with wide-focus questions occurs when a user is already in the course of completing a random flow. Our aim is to help him complete it, so the open question may leads him astray.
The correct example:
Me: browse
Atom: Would you like to browse movies that are playing or coming soon? Also, you can ask me for a recommendation.
or
Atom: Okay, I can walk you through buying tickets for “Green Book”. Would you like to continue?
Narrowing the question is a hint for a user that only he can tell us the proper way of his activity. He hasn’t to guess what the app wants to hear from him. This is no doubt positively reflects on the conversion of the completing this flow.
Moreover, the open question may put the user expectations too high and then a user may ask what is not provided by the app.
Strong points
Greeting
The greeting is elaborated well at Atom tickets. When we are launching the app for the first time, we are welcomed with the phrase:
Me: Launch Atom Tickets
Atom: Welcome to Atom Tickets, the best way to go to the movies. You can buy tickets or browse movies. What would you like to do?
There are three things I liked:
- The right structure. The skill welcomes the user, sets expectations, lets the user take control. It is the right sequence and there is nothing unnecessary.
- Setting the expectations without overpromising. The app tells at once the things it lets us do — buy tickets or browse movies, it doesn’t overpromise.
- Avoiding the obvious tips. The phrase “You can buy tickets or browse movies. What would you like to do?” not only sets the promises right but also hints the user at how he can interact with the app without any obvious tip. Atom Tickets doesn’t say “To buy tickets, say “buy tickets”, it prompts the user with the natural way.
Moreover, when you launching the app for the second time, the app greets you in another way.
Me: Launch Atom Tickets
Atom: Hello again. Thanks for coming back to Atom Tickets. What would you like to do?
Firstly it saves us from unnecessary hints and saves our time. Secondly, every time we can hear the different greeting so it makes the conversation more natural.
Appropriate usage of narrow questions and wide-focus questions.
I have already touched on this theme, but now I want to focus on the good examples in the app.
The good example of the wide-focus questions usage:
Atom: Welcome to Atom Tickets, the best way to go to the movies. You can buy tickets or browse movies. What would you like to do?
This is a part of greeting, the user is not at any flow yet, therefore the wide-focus question is appropriate. We grant him the freedom of choice.
The good example of the narrow-focus questions usage:
Atom: AMC Metrion 16, AMC Van Ness 14, AMC Kabuki 8. Which theatre?
The user raises the order here, and the app specifying some details. The narrow question lets a user give the information to the app very exactly. The app knows the certain information about what kind of information a user interested in.
The right phrase construction
As it was highlighted at VUX Best Practices book by Voicebot, it’s very important to keep the order of the phrase construction right.
There is at the world of the GUI a user reads only some first lines and passes other. In the case of VUI, the situation is right on the opposite side. The user may listen to the first part of the phrase but certainly remembers the last words. Therefore it is important to place questions at the end of the message.
Good examples:
Atom: Okay, there are 5 theaters near you. Say the name of the theater you want or to hear more say “next”. AMC Metreon 16, AMC Van Ness 14, AMC Kabuki 8. Which theater?
or
Atom: Last time you searched for a Green Book. Continue buying these tickets?
Using the acknowledges
As Google Guidelines tells: “Acknowledgements assure users that their input was received.” The app hasn’t any issue with this statement. Every time I give the app some information it confirms it has got it.
Good example:
Atom: Last time you searched for a Green Book. Continue buying these tickets?
Me: No
Atom: Okay. What movie do you want to see?
Error handling
The application is fluent at handling the situations where something went wrong. It not only repeats the question but also grants us additional information.
Good example:
Atom: AMC Metrion 16, AMC Van Ness 14, AMC Kabuki 8. Which theater?
Me: *unresolved speech*
Atom: No results for *repeats my words*. Please pick form the list. AMC Metrion 16, AMC Van Ness 14, AMC Kabuki 8. Which theater?
Let’s suppose a user didn’t understand he has to answer the question “Which theatre”. In this case, the application not only repeats the words after the user (it dispel doubts about he simply wasn’t understood right) but also hints him what exactly he has to do — pick the theatre from the list.Informational Statements
Information statements
Before the app will give some information, it explains what exactly will be told. It helps a user to set himself for those data, which the app gonna tell him.
Good example:
Atom: Okay, there are 5 theaters near you. Say the name of the theater you want or to hear more say “next”.
Atom: AMC Metrion 16, AMC Van Ness 14, AMC Kabuki 8. Which theatre?
Hearing the app is gonna read out the list of the theatres the user is mentally prepared to receive the information. If there won’t be such warning, the user probably would listen to some first items at the list as he wasn’t prepared to receive this information.
Conclusion
Generally, I liked the Atom Tickets App. The interaction with it was clear and simple. The app told me what it can do right away, so I without any problems was able to order tickets to the necessary movie from the first attempt. In the case where an irregular situation has occurred (I didn’t know the ZIP code), the application dealt with it and suggested simply tell him the city.
Sometimes problems with information confirmation and open questions led me astray, but nevertheless, I got out of them. I think it is a good point for improvement, and of course, it is not a critical error. And also I haven’t founded any critical errors.
Tools I used:
- Tortu. I visualised the dialog with this tool, simply adding all my journey points. The prototype mode is pleasant bonus, because saved me from launching skill to go thought the scenario over and over again or simple copy the text.
- Reverb. Since I was recording all my interactions with the app, it could be conveniently to use Alexa via laptop. Reverb is an ideal tool for it.
Materials I used at my review:
- Google, Amazon, and Microsoft guidelines.
- Some materials from Voice Summit.
- Voicebot book
- My own experience
Summarising all I want to add that I want to discuss those moments where I missed something or did a mistake. What kind of mistakes or strong points you’ve found out?
Thank you for reading till this point. I want to review more applications, but not sure is it interesting for people. If you liked it please applause to this article, so I can understand how many people are interested in it. By the way, you can hold the Clap Button and clap even 37 times in a row ✌️
P.S: I’m a founder of Tortu, the tool that I mentioned above, so if you have any questions, suggestions or feedback I will be glad to discuss it. Here is my personal e-mail: p@tortu.io
