User Experience in Voice User Interfaces am Beispiel eines Alexa Skills

Voice User Interfaces stellen neue Herausforderungen an alle, die sich für Benutzerinteraktionen verantwortlich fühlen. Während grafische Benutzerschnittstellen uns schon eine ganze Zeit begleiten und wir auf etablierte Entwurfsmuster, Prozesse und Werkzeuge zurückgreifen können, müssen diese für Benutzerinteraktionen mit Sprachinterfaces erst noch entstehen. Exemplarisch habe ich mir angesehen, was heute bei der Umsetzung eines Voice UIs in einem Alexa Skill möglich ist und wo konzeptionelle Herausforderungen liegen.

In einer Serie von Blogposts habe ich mich bereits aus technischer Sicht mit einigen Aspekten der Entwicklung eines Alexa Skills auseinandergesetzt. Dieser Beitrag ist keine Fortsetzung dieser Serie. Stattdessen werde ich mich hier rein auf den Aspekt des Sprachinterfaces und der User Experience mit einem Skill beschränken. Die technischen Artikel sind keine Voraussetzung für diesen Artikel, aus diesem Grund lassen sich einige Überschneidungen nicht ganz verhindern.

Hauptzutaten eines Skills

Ein Skill besteht aus zwei wesentlichen Hauptbestandteilen:

1. Dem Voice Interaction Model, welches die User-Interface-Schicht unseres Skill bildet
2. und einem Service, der die Logik beinhaltet, Benutzereingaben entgegennimmt und eine Antwort erzeugt (üblicherweise eine Sprachantwort).

Spricht der Anwender mit dem Skill, wird (durch den Alexa Voice Service) anhand des Voice Interaction Models ermittelt, ob die Spracheingabe verarbeitet werden kann. Wenn dies der Fall ist, wird der Service mit den notwendigen Informationen aufgerufen und anschließend die erzeugte Antwort zurück an das Echo-Gerät geschickt, welches es dem Anwender ausgibt.

Schauen wir uns das Voice Interaction Model einmal etwas genauer an:

Das Voice Interaction Model

Die Grundlage der Interaktion eines Nutzers mit einem Alexa Skill ist das Voice Interaction Model. Darin ist festgelegt, auf welche Spracheingaben unser Skill reagiert. Das Modell besteht aus folgenden Hauptelementen:

• Dem Invocation Name: Ein Dialog zwischen dem Nutzer und unserem Skill muss immer durch den Nutzer initiiert werden, indem er den Skill über einen Sprachbefehl startet. Wie sich der Skill starten lässt, ist durch den Invocation Name festgelegt.
• Den Intents: Intents sind mögliche Sprachbefehle, die unser Skill verarbeiten kann.
  • Für jeden Intent muss mindestens eine Utterance festgelegt werden. Eine Utterance ist eine konkrete Phrase, die der Benutzer sagen kann um den Intent auszulösen.
  • Intents sind nicht rein statisch, sondern können variable Anteile beinhalten, die sogenannten Slots. Welche Werte die Slots annehmen können, wird in Slot-Types definiert.

Ein Beispiel-Dialog

Das Zusammenspiel dieser Elemente wird verständlicher, wenn wir uns ein Beispiel ansehen. Nehmen wir an, wir hätten einen Skill für ein Würfelspiel. In diesem Skill haben wir einen Intent um ein neues Spiel zu starten, den starteSpiel Intent. Dieser Intent hat einen möglichen Slot mit dem Namen anzahlSpieler, der definiert, mit wie vielen Spielern der Anwender ein neues Spiel starten möchte. Der Slot anzahlSpieler hat den Typ AMAZON.number, d.h. nur Zahlen werden als gültige Werte erkannt. Der Intent kann über die Utterance Starte eine Spiel mit {anzahlSpieler} Spielern ausgelöst werden, wobei der Slot über die geschweiften Klammern gekennzeichnet wird.

Wird keine Utterance erkannt, bekommt unser Skill die Chance, eine generische Antwort in einem Fallback Intent zu erzeugen:

Lessons Learned

Nachdem wir den grundsätzlichen Aufbau eines Skills verstanden haben, werfen wir nun einen Blick darauf, was wir aus Sicht der User Experience lernen können.

Die Nutzungserfahrung mit einem smarten Assistenten ist durch vielerlei Dinge geprägt. Manche davon können wir beeinflussen, manche hingegen nicht. Zwei Hauptaspekte aber sind:

• Wie gut funktioniert die Spracherkennung? Also wird meine Stimme, mein Akzent erkannt und in den richtigen Befehl übersetzt ?
• Erkennt der Assistent meine Intention? Auch wenn die Spracherkennung funktioniert, ist längst nicht sichergestellt, dass auch meine Absicht sicher erkannt wird

