In early 2019 the team had the opportunity to work on a few Alexa skills, and so had the opportunity to test both our methodology and prototyping tech stack. Here’s the methodology we developed and the learnings we’ve taken from it.
The methodology
Taking a user-centred approach meant that we could fit the process into our existing framework, which should be familiar to most:
Understand > Define > Design > Test/iterate > Build > Live/optimise
Here’s the process we ended up following, much of which is the standard framework, but with voice-specific requirements highlighted below:
Understand
· Stakeholder requirements workshops
· Desk research, existing user research, academic papers etc
· Competitor/comparator research
· Tech exploration
· Primary research (with humans!)
What’s different? The key difference here is that you absolutely, categorically, have to do generative research with real humans in order to design for voice (especially for zero UI experiences, but we’ve found the same for interface+voice and chatbots as well).
You need to know literally what words your target users use in order to construct successful dialogue flows later, otherwise you will fail in the first user test. It’s even more critical if the user is doing something else in parallel — i.e. working in a kitchen environment. You need to know user behaviour as well as the words they’re likely to use — especially as one can influence the other!
You need to let your clients know this upfront. They cannot kill the gen!
Define
· High level task flows
· Brand voice and experience principles
What’s different? In voice, the whole design element is basically IA. We split “task flows” and “dialogue flows” between define and design respectively. This allowed us to focus on getting the basics of the interaction right before going anywhere near the words.
Because of this, we found that from the Understand phase, insight into user behaviour influenced more directly the task flows, and user speech influenced more directly the dialogue flows (design stage). Of course there are dependencies and I’m over-simplifying, but correlation was of interest.
Also, we were able to test the initial task flows which were created either with pen and paper or omnigraffle, using WoZ methods. A lot of fun, and also pushed our research skills!
Design
· Dialogue flows
· Prototypes
What’s different? No wireframes, obviously :)
Whereas in the define stage, we tried to limit ourselves to pen and paper, or Omnigraffle to get the basic flows working, with dialogue flows we needed to get into software as quickly as possible- not just for testing but so that we could start building out and tracking intents and utterances in a logical way.
Part of my IA brain wanted this to be done in a giant spreadsheet, but we were moving too quickly in test cycles and essentially it became wonderfully redundant due to the software we had.
The other great thing about separating Task flows (define) and Dialogue flows (design) is that we could establish the experience principles and brand voice up front as a hypothesis, focus on getting the basic flows right, and finesse the tone of voice in later testing cycles. Essentially “how does your brand sound” doesn’t have to be fully integrated until you’ve nailed usability.
Test/Iterate
· User testing — WoZ and Voiceflow/Alexa
What’s different? As described above, we used two different methods — Wizard of Oz (WoZ) testing to iterate the basic flows, and Voiceflow directly into Alexa to user test the dialogue flows.
Voiceflow is an app that allows you to create dialogue flows, including intents, utterances, slots and a whole lot more. It also lets you sling it directly to an Amazon device (we were using an echo) for user testing.
The best bit is that you can actually push live directly from this environment, which made our creative techs very happy.
Learnings:
- UCD works. Much in the same way that the original NN heuristics still apply to voice app design, the UCD process stands the test of time in terms of keeping user needs (no matter how complex) front and centre. It also removes risk by providing stage gates of testing and validation.
- UCD can and needs to adapt to voice design. Just by running our standard framework, we discovered that different versions of traditional IA and research tasks and methodologies were needed within the overall approach — but that it still held well as a framework. The biggest learning within the framework however was that define, design and test need to be run in tight iterative loops to move the project forward.
- Finally, as the UXD team have found repeatedly, and as clients and other teams rarely understand at the beginning — writing dialogue flows let alone error states is much harder than you think it’s going to be.
But that’s a post for another day.
If you found this useful, consider subscribing for free to get email alerts when I post new articles, or you can join Medium for full access to my article archive, plus everything else on Medium.
