Voice: zo test je je idee en kies je het juiste platform

Geen reacties
Tags: , , , , , ,
Posted 14 mrt 2019 in nieuws

Voice is zo’n nieuw medium, dat het prettig kan zijn om eerst de mogelijkheden te onderzoeken voor je een developer aan de slag zet. Met een prototype kun je verschillende scenario’s uitwerken en die laten testen door gebruikers. In dit artikel bespreken we drie handige tools waarmee je zonder een regel code je idee kunt valideren en tips hoe je vervolgens een platform kiest.

In het vorige artikel keken we naar de businesscase van voice. Daarin bespraken we dat de beslissing om te starten met deze technologie het directe gevolg is van een kritische blik op je producten, diensten of processen en de mogelijkheden om die te ‘vangen’ in een voice-applicatie. Je concept moet immers wel meerwaarde hebben als spraakgestuurde toepassing.

Als dat het geval is, dan is de volgende stap om een script te ontwikkelen met behulp van een prototyping tool. Daarmee geef je het gesprek vorm en ontdek je eventuele obstakels vanuit de technologie en het platform waarop je wilt draaien. Als je die oplost, heb je een werkend prototype en kun je gaan testen met gebruikers.

Welk platform kies je?

Je zou denken dat je eerst het platform kiest waarop je je voice-toepassing wilt publiceren en daarna pas de prototyping tool. Dat kan, maar je kunt je idee ook eerst testen in een van de prototyping tools die we hieronder bespreken en later geschikt maken voor het platform dat je voorkeur heeft. Dit geldt eens te meer voor Siri, waarvoor geen speciale prototyping tools beschikbaar zijn.

Goed, laten we ervan uitgaan dat je voice-prototype gevalideerd is en dat je voor de keuze staat van het platform waarop je het uitrolt. Vooralsnog is de belangrijkste keuze of je gaat voor Google Assistant, Siri of Amazon Alexa. Er zijn meer spelers actief maar deze drie hebben de technologie het verst ontwikkeld.

Belangrijk om te weten is dat er een groot verschil is in hoever je kunt doorvragen bij de verschillende voice-assistenten. Google Assistant begrijpt de context van een gesprek behoorlijk goed, Siri en Alexa daarentegen nog niet. Als je bijvoorbeeld vraagt: ‘Wanneer is koning Willem-Alexander jarig?’ dan komen alle drie de spraakassistenten met het juiste antwoord. Maar als je vervolgens vraagt: ‘Hoe heten zijn dochters?’ dan begrijpen Siri en Alexa niet dat je het over de dochters van Willem-Alexander hebt. Google Assistant snapt dat wel.

De keuze voor een bepaalde assistent wordt dus vooral bepaald door de gewenste en benodigde mate van intelligentie van je applicatie. Op hoeveel manieren kunnen gebruikers een vraag stellen? Als er veel verschillende mogelijkheden zijn voor dezelfde taak, dan is Google Assistant de beste optie.

Een even belangrijke beslissingsfactor is waar je doelgroep nu al actief is. Kijk naar de beschikbare data over de bestaande kanalen (app, website, enzovoorts) of doe een survey – wat voor telefoon heeft je gebruiker, gebruiken ze al een voice assistant en zo ja, welke?

En de rol van de developer?

Het is niet zo dat je de developer pas betrekt bij de ontwikkeling van de voice-toepassing als met het prototype het concept is gevalideerd. De developer is de stem der rede in het hele proces. Zij hebben een beter idee van wat de hoofd actiepunten zijn van een applicatie of service. Je wilt niet vanuit beperkingen denken en je maakt prototypes met een bepaald doel. Maar toch is het een aanrader om eerst in de developer-documentatie te duiken voor je allerlei dingen verzint die gewoon nog niet kunnen.

In een vorig blog schreven we al over de voice-toepassing die we voor Greenwheels ontwikkelden, waarmee je met je stem de auto kunt openen. We hebben dit technisch werkend, maar door een policy van Google nog niet live gekregen. Voor Siri is namelijk een aantal domeinen vastgesteld waaronder de voice-app moet vallen: messaging, lijsten & notities, workouts, betalingen, VoIP bellen, visuele codes (QR), foto’s, ridesharing, autobesturing, auto-entertainment en restaurantreserveringen. Als dat niet het geval is, wordt de toepassing niet gepubliceerd. Omdat Greenwheels geen eigen auto is, viel de applicatie niet onder het domein autobesturing. Het businessmodel paste echter ook niet bij het domein ridesharing.