Die Spracherkennung können wir nicht beeinflussen. Hier sind wir allein auf die Arbeit von Amazon angewiesen. Wir können aber viel dazu beitragen, dass die Intention des Benutzers richtig erkannt wird. Umgekehrt kann man hier aber auch viel falsch machen.

Welche Spracheingaben erlauben wir?

Wie Anwender mit Sprachassistenten interagieren ist sehr unterschiedlich. Je nach Alter, kulturellem Hintergrund, technischer Sozialisierung oder Bildung erfolgt die Ansprache mal sehr formal, mal weniger formal, höflicher oder befehlsorientierter, knapp oder ausführlich.

Es reicht also nicht, wenn wir als Experten uns einige Utterances überlegen, wir müssen früh unsere Anwender miteinbeziehen. Wenn wir wirklich wissen wollen, was Nutzer zu einem Sprachassistenten sagen, gibt es kaum eine bessere Methode als dies zu testen. Mit „Wizard-of-Oz“ Testing können wir dies schon, bevor wir auch nur eine Zeile Code geschrieben haben.

Erstaunlich war für mich, wie wenig smart unser Skill dabei behandelt wird. Sicherlich ist die Leistung von Amazon mit Alexa sehr beachtlich und im Hintergrund findet bestimmt auch viel Künstliche-Intelligenz-Magie statt. Aber bezogen auf unseren Skill ist es eher so: Entweder trifft ein Anwender eine unserer hinterlegten Phrasen (Utterances) oder die Eingabe wird nicht erkannt. Eine smarte Interpretation von alternativen Formulierungen konnte ich zumindest nicht feststellen (eventuell kommt das aber auch noch).

Anfragen in einer Session vs. Direktanfragen

Benutzer können einen Skill erst öffnen und dann eine Frage stellen oder als “one shot” einen Skill direkt mit einer Frage öffnen. Dies resultiert in unterschiedlichen Aufrufen, die sich im Wesentlichen über die veränderte Grammatik unterscheiden:

In ersten Fall müssen wir eine Utterance “Wie viele Mitspieler gibt es?” unterstützen, im zweiten Fall “wie viele Mitspieler es gibt”. Beide Utterances müssen aber explizit vom Skill-Entwickler angegeben werden, obwohl man annehmen könnte, dass ein Algorithmus erkennt, dass hinter beiden Fragen die gleiche Intention steckt.

Wir müssen also für jede mögliche Utterance die wir für einen Intent unterstützen wollen prüfen, ob sie auch als Direktanfrage denkbar ist und dann ggf. beide Varianten unterstützen.

Alternative Formulierungen

Um Utterances für unseren Skill zu formulieren, machen wir also Tests mit Anwendern und berücksichtigen die verschiedenen Arten, wie Alexa angesprochen werden kann. Daraus ergibt sich schnell eine sehr große Anzahl an unterschiedlichen Utterances. Hier können zusätzliche Slots helfen. Im Beispiel mit der Anzahl an Mitspielern haben wir einen Slot verwendet, um eine Variable in unserem Intent-Aufruf zu haben (die Anzahl an Mitspielern). Wir können Slots aber auch verwenden, um unterschiedliche synonyme Formulierungen zu unterstützen.

Auch hier wieder ein Beispiel:

Der starteSpiel Intent kann momentan über „Starte ein Spiel mit {anzahlSpieler} Spielern“ aufgerufen werden. Manche Anwender sagen aber nicht „Spieler“ sondern „Mitspieler“. Andere wollen das Spiel nicht „starten“ sondern „beginnen“. Also sind wir bereits bei vier Utterances:

• „Starte ein Spiel mit {anzahlSpieler} Spielern“
• „Beginne ein Spiel mit {anzahlSpieler} Spielern“
• „Starte ein Spiel mit {anzahlSpieler} Mitspielern“
• „Beginne ein Spiel mit {anzahlSpieler} Mitspielern“

Dies können wir durch zusätzliche Slots wieder reduzieren. Wir führen zwei neue Slots ein: starte mit den möglichen Werten „Starte“ und „Beginne“ und spielern mit den möglichen Werten „Spielern“ und „Mitspielern“. Mit dieser Änderung haben wir wieder nur eine Utterance, die wie folgt aussieht:

„{starte} ein Spiel mit {anzahlSpieler} {spielern}“

Auf diese Utterance passen nun alle oben definierten Phrasen, unser Interaction Model bleibt aber übersichtlicher.

Konflikte in Utterances

