Designing for voice
When beginning the creative process, we’d usually rely on tried and tested principles of design to inform decisions. The real challenge with designing for Alexa however, is that the technology is still very much cutting edge, as opposed to a mature ecosystem. This means that although Amazon provide some great UX suggestions and guides, there is no verified, ‘one-fits-all’ rule yet.
That’s not to say that the Alexa guidelines don’t lend themselves brilliantly to the majority of skills in the App store, however it has to be recognised that language design guides for suggesting your next TV show to binge watch may not be quite as appropriate for warning users on severe weather events.
TONE OF VOICE
During the design process of our skill, I attended a ‘Webcredible’ voice workshop along with many other large-scale UK organisations hoping to incorporate voice into their digital marketing strategies. The day consisted of a talk from Amazon, an open discussion panel with Head of voice at Virgin Trains, and a hands-on workshopping event with the voice UX experts at Webcredible.
One of the most useful takeaways of the day was to keep the tone of the skill light where possible, however to be flexible, and to alter the design of tone in relation to the information being communicated.
For example, Virgin trains revealed that they’ve modelled the tone of their Alexa skill in relation to whether they’re communicating good or bad news to the user. If your train is on time, the tone of response will be cheeky and informal, however if your train is late, the tone is serious and informative. User testing at Virgin stated that this tended to appease those that were receiving bad news.
Although for now we’ve simply been following the brand guidelines of the Met Office - “authoritative and trusted” - in the future perhaps we could experiment with mixing up tone in relation to the weather, perhaps more fun for a day with blue skies and good temperatures.
Text to speech weather warnings
The function that sets our skill apart from other weather providers is of course our weather warnings. However, implementing these in the skill proved a tricky design challenge in itself. Many decisions had to be made, from when to issue a warning, to the vocabulary used. While not issuing warnings at the right time could be dangerous to users in the area of the warning, we also had concerns that issuing them too frequently would provoke an attitude in which users become desensitised and therefore less susceptible to following advice.
We eventually made the decision to not mention yellow weather warnings (those with the least severe effects), to ensure that red and amber warnings would be recognised as something that the user should take notice of.
One of the most important aspects of handling user interactions is being able to admit when our skill is wrong, or is not performing in the way we’d like it to.
To us, it feels like common knowledge that users are more forgiving of errors if they are dealt with correctly. So how did we design for this?
1. We don’t simply return the same error message every time something goes wrong. All errors are different, and will have a different impact on the user, therefore it’s important that they’re handled as such.
2. Explain the error to the user in order to avoid the frustration of not being sure whether the fault lies with them or us. For example, if the error is simply caused by a mispronunciation of a place name, we should return something along the lines of “sorry, I didn’t understand that, try asking me again”. On the other hand if there is a problem with our data API’s, then the response should be something like, “Sorry, I’m having trouble getting that information at the moment, try asking me again in a few minutes”. This way, the user knows immediately if and how the issue can be rectified, and whether the fault lies with them or with our skill.
3. Where possible, provide an alternative or follow up action. Simply hearing “Sorry, this feature isn’t available or hasn’t worked” leaves the user unsure on what action to take next and can therefore be frustrating. Instead, where possible we tried to provide an alternative action for the user, so that our responses ended up something a little more like “sorry *this* isn’t working, try asking *this* instead”.
WHAT WE'VE LEARNT
As stated at the beginning of this post, on the scale of new technologies, Alexa and voice forward design remain to be relatively new concepts. Although we have been working with Amazon to ensure our skill uses the methods of best practice with responses, the only way to know whether we’ve nailed our UX design is through extensive user testing and feedback. While we work towards version 1.0, we’ve decided to focus primarily on the functionality in order to perfect a minimum viable product. However, for later versions of our skill, there is still a lot to be done with tweaking the design of responses and interactions.