In het vorige artikel haalden we al stap 1 van het Conversational UX-model van Soundhound aan. Samenvattend bestaat het ontwerpproces van voice-conversaties volgens dit model uit 3 fases:
- Deliver: het creëren van een goede basis.
- Differentiëren: het creëren van meer natuurlijke interacties en het bedenken van vervolgvragen
- Delight: verras gebruikers
Bron: Presentatie Soundhound tijdens de Voice of The Car Summit, 8 April, 2020
Aanvullend op de in het vorige artikel besproken basiselementen is er nog één onderdeel cruciaal om een goede basis voor een conversatie te leggen: de ‘invocation name’. Dit is het woord waarmee gebruikers jouw voice app kunnen activeren. Het kiezen van dit woord kan best lastig zijn. Het radio-, podcast- en muziekplatform JUKE koos voor “JUKE” als invocation name voor haar voice-applicatie. Het probleem daarmee was dat de Nederlandse Google Assistant deze Engelse naam niet begreep (gelukkig hielp Google om de uitspraak goed geïnterpreteerd te krijgen). Bij de naam Beyoncé duurde het zelfs 18 maanden voordat de Google Assistant begreep dat het om de 24-voudig grammy-winnende zangeres ging. Best lastig om dan via voice een van haar liedjes op te zetten. Wees daarom altijd voorzichtig met het kiezen van een invocation name en zorg ervoor dat je merknaam gemakkelijk kan worden uitgesproken én kan worden verstaan in de taal van je voice-assistent.
Happy paths: ideale conversatieroutes
Kijk voordat je begint met het daadwerkelijk vormgeven van de conversatie altijd nog even terug naar het persona van je applicatie en de context waarin die het meest gebruikt zal worden. Zo weet je zeker dat je de juiste woorden gebruikt en je merk op de beoogde manier naar voren komt. Als je dat hebt gedaan, ben je klaar voor het leukste deel: het ontwerpen van de daadwerkelijke conversatie (tip: lees het boek Conversational UX Design van Robert J. Moore, een aanrader). Als een conversatie tussen een gebruiker en een voice-assistent op een ideale manier verloopt verloopt en de einddoelen van gebruikers worden gehaald, is er sprake van een zogenaamd ‘happy path’, een ideale conversatieroute. Een voorbeeld van zo’n route is als een gebruiker bijvoorbeeld vraagt: “Hey Google, vraag JUKE om radiozender 538 op te zetten” en een voice-assistent antwoord met “Ok, Radio 538 wordt nu opgezet”.
Voor een goed conversatie-ontwerp moet je weten wat de ideale routes zijn die een gebruiker kan afleggen om diens einddoel te bereiken. Bij een voice-app over hypotheken zijn er bijvoorbeeld verschillende happy paths. Denk aan de kosten van de hypotheek, de duur ervan, etc. Houd er rekening mee dat een gebruiker verschillende type vragen kan stellen over hetzelfde onderwerp. Daarnaast is het belangrijk om zoveel mogelijk manieren van vragen stellen en synoniemen van woorden op te nemen in je design. Zo zorg je ervoor dat gebruikers, op welke manier ze een woord ook uitspreken, het goede antwoord krijgen omdat de assistant de vraag herkent.
Het nut van foutmeldingen
Er bestaat altijd een kans dat voice-assistenten gebruikers niet begrijpen, waardoor gebruikers van de voorbedachte paden afwijken. Niet elke conversatie gaat daarom als gepland. Hoe leid je een gebruiker dan weer terug naar een ideale conversatieroute? Foutmeldingen kunnen helpen als een voice-assistent een opdracht niet begrijpt. Uit gebruikersonderzoek blijkt dat 2 tot 3 meldingen het maximum is voordat de irritatiegrens wordt bereikt. Deze stappen kun je inrichten zoals je wilt. Belangrijk is wel dat je bij elke escalatie iets meer context of informatie geeft wat er mogelijk is. Bij een podcast- of radio-applicatie zouden die als volgt kunnen luiden:
- “Welke podcast- of radiostation wil je horen?”
- “Wil je een radiostation of podcast horen?”
- “Je kunt me vragen een specifiek radiostation op te zetten door bijvoorbeeld te zeggen ‘Hey Google zet Radio 538 op’ of de naam van de podcast. Waar kan ik je mee helpen?”
Deze drietrapsopzet is een voorbeeld van hoe je het stressniveau van de gebruiker zou kunnen verlagen. Eerst vraag je om verduidelijking. De tweede keer probeer je het op te vangen in een bepaalde categorie (podcast of radiozenders) waarna je meer kan vragen. Ten slotte laat je expliciet weten wat er allemaal kan. Bij de laatste foutmelding zou je er ook voor kunnen kiezen om een pop-up bericht met een link naar een bepaalde pagina binnen je app of website te sturen om meer informatie aan de gebruiker aan te bieden. Dat kan bijvoorbeeld met een bericht als: “Sorry dat ik je niet heb kunnen helpen. Bij deze stuur ik een link naar je telefoon zodat je in de mobiele app verder kan zoeken. Ik spreek je snel.”
3 soorten foutmeldingen
Er zijn verschillende soorten foutmeldingen, over het algemeen onder te verdelen in 3 categorieën:
- ‘No Input’-foutmeldingen: deze verschijnen als voice-assistenten niets horen. Bijvoorbeeld, als een gebruiker in gesprek met een voice-assistent opeens de deur open moet doen voor de postbode met een pakketje. Zo ontstaat de situatie dat de assistent moet wachten op een antwoord. De eerste foutmelding die je kunt gebruiken is bijvoorbeeld: “Kun je wat luider praten?” Als een gebruiker daarna ook niet antwoord, geef dan wat meer informatie, een escalating detail, zoals: “Vertel me de naam van een artiest, nummer of een stuk van de songtekst en ik zet een nummer op.” Antwoordt een gebruiker nog steeds niet, ga dan in op de mogelijkheden van je voice-applicatie: “Je kunt me vragen om liedjes, radio of podcasts af te spelen door me titel, artiestennaam of songteksten door te geven. Waar kan ik je mee helpen?” Als een gebruiker daarna nog niet antwoord, sluit je het gesprek af.
- ‘No match’-foutmeldingen: deze meldingen verschijnen als voice-assistenten gebruikers niet verstaan of niet begrijpen. Zo kan een zoekopdracht (nog) niet verwerkt zijn in het conversatie-ontwerp of de gebruiker wijkt opeens van het onderwerp af. Bijvoorbeeld als een gebruiker in gesprek met een assistent opeens met iemand in de kamer gaan praten. Ook hier kan een eerste foutmelding bestaan uit een snelle reactie, zoals “Was dat een ja of een nee?”, gevolgd door een escalating detail en tot slot een korte opsomming van de mogelijkheden van de betreffende voice-applicatie. Zo heeft JUKE 3 verschillende ‘no match’-foutmeldingen, een algemene, een voor radio en een voor podcasts. Erg handig, omdat de woorden ‘podcast’ en ‘radio’ vaak terugkomen in de opdrachten die gebruikers bij JUKE geven. Op deze manier kan JUKE gebruikers onderverdelen in 3 categorieën, waardoor de applicatie gebruikers bijvoorbeeld alleen podcast-gerelateerde suggesties kan voorleggen.
- ‘Ondubbelzinnige’ foutmeldingen: bij deze foutmeldingen begrijpen voice-assistenten opdrachten tot op zekere hoogte, maar is er meer context nodig. Bijvoorbeeld als een voice-assistent vraagt: “Welk liedje wil je horen?” en een gebruiker geeft een vaag antwoord als “Een liedje”. Als een assistent de gebruiker en diens voorkeuren niet kent, is er in deze situatie meer informatie nodig. Vraag bijvoorbeeld naar welk genre of artiest de gebruiker wil luisteren. Zo help je de gebruiker uiteindelijk het juiste liedje te kiezen.
Bevestiging geven aan de gebruiker
In gesprekken met voice-assistenten zijn gebruikers vaak op zoek naar bevestiging. In het conversatie-ontwerp van jouw voice-applicatie kun je 2 verschillende soorten bevestiging verwerken:
- Expliciete bevestiging: als jij een vriend vraagt naar dat ene goede restaurant waarvan je de naam niet meer zeker weet, hoop je natuurlijk dat hij de naam die je in gedachten hebt, bevestigt. Dit is een expliciete bevestiging waar gebruikers van voice ook naar vragen. Het hangt per voice-applicatie af van hoe zeker deze bevestiging moet zijn. Bij een applicatie van een bank is dit bijvoorbeeld hoger dan bij een muziekapplicatie omdat het gaat om gevoelige informatie. Een bevestigingsmelding kan bijvoorbeeld bestaan uit: “Oké, je wilt dus €100 overmaken naar meneer Jansen, klopt dat?” Zo laat de applicatie zien dat ze gebruikers begrijpen, maar tegelijkertijd toch even de vraag dubbelchecken.
- Impliciete bevestiging: deze bevestiging wordt gebruikt als het antwoord zo goed als zeker is. Bijvoorbeeld, als een gebruiker vraagt om Radio 538 op te zetten en de voice-assistent antwoordt: “Oke, nu speelt Radio 538.” Hiermee geeft de assistent aan de opdracht begrepen te hebben en hem uit te gaan voeren. Ook hier geldt: hoe specifieker de informatie is die in een opdracht wordt gegeven, hoe meer zekerheid er in een bevestiging kan worden gegeven.
Dit is het vierde artikel van een serie van de DDMA Commissie Voice over het ontwerpen van de optimale gebruikerservaring voor voice. We hebben het onder meer gehad over de basis van voice design, het belang van persona’s, de essentie van voice-applicaties en tot slot de kernelementen van conversatieflows. Volgende week volgt er nog een extra vijfde afsluitend stuk over het belang van testen, inclusief succesvoorbeelden.
Anja de Castro
Krijn Janse
Ook interessant
Europese Commissie publiceert concept van ‘code of practice’ voor gebruik LLM’s
Nieuwe marketinggids Responsible AI voor de verantwoorde inzet van AI in marketing