Mit einer steigenden Anzahl von unterschiedlichen Utterances steigt aber auch die Gefahr von Konflikten. Ein Beispiel: Nehmen wir an, wir würden einen Skill schreiben, mit dem ein Anwender Dinge einkaufen kann. Mögliche Befehle wären:

1. „Ich will {Produkt} kaufen“ und Alexa würde dann fragen wie viel von dem Produkt gekauft werden soll
2. „Ich will {Anzahl} {Einheit} {Produkt} kaufen“, um z. B. „zwei Packungen Milch“ zu kaufen“
3. „Ich will weniger kaufen“, wenn Alexa eine Mengenangabe falsch verstanden hat und man dies korrigieren möchte

In diesem Fall kann Alexa den Befehl „Ich will weniger kaufen“ nicht eindeutig zuordnen. Ist der dritte Intent gemeint oder will der Anwender ein Produkt mit dem Namen „weniger“ kaufen?

In diesem Beispiel sieht man das Problem noch recht schnell, bei vielen Intents und Utterances geht so etwas aber schnell unter. Hier helfen automatisierte Akzeptanztests .

Session-Verwaltung

Neben der Arbeit an der Formulierung, wie Anwender einen Skill ansprechen, war die Behandlung von Zustandsinformationen in einer Alexa Session ein weiteres großes Learning für mich.

Bleiben wir beim initial vorgestellten Skill für ein Würfelspiel. Wenn ich ein neues Spiel für fünf Mitspieler starte, erwarte ich als Anwender, dass sich Alexa diese Information merkt und nun fünf Spieler würfeln lässt. Zu diesem Zweck bietet Amazon dem Skill-Entwickler Möglichkeiten, Statusinformationen für die Dauer einer Session abzuspeichern.

Was ist eine Alexa-Session

Aber was genau ist denn eine Session aus Sicht eines Alexa Skills? (Leser der technischen Artikelserie kennen diesen Abschnitt bereits)

• Eine Session beginnt in dem Moment, in dem der Nutzer den Skill startet.
• Eine Session endet, wenn:
  • der Benutzer die Session explizit beendet (z.B. mit „Alexa, stopp“).
  • der Benutzer nach der letzten Antwort von Alexa nicht innerhalb von acht Sekunden wieder mit dem Skill interagiert.
  • Diese Zeit können wir einmal verlängern, indem wir eine erneute Nachfrage einbauen, die ausgegeben wird wenn der Anwender innerhalb der ersten acht Sekunden nicht antwortet. Kommt innerhalb von (erneuten) acht Sekunden dann wieder keine Antwort, wird der Skill beendet.

Eine Session ist also potentiell recht kurz. Gerade bei komplexeren Interaktionen ist bei einem Skill heute die Gefahr noch recht hoch, dass eine Session beendet wird, weil nicht rechtzeitig geantwortet wird, die eigentliche Intention des Anwenders aber nicht vollendet wurde. Dies ist aus meiner Sicht auch mit einer der Gründe, warum ein großer Teil der verfügbaren Skills heute auf sehr einfache Interaktionen beschränkt ist. Oft sind es einfache kurze Befehle, die von Alexa kurz bearbeitet und beantwortet werden (One-Shot-Interaktionen). Von einem echten Dialog zwischen Alexa und Anwender kann oft keine Rede sein.

Ein eigenes Session-Konzept

Wer trotzdem komplexere Interaktionen realisieren will, sollte sich dieser Herausforderung bewußt sein und eigene Lösungsstrategien erarbeiten. Das kann z.B. bedeuten, dass man sich für seinen Skill ein eigenes Session-Konzept überlegt, das eng an die Aufgabe geknüpft ist, die der Anwender bearbeitet.

Was wir nicht verhindern können, ist, dass der Skill sich beendet wenn der Anwender nicht kontinuierlich mit ihm interagiert. Aber wir können dem Anwender den Wiedereinstieg so einfach wie möglich machen, indem wir den Skill darauf auslegen, direkt am letzten bekannten Punkt wieder aufzusetzen. Dies ist sicherlich noch keine ideale Lösung, aber wir sind dadurch eingeschränkt, was technisch heute möglich ist. Aber der Trend scheint zu komplexeren Interaktionen zu gehen, also wird Amazon hier sicher nachbessern.

Technisch bedeutet dies, dass man sich von der Alexa-Session entkoppelt. Man kann den Status also nicht mehr im dafür vorgesehenen Session-State halten, sondern muss diesen über die Grenzen einer Alexa-Session hinweg speichern. Dadurch stellt sich aber die Frage: wann endet diese selbst definierte Session? Und wie erkenne ich das um den Session-State zu bereinigen?

Gesprächskontext

