Suche
Mit den richtigen Usability-Zutaten zum Rezept für Conversational UI

3 Zutaten für glückliche Chatbots: Usability-Rezept für Amazon Alexa, Google Home, Apple Siri & Co.

Christian Ochsenkühn

(c) Shutterstock / Maxfarruh

 

Wer bereits in den Genuss gekommen ist, mit Amazons Alexa, Google Home, Apples Siri oder Microsofts Cortana zu sprechen, der merkt schnell, dass die Ein- und Ausgabe per Sprache noch einige Tücken aufweist. Das einfache Abbilden von Rezepten aus der Gestaltung grafischer Oberflächen auf Conversational UIs bringt den Nutzern mehr Schmerzen als neue positive Möglichkeiten zur Interaktion. Um also weiterhin eine gute Usability für die Begebenheiten der Sprachassistenz zu bieten, müssen wir bestimmte Zutaten dieser Rezepte austauschen, anpassen oder neu hinzufügen.

Zutat 1: Kontext halten

Eine der elementarsten Anforderungen an ein Conversational UI ist, den Kontext zu halten. Wie auch in einem Gespräch von Mensch zu Mensch fühlt sich ein Nutzer schnell von einem Gegenüber genervt, der im folgenden Satz nicht mehr weiß, um was es einige Sekunden zuvor ging. Wenn eine Nutzerin also ein Auto mieten möchte und gerade über die Wagenklasse spricht, dann erwartet sie, dass die Anwendung in diesem Kontext mit dem folgenden Satz umgehen kann. „Was wäre eine Kategorie höher als meine jetzige?“ Der Sprachassistent muss dabei wissen, dass es um die Kategorie der Wagenklasse geht und welche Kategorie die Nutzerin aktuell ausgewählt hat.

Das erscheint noch ziemlich selbstverständlich. Schwieriger wird es aber schon, wenn ein Nutzer die aktuelle Aufgabe, die er mit dem Assistenten bespricht, wechseln möchte. Mit einer GUI ist das relativ einfach zu bewerkstelligen. Der Nutzer möchte wiederum ein Auto mieten und befindet sich im Bestellvorgang. Währenddessen fällt ihm aber ein, dass er sich auch vorstellen könnte, einen Van zu mieten. Er öffnet also zum Beispiel ein neues Fenster, recherchiert dort und wechselt zum eigentlichen Bestellvorgang zurück.

Lesen Sie auch: Einen eigenen Chatbot bauen – so geht’s!

Auch bei der Interaktion mit einem Sprachinterface ist das kein untypisches Verhalten. Wir müssen also damit umgehen können. Dazu gibt es verschiedene Möglichkeiten. Fragt ein Nutzer während der Buchung eines Autos „Kann ich auch ein Wohnmobil mieten, und was kostet das?“, so könnte der Assistent fragen, ob die Bestellung wirklich abgebrochen werden soll. Gibt es positive Resonanz vom Nutzer, erzählt das Interface über Angebote von Wohnmobilen. Das mag in manchen Fällen sinnvoll sein, ist in diesem Beispiel aber nicht zielführend. Besser wäre es, den Kontext zu wechseln, den Nutzer darüber zu informieren (Transparenz) und sich zusätzlich den Bestellvorgang zu merken. So kann der Nutzer, nachdem er über Wohnmobile informiert wurde, gefragt werden, ob er zum Bestellvorgang zurückkehren möchte.

Dass der zweite Ansatz hier der bessere ist, wissen wir aber nur, weil wir uns den Grund für den Kontextwechsel des Nutzers selbst ausgedacht haben. In der Realität werden solche Vorgänge schnell übersehen oder falsch antizipiert. Es ist daher wichtig, sich solche Szenarien im Vorfeld genau zu überlegen und zum Beispiel mit Personas zu erarbeiten.

W-JAX
Ivo Wessel

QWERTZ war gestern! Interfaces von morgen

mit Ivo Wessel (IN BEST HANDS UG)

Dominik Obermaier

Securing MQTT

mit Dominik Obermaier (dc-square GmbH)

Zutat 2: Transparenz schaffen

Nutzer: „Habt ihr kommenden Mittwoch noch einen Kleinwagen zu vermieten?“

Bot: „Ich habe Ihnen einen Kleinwagen für Mittwoch, den 22. Februar gebucht.“

Ein solcher Dialog würde wohl jeden Nutzer veranlassen, diese Sprachanwendung nie wieder zu nutzen. Hinter der ausgeführten Aktion fehlt die Transparenz. Der Nutzer weiß nicht, warum er direkt gebucht hat oder welcher Teil seiner Aussage die Buchung veranlasst hat. Er vertraut der Anwendung nicht mehr.

Das geht aber auch anders. Als Nutzer möchte ich zu jeder Zeit wissen, was bzw. ob meine gesprochene Antwort eine bestimmte Aktion auslöst. Mir muss transparent gemacht werden, was gerade passiert.

Wenn zum Beispiel eine fehlerhafte Eingabe gemacht wird, ist eine Erklärung zum Fehler und bestenfalls eine Lösung sehr hilfreich. Sagt eine Nutzerin „Ich möchte das Auto in Woltersdorf abholen“, hilft ihr die folgende Antwort: „Schade, dort können Sie den Mietwagen leider nicht abholen. Der nächste verfügbare Ort wäre Magdeburg. Soll ich Magdeburg zur Abholung auswählen?“ Diese Antwort bietet ihr direkt eine Lösung, die sie, falls gewünscht, nur noch mit „Ja“ bestätigen muss.