Google is minder streng maar kijkt wel of de voice-applicatie die je hebt bedacht een bepaald niveau heeft en niet in strijd is met privacyregels. Een developer kan goed beoordelen of de applicatie die je wilt maken daadwerkelijk gepubliceerd zal worden. En bij Apple en Google heb je de developer uiteindelijk nodig om ervoor te zorgen dat je toepassing voldoet aan de technische eisen en deze in te dienen voor goedkeuring. Alexa staat hier los van, in de zin dat die skills niet op een mobiel device worden gebruikt. Daardoor kunnen de meeste bedrijven zelf voice-toepassingen ontwikkelen voor Alexa.

Drie tools om prototypes te bouwen

Wij hebben ervaring met de volgende drie handige tools waarmee je zo’n prototype kunt bouwen:

Invocable(voorheen Thestoryline)

Met Invocable kun je heel laagdrempelig in een diagram een prototype maken. Dat gaat op het niveau van ‘als iemand dit woord zegt, dan voert het systeem deze actie uit’. Je kunt met deze tool heel goed testen of het gesprek dat je uitdenkt een afgerond geheel vormt en dus wordt afgesloten met het uitvoeren van een handeling of het geven van bepaalde informatie.

Kosten: Twee weken gratis trial, daarna 100 dollar per maand

Toepassing: Amazon Alexa.

Voordelen: Je kunt API’s toevoegen aan je prototype en Alexa skills direct uploaden.

Nadelen: Je hoeft geen developer te zijn om te kunnen werken met Invocable, maar hebt wel wat technische knowhow nodig.

Sayspring

Sayspring is tegenwoordig eigendom van Adobe. Hiermee kun je toepassingen maken voor Google Assistant en Alexa. De tool is onderdeel van de Adobe XD-ontwikkelingstool, dus als je daar al een licentie voor hebt, kun je meteen aan de slag. Het is laagdrempelig om een diagram te maken van het gesprek dat je voor ogen hebt. Na een paar uur kun je al testen of het werkt en je aannames kloppen. Dan is het nog niet daadwerkelijk geïntegreerd in je app maar het gesprek is al wel vormgegeven. Het is op zich ook geen probleem als je besluit om de skill niet in Alexa te publiceren. De vormgeving kun je testen en dat staat los van waar het landt.

Kosten: Gratis op uitnodiging.

Toepassing: Google Assistant en Amazon Alexa.

Voordelen: Laagdrempelig en door de koppeling met AdobeXD kun je voice toepassen in je app.

Nadelen: Je kunt geen API toevoegen aan je prototype.

Botsociety

Ook Botsociety is bedoeld voor Alexa en Google Home. Het is een visuele interface waarmee je simpele chatbotgesprekken kunt ontwerpen. Denk aan vraag- en antwoordsessies. Het is ook een heel erg laagdrempelige tool waarmee je snel een gesprek kunt vormgeven. Het prototype kan worden ingezet op messaging apps zoals Facebook Messenger en Slack.

Kosten: 0 dollar voor het opstartniveau, 79 dollar per maand voor bedrijven

Toepassing: chatbots voor onder andere Facebook Messenger, Google Assistant, Amazon Alexa

Onderschat voice niet

Wat vooral belangrijk is om je te realiseren is dat je voice er niet even bij doet. Als je een voice-applicatie lanceert, gaan mensen het gebruiken en dat brengt verplichtingen met zich mee. Het moet werken en tot in de details uitgedacht zijn. Wees bereid er geld en tijd in te steken. Het heeft technische implicaties voor je front- en backend, dus veel verschillende disciplines binnen het bedrijf moeten meedenken.

De grote valkuil bij voice is dat je te gimmicky wordt. Het is heel belangrijk om erop te letten dat je meerwaarde biedt en dat je alle scenario’s hebt uitgedacht. Dat is een enorme uitdaging in het ontwerpproces. Maar als je die uitdaging hebt overwonnen, heb je wel een killer voice-applicatie in handen.



Lees het volledige bericht op Emerce »


Add Your Comment