Designing for Voice: Making a Map

In my Voice Experience class at UVU we went through the general steps for a full design process in the Voice User Interface field. From a basic idea that you sketched on a napkin to a working prototype we went through what a designer could do, but we only did the steps as individual assignments and never all together.

For this project, our professor decided to throw us into the deep end to see if we would swim. We were to do a rapid prototype of a new Alexa Skill from ideation to prototype in about 2 hours.

The Setup

We were presented with a challenge to fix a pain point for students and teachers at Utah Valley University (UVU.) My group decided to talk with our professor who was relatively new to UVU, and would have more of an outsider’s perspective on the university.

He mentioned the class tracking app we use, Wolverine Track, and noted a few issues he had as a professor when evaluating classes, and we also griped about the app (it really isn’t very good.) Honestly it is a perfect example of the Flexibility-Usability Trade Off. It probably started off as a simple plan and sign up program but as the University has grown so has the web app with very little overview on how the app grew.

After talking with our professor, we went out and interviewed a couple students. Unluckily for us, it was 8 pm by this point and the rest of the class had already talked to everyone so we decided to double down on the Wolverine Track issues.

Though since we aren’t professors and wouldn’t have enough insight into the issues we decided to make a voice companion app for students registering for classes.

There was so much potential for a companion app, we could include features we wish the web app had like class and professor ratings, textbook ordering, and a concise way to review a schedule. Basically we wanted the world for this voice skill, but we only had an hour and a half left and very limited experience in this new field.

The Challenge

With so much possible functionality it was difficult to narrow down what the user could or should do in what order.

We settled on letting the user review their schedule, order books, and hear reviews of professors. The first version of this script looked like this:

User: Open Wolverine Track

Alexa: Welcome to Wolverine Track.

and that was it. So we tested this with users and added a much needed intro to the hello statement of the Skill. We did still like the simplicity of the Skill just saying “what can I help you with?” so we added tapering for experienced users in our script. If someone has used the Skill multiple times, Alexa is able to assume they know what the Skill can do and just asks what they want to do.

Now that we got the user into the Skill we had to make sure they had a road map to see where they could go. Follow up questions after overviews or answers to previous questions became this road map for the user. It presents useful information to the user to guide them through the functions of the Skill.

User: What is the Voice Experience class about?

Alexa: In the Voice Experience class, You’ll be designing for the Amazon Alexa and Google Home. Also, This course requires a book, would you like to order it? Or do you want more info on your classes?

In this example from our script the user has heard about the class, and is presented with a fork in the conversation. If the system just said the info about the class with no follow up question the user wouldn’t know if that was the end of the conversation and could get frustrated and leave the app. These narrow focus questions give the user clear options on where to go from here.

It was never enough to just answer the user’s question especially since we were primarily designing for a first time or novice user. With an almost overwhelming amount of information to present it was crucial to guide the user in a simple flow through the process.

Take Aways

Never assume the user knows how to use your app, or that they know what you are expecting them to ask next. We needed to provide follow up questions in order to bring them along through a new experience.

This also allows for an easier prototyping/testing flow, if a tester is presented with 2 narrow focus questions instead of one large wide focus question they are more likely to use the app in a predictable manner.

Designing this way may be more restrictive for the user, but restrictions for a new user are better than having the user get lost in the app and not know what to do. This way they can actually use the app without a road map they could get lost and close the app after one use and never come back.

The restrictions can also be lifted after they use the app a few times as we taper for their experience. In a way the system begins to trust the user to go around the app without a map and not get lost.