Im obigen Beispiel merken wir uns für eine Session, wie viele Mitspieler das aktuelle Würfelspiel hat. Dies ist naheliegend, sonst würde unser Skill nicht sinnvoll funktionieren. Wir wollen aber auch, dass sich ein Dialog mit unserem Skill natürlich anfühlt. Dafür brauchen wir aber noch mehr Gesprächskontext.

In unserem Würfelspiel-Skill könnte ich den Skill fragen: „Wie viele Fünfen habe ich gewürfelt?“. Wenn ich nun drei Fünfen gewürfelt habe, aber nur zwei dieser Würfel behalten möchte, wäre ein natürlicher Dialog:

Ich möchte also, dass Alexa automatisch erkennt, dass sich mein Befehl „Lege zwei davon zurück!“ auf meine letzte Anfrage bezieht, also die Fünfen. Diesen Kontext zu implementieren obliegt momentan rein dem Skill-Entwickler. Von Haus aus merkt sich Alexa keinerlei Kontext.

Geschwätzige Antworten

Ein anderer Aspekt, den es beim Entwurf eines Skills zu berücksichtigen gilt, ist, wie wortreich die Antworten des Skills ausfallen. Als Anwender wünsche ich mir kurze und knappe, aber ausreichend informative Antworten auf meine Anfragen. Hier gehen Skills heute häufig noch dem vermeintlich sicheren Weg und geben dem Anwender im Zweifel lieber zu viele Informationen. Wenn ich aber per Sprache durch eine Menge von Schritten navigiere und nach jedem Schritt darauf hingewiesen werde, dass ich mit „Weiter“ zum nächsten Schritt komme, mit „Zurück“ einen Schritt zurück und „Wiederholen“ den letzten Schritt wiederholt, dann wird das schnell lästig. Wenn ich Hilfe zur Navigation brauche, möchte ich lieber explizit danach fragen können.

Die Antwort so knapp zu bemessen wie in einem menschlichen Dialog ist aber oft auch nicht das richtige Maß. Wir sind eben nicht in einer menschlichen Interaktion. Denn auch wenn die Spracherkennung heute sehr beeindruckend funktioniert, ist sie im Allgemeinen nicht auf dem Niveau eines Menschen. Das wissen auch die Anwender und es bleibt eine gewisse Ungewissheit: Hat mich der Skill auch wirklich verstanden?
Im Beispiel oben fragt der Anwender: „Wie viele Fünfen habe ich gewürfelt?“ und die Antwort ist: „Du hast drei Fünfen gewürfelt“. Ein Mensch würde wohl eher nur mit „Drei“ antworten. Mit der etwas längeren Antwort beantworten wir so nicht nur die ursprüngliche Frage, sondern bestätigen auch, was der Skill verstanden hat und geben dem Anwender so mehr Sicherheit und Vertrauen in unseren Skill.

Fehlertoleranz

Ein wichtiger Aspekt bei allen Mensch-Maschine-Interaktionen ist die Fehlertoleranz und die Steuerbarkeit. Fühlt sich der Anwender in Kontrolle des Systems oder eher durch das System kontrolliert?
Um sicherzustellen, dass ein Slot in einem Intent richtig interpretiert wurde, bietet Amazon Skill-Entwicklern die Möglichkeit, Slot Confirmations zu implementieren. Dabei muss der Anwender die Werte die der Skill verstanden hat noch einmal bestätigen.

Die Möglichkeit, Aktionen vom Anwender noch einmal bestätigen zu lassen, ist insbesondere bei Aktionen sinnvoll, bei denen potenziell Daten verloren gehen könnten oder die eine finanzielle Transaktion einleiten. Aber die Häufigkeit, mit der sie in Skills eingesetzt werden, erinnert etwas an vergangene Tage in grafischen Benutzerschnittstellen, wo man noch häufig mit Dialogen behelligt wurde: „Sind Sie wirklich sicher, dass Sie das Spiel neu starten wollen?“ oder „Soll der Spieler wirklich gelöscht werden?“.
Vielleicht schaffen wir es auch bei Sprachinterfaces, dem Anwender mehr Kontrolle zu verschaffen, indem wir ihm bessere Möglichkeiten geben, Befehle wieder zurückzunehmen.

Fazit

Was Sprachinterfaces heute leisten können, ist bereits sehr beeindruckend. Mit Blick auf Alexa Skills ist für natürlich geführte Dialoge aber noch einiges zu tun. Heute sind die Interaktionen mit einem Sprachassistenten noch recht einfach und kurz. Wer trotzdem komplexere Interaktionen realisieren will, konnte hoffentlich in diesem Beitrag einige hilfreiche Anregungen finden. Wenn ihr ähnliche oder abweichende Erfahrungen gemacht habt, würde ich mich über euer Feedback in den Kommentaren freuen.