Spraakassistenten worden meer en meer naar voor geschoven als nieuwe vorm van interactie met computersystemen. Siri, Alexa en Google Assistant strijden om de plaats van uw geprefereerde virtuele assistent. Ze duiken op in allerlei toestellen: in smartphones, smart speakers, tot zelfs in de auto. Naast Engels en Frans wordt ook het Nederlands steeds beter ondersteund.
Als organisatie kun je zelf toepassingen toevoegen aan de bekende spraakassistenten. Amazon spreekt van ‘skills’. Bij Google heten ze ‘actions’. Om de conversatie met dergelijke spraaktoepassingen zo vlot mogelijk te laten verlopen, schenk je best de nodige aandacht aan een aantal principes voor het ontwerp van de interactie: het ‘conversation design’.
Foutmeldingen als uitdaging
De manier waarop een spraaktoepassing omgaat met fouten bepaalt in sterke mate de gebruikerservaring. Een fout die niet of slecht opgevangen wordt kan ervoor zorgen dat de gebruiker de toepassing snel de rug toekeert. Dit zijn de drie soorten errors die we best opvangen in de conversatie:
Geen match: In bepaalde gevallen begrijpt de toepassing het antwoord van de gebruiker niet, of kan het dat niet correct interpreteren in de context van de conversatie. Dat kan voorvallen als de gebruiker niet volledig of onvoldoende duidelijk antwoordt, als de gebruiker niet tegen de toepassing spreekt maar bijvoorbeeld even iets bespreekt met een andere persoon, of wanneer deze radicaal van onderwerp verandert. Het kan ook voorvallen dat er een fout is gebeurd bij het omzetten van de spraak-input van de gebruiker naar een tekstuele vorm. De gebruiker kan ook een relevant antwoord geven, dat niet wordt begrepen door de toepassing. Een voorbeeld:
Gebruiker: “Ik wil tickets kopen”
Toepassing: “Ok, voor hoeveel personen?”
Gebruiker: “Voor mij en de kinderen.”
Toepassing : “Sorry, voor hoeveel personen?”
Om dit op te vangen vraagt de toepassing best opnieuw, kort en to-the-point om de nodige input. Loopt het dan alweer verkeerd, dan kan de vraag nogmaals gesteld worden met iets meer detail, of eventueel met een voorbeeld van passend antwoord. Lukt het dan nog niet, dan wordt de conversatie best afgesloten om verdere frustratie te vermijden.
Geen input: Soms weet de gebruiker niet goed wat hij moet zeggen, is hij afgeleid, spreekt hij nog vóór de microfoon openstaat, of wacht hij te lang en is de microfoon alweer afgesloten door de virtuele assistent. In die gevallen is er géén input van de gebruiker geregistreerd en moet de toepassing daarop passend reageren. Dat kan door de vraag opnieuw te stellen, eventueel met meer details, met een voorbeeld, of het expliciet opsommen van de mogelijkheden. Ook hier sluiten we de conversatie best af na twee extra pogingen.
Gebruiker: “Ik wil een aangifte indienen.”
Toepassing: “Ok, wat is het KBO-nummer?”
Gebruiker: <zoekt het KBO-nummer ergens op>
Toepassing: “Wat is het KBO-nummer van de werkgever?”
Systeemfouten: Ze kunnen voorkomen als een back-end systeem waar de toepassing gebruik van maakt tijdelijk niet-beschikbaar is, of een foutmelding teruggeeft.
Toepassing: “Akkoord om deze aangifte in te dienen?”
Gebruiker: “Ja”
Toepassing: “Door een technisch probleem kan ik de aangifte momenteel niet indienen. Wil je dat ik binnen een paar minuten opnieuw probeer?”
In het ontwerp van de conversatie moeten we dus rekening houden met alle mogelijke fouten die zich kunnen voordoen bij elk systeem waar de toepassing op steunt, er duidelijk over communiceren en eventueel een alternatief aanbieden.
De context als uitdaging
Wat een gebruiker zegt, en wat hij daarmee bedoelt, hangt soms af van de context. Dit betekent dat de spraaktoepassing deze context ook moet bijhouden en er rekening mee moet houden tijdens het verloop van de verdere conversatie. Alleen zo kan wat de gebruiker zegt, correct begrepen worden. Een voorbeeld:
Gebruiker: “Is mijn RVA-kantoor vandaag open?”
Toepassing: “Neen, het kantoor in Hasselt is vandaag gesloten.”
Gebruiker: “En morgen?”
Toepassing: “Morgen is het RVA-kantoor in Hasselt open van 8u30 tot 17u.”
Gebruiker: “En mijn RSZ-kantoor?”
Toepassing: “Het RSZ-kantoor in Hasselt is morgen open van 8u tot 16u30.”
Door rekening te houden met de context kun je de conversatie vlotter laten verlopen en vermijd je dat de gebruiker gefrustreerd geraakt. Het is belangrijk om alle relevante informatie die een gebruiker meegeeft bij te houden, zodat de toepassing deze elementen ook begrijpt wanneer de gebruiker er verder in de conversatie impliciet naar verwijst. In het voorbeeld hierboven houdt de toepassing bij over welk type kantoor het gaat en over welke datum. De kennis over de locatie van de gebruiker is vereist om de link te leggen met het desbetreffende lokale kantoor.
Werken met suggesties
In een klassieke grafische gebruikersinterface is het meestal duidelijk welke functionaliteit een toepassing biedt. De gebruiker kan dat afleiden uit de menu’s, invoervelden en knoppen. Bij een spraakinterface is dat minder evident en kan de gebruiker het gevoel hebben dat hij maar wat moet raden naar wat hij kan doen. Daarom is het nuttig dat de spraaktoepassing suggesties doet, om de gebruiker te helpen bij het beantwoorden van vragen en om bepaalde functionaliteiten te ontdekken.
Gebruiker: “Ik wil een Dimona-aangifte doen.”
Toepassing: “Ok, wat is de startdatum? Je kan bijvoorbeeld zeggen “4 juni” of “vandaag”.”
De gesproken suggesties kunnen aangevuld worden met suggestie-knoppen op het scherm. Dit biedt de mogelijk om te antwoorden met een druk op de knop en geeft aan welk soort antwoord de toepassing verwacht.
Tot slot
Zo zie je maar dat computers van nature uit niet zo handig zijn in het voeren van conversaties. We moeten een aantal zaken zelf expliciet opvangen in de spraaktoepassing, zodat de gebruiker zich op een natuurlijke manier kan uitdrukken en een zinvol antwoord terugkrijgt.
Een goed ontworpen conversationele interface kan een grote meerwaarde betekenen op het vlak van gebruiksgemak. Want hoe meer een interface gebruik maakt van menselijke conversaties, hoe minder gebruikers moeten leren omgaan met de interface.
Dit is een ingezonden bijdrage van Bert Vanhalst, Research consultant bij Smals Research. Via deze link vind je meer informatie over de het onderzoek van de organisatie.