Sagt die Nutzerin hingegen etwas wie „Ich hole das Auto auf meinem Balkon ab“, kann sie darauf hingewiesen werden, dass dies keine sinnvolle Eingabe ist (auch wenn sie das vielleicht schon weiß).

Mehr zum Thema in unserem Gratis-Dossier Machine Learning

Ähnlich wichtig ist Transparenz für Eingaben, die kritisch oder absolut notwendig sind. Wenn sich Nutzer dessen bewusst sind, können sie auch entsprechend reagieren. In einer GUI kann ein entsprechender Hinweisdialog die weitere Eingabe sperren, bis die notwendigen Informationen (z. B. eine Emailadresse) geliefert wurden. In einem Conversational UI hingegen muss der Nutzer immer wieder darauf hingewiesen werden. Das kann einige Nerven kosten.

Nutzer: „Schicke mir die Buchungsbestätigung per E-Mail zu.“

Bot: „Dazu müssen Sie zuerst Ihre E-Mail-Adresse in der App verifizieren.“

Nutzer: „App ist nicht da. Bitte trotzdem schicken.“

Bot: „Leider kann ich Ihnen erst eine E-Mail schicken, wenn Sie Ihre E-Mail-Adresse in der App verifiziert haben.“

Hier helfen unterschiedliche Antwortmöglichkeiten, wenn der Loop öfter durchlaufen werden muss. In anderen Fällen könnte dem Nutzer auch eine limitierte Funktionalität angeboten werden, solange er eine erforderliche Eingabe noch nicht getätigt hat.

Zutat 3: Nutzer an die Hand nehmen

Nun haben wir das Conversational UI so weit, dass es die Zusammenhänge von Anfragen versteht und am besten so transparent antwortet, dass die Nutzer das Was und Warum der ausgeführten Aktionen nachvollziehen können. Doch die nächste Herausforderung wartet bereits hinter Zutat drei.

Dort verbirgt sich ein weiteres Risikopotential für schlechte Usability. Genauer gesagt in OSI-Schicht 8 – beim Anwender selbst. In einer per Sprache bedienbaren Anwendung können Nutzer grundsätzlich sagen, was sie wollen. Das führt dazu, dass wir häufig Antworten wie „Das habe ich leider nicht verstanden“ zu hören bekommen. Das frustriert.

Wirklich verhindern können wir unpassende Eingaben nicht. Aber wie können wir diesen vorbeugen? Grundsätzlich sollte der Sprachassistent den Nutzer an der Hand nehmen und proaktiv zu spezifischen Aussagen bzw. Satzfragmenten bewegen. Das heißt, ihm werden keine offenen Fragen gestellt, sondern immer bereits Hinweise zur Antwort mitgegeben. Das macht auch aus psychologischer Sicht Sinn. Der Nutzer erhält verschiedene Optionen, aus denen er auswählen kann (=positiv), anstatt ihm alle Möglichkeiten offen zu lassen, von denen wir den Großteil nicht bedienen können (=negativ).

Bot: „Wir haben Kleinwagen, Wagen aus der Mittelklasse und Wagen aus der Oberklasse im Angebot. Was sagt Ihnen davon zu?“

Dieses Beispiel gibt nicht nur einen Hinweis auf die möglichen Antworten, sondern glänzt zudem durch einen anderen Punkt. Der Satz bezieht sich nur auf ein Detail der benötigten Eingaben. Alle anderen Informationen wie das Datum, die Mietdauer usw. sollten peu à peu abgefragt werden.

Hat der Nutzer die Antwort gegeben, wiederholt die Sprachassistenz die Eingabe, um auf Feedback reagieren zu können, falls etwas falsch verstanden wurde. Gleichzeitig enthält die Antwort des Assistenten zusätzlich eine weiterführende Frage zur nächsten geforderten Eingabe. So wird verhindert, dass der Nutzer jedes Mal mit „ja“ bestätigen muss.

Bot: „Schön, ein Kleinwagen also. Wann und wie lange möchten Sie ihn mieten?“

Hat er nicht vorhin gesagt, dass immer nur eine Information abgefragt werden soll? Ja, das ist richtig. Sie sehen schon, es gibt immer noch einen anderen Weg. In diesem Beispiel spielen die abgefragten Informationen aber so eng zusammen, dass sie getrost in einem Satz abgehandelt werden können.

Auch interessant: Interview mit Dorothea Kolossa: “Wir werden Sprachinteraktion zwischen Mensch und Maschine bald als einen ganz normalen Prozess erleben”

Fazit

Obige Zutaten sind nur ein kleiner Auszug an Herausforderungen, die mit der Interaktionsmöglichkeit „Conversational UI“ einhergehen. Auch wird es weiterhin Fälle geben, wo eine grafische Ausgabe mehr Sinn macht als eine Sprachausgabe. Hier entscheidet der spezielle Anwendungsfall. Wenn Sprache zur Interaktion richtig eingesetzt wird, so kann sie den Nutzern erheblichen Komfort bieten und Zeit einsparen. Am besten funktioniert sie, wenn sie in Verbindung mit einer grafischen Ausgabe benutzt werden kann. Denn manchmal sagen Bilder doch immer noch mehr als tausend Worte – ähnlich wie bei Kochrezepten.

Geschrieben von
Christian Ochsenkühn
Christian Ochsenkühn
Christian Ochsenkühn arbeitet bei der OPITZ CONSULTING Deutschland GmbH im Bereich Software Development. Zudem beschäftigt er sich für die Abteilung Business Development & Innovation mit aktuellen Trends und innovativen Lösungen für digitale Problemstellungen. Als Betreiber eigener Webangebote kennt er die Herausforderungen des schnellen technischen Wandels und konzentriert sich auf eine optimale Benutzererfahrung.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.