Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

Ratgeber

Was wir aus einer Shoppingtour mit Alexa, Siri und Cortana gelernt haben

(Foto: dpa)

Keine Frage: Sprache ist das Eingabeinterface der Zukunft. Doch eine Shoppingtour mit Alexa oder dem Google Assistant ist heutzutage mit einem dramatischen Kanalbruch in der Customer Journey verbunden.

Denn die digitalen Helfer verweisen bei Zalando und Co. in der Regel auf die Website des Anbieters – ohne Smartphone geht also nichts. In seinem Gastbeitrag skizziert Alexander Käppler von Diconium, wie die Customer Journey bei einem Wechsel vom Voice-Assistant auf eine Website gestaltet sein muss.

Mit dem Google Assistant, Amazons Alexa, Microsofts Cortana oder Samsungs Bixby erwachten die smarten Assistenten zum Leben. Die Verbreitung nimmt rasant zu, wenngleich die Usability aus dem Blickwinkel der Customer Journey zu wünschen übrig lässt. Bei Amazon ist es beispielsweise notwendig, sich einen Skill als Erweiterung der Alexa-Fähigkeiten innerhalb seines Amazon-Profils zu installieren. Erst dann ist dieser Skill mit der eigenen Alexa nutzbar. Google ist da etwas offener, die Funktionserweiterung wird einfach per Sprache adressiert, ohne diese vorher irgendwo installieren zu müssen. Hier reicht es „OK Google, rede mit … “ zu sagen.

Gibt es einen Skill, der auf diese „Invocation“ reagiert, übergibt Google jedes weitere Sprachkommando an diesen. Ab hier sind Amazon und Google in der Ausführung vergleichbar. Der Nutzer spricht seine Frage in das Gerät und der jeweilige Skill liefert eine passende Antwort. Das ist in der Regel eine verbale Formulierung in Verbindung mit einem Produktbild, einer Vermutung der nächsten Aktion oder ein Weblink zu einem Produkt.

Google Assistant. (Foto: t3n)

Schaut man sich dieses Vorgehen etwas genauer an, stellt man schnell fest, wie dramatisch der Kanalbruch innerhalb der Customer Journey im Real-Life-Szenario ist. Der Nutzer interagiert mit seinem Gerät – egal ob Alexa oder Google Assistant – per Sprache, spricht Fragen oder Befehle ein. Das Ergebnis ist jedoch gerade bei Skills, dass diese anschließend auf die Website oder auf den Shop des Anbieters weiterleiten. Aufgefallen ist uns das insbesondere bei E-Commerce-Skills wie dem von Zalando.

Das Ergebnis einer – nennen wir es mal Produktsuche – endet damit, dass der Nutzer sein Smartphone wieder in die Hand nehmen muss, um auf das Ergebnis zu klicken. Nichts mit Sprache. Nach einem Klick landet der Nutzer im Zalando-Shop und beginnt jetzt, wieder mit dem Smartphone in der Hand, durch den Shop zu navigieren, das Produkt in den Warenkorb zu legen und zu bestellen. Das kann als äußerst unangenehm empfunden werden, wenn man ja eigentlich im Voice-Kontext seine Customer Journey begann, um dann doch wieder per Smartphone oder Maus und Tastatur zur Eingabe gezwungen zu werden.

Cortana (Bild: Shutterstock / ymgerman)

Dieser Kanalbruch hat uns zum Nachdenken angeregt. Was, wenn der Nutzer nach seiner Sprachinteraktion mit einem Skill zwar im E-Commerce-System des Anbieters landet, dort aber nahtlos ebenso per Sprache weiter agieren kann? Wie ändern sich das Surf- und Navigationsverhalten, die Erwartungen und die Interaktionen mit einem E-Commerce-System, wenn dieses per Sprache bedienbar wird? Und kann man nicht noch einen Schritt weitergehen und das E-Commerce-System auch am PC sprachgesteuert bedienbar machen?

Um Antworten auf diese Fragen zu erhalten, haben wir ein Chrome-Plugin geschrieben, welches sich die nativ im Chrome-Browser implementierte Sprach-Unterstützung zu Eigen macht. Dabei haben wir einen Referenzshop betrachtet und das Plugin dahingehend programmiert, den Referenzshop bedienen zu können.

Verschiedene Aspekte beim Umgang mit einem bestehenden E-Commerce-System ändern sich massiv, wenn der Nutzer per Sprache navigiert. Unsere Learnings:

  1. Das Such- und Eingabeverhalten ändert sich. Die Eingaben sind nicht mehr eindeutig – wie etwa bei einem Klick auf einen Link. Suchanfragen werden komplexer, länger und schwer auswertbar.
  2. Die Erwartungshaltung steigt. Das bedeutet, kleine Fehler in der Ergebnisdarstellung werden weniger verziehen. Da die Eindeutigkeit des Klicks auf einen Link entfällt, steigt die Wahrscheinlichkeit, das falsche Ergebnis einer Spracheingabe zu zeigen.
  3. Als Feedback einer Interaktion reicht es nicht, die angeforderte Aktion nur auszuführen. Spracheingabe erfordert Sprachausgabe. Das bedeutet, jedes eingesprochene Kommando oder jede Funktion sollte auch per Voice-Feedback an den Nutzer ausgegeben werden.
  4. Wenn Sprache das führende Eingabe-Interface ist, dann wird der Screen in eine unterstützende Rolle gedrängt. Die Informationen, die auf der Seite dargestellt werden, sind in der Regel zu zahlreich, um sie entsprechend der Feedback-Anforderung vorzulesen. Folglich müssen visuelles und akustisches Feedback getrennt werden, wenngleich der Nutzer die vollen Informationen auf dem Screen zum Nachlesen erwartet. Die Darstellungsform sollte dabei Scrollen vermeiden, denn Scrollen per Sprache macht keinen Spaß. Das führte uns dazu, über einen neuen, noch nicht vorhandenen „Voice-as-UI-Breakpoint“ nachzudenken.
  5. Was der Nutzer nicht sieht, wird erfragt oder gelassen. Die bereits aus der UX bekannte Anforderung nach einer Darstellung der „Next best Activity“ wird im Kontext Voice-as-UI wichtiger. Was der Nutzer nicht als adressierbare Funktion erkennt oder nicht per Sprache mitgeteilt bekommt, macht er nicht. Schlimmer noch: Er beginnt, eigene Formulierungen für seine nächste Aktion zu nutzen, was wiederum dazu führt, dass die Spracherkennung gut genug sein muss, auch individuelle Fragen und Kommandos zu erkennen. Schlägt das fehl, ist die Frustrationsgrenze schnell erreicht und der Nutzer bricht ab.
  6. Das Adressieren und Ausführen der jeweils „richtigen“ Funktion muss – wie bei einem Link – eindeutig erfolgen können. Folglich müssen Funktionen eines E-Commerce-Systems eindeutig erkennbar und benennbar sein, ohne dabei die Spracheingabe zu kompliziert zu machen. Die intuitive Eingabe von „das dritte Hemd finde ich gut“ muss genauso möglich sein wie der Befehl „zeig mir meinen Warenkorb“ oder „lösche das dritte Produkt aus meiner Wunschliste“.
  7. Sicherheitsbedenken und Eingabefelder stellen eine kritische Hürde dar. Sowohl das Adressieren von Eingabefeldern wie auch die Bedenken der User, Nutzername und Passwort in eine Oberfläche einzusprechen, stellen die Verwendung der Sprache als Einagbe-Interface vor eine große Herausforderung. Das Eingeben der richtigen Information in das richtige Feld ist technisch realisierbar, aber wie geht man mit Passwörtern, Kreditkartennummern oder sonstigen eher privaten Daten um? Ein Blick auf OpenID, Facebook- oder Google-Login scheint interessant zu sein, um sich im Grunde einmal Internet-weit zu authentifizieren und dann alle Daten ohne erneute Eingabe zugriffsbereit zu haben.

Fazit unserer Sprachsteuerung von Online-Systemen

Voice-as-UI, also Sprache als User-Interface für E-Commerce-Systeme, wird kommen, die Forderung nach sprachgesteuerten Web-Systemen zunehmen. Alleine das Verhindern des Kanal-Bruchs und damit der Vermeidung von Conversion-Hürden wird dazu beitragen, bald auch sprachgestützte Onlineshops zu entwickeln beziehungsweise die aktuellen um sprachunterstützende Eingabe-Optionen zu erweitern.

Bixby zeigt euch auf einer Hilfeseite, was alles möglich ist. (Foto: t3n)

Die Herausforderungen sind jedoch aktuell noch ziemlich hoch, gerade wenn man bedenkt, dass sich niemand, wie in unserem Fall, für jeden Shop ein eigenes Plugin installieren will, welches die Eigenheiten des Shops richtig umsetzen kann.

Daher wird es meiner Einschätzung nach zwei Szenarien geben: Entweder es gibt ein Plugin, welches für alle Shops funktioniert, oder Google integriert die Voice-as-UI-Funktionalität (Sprachsteuerung von Webseiten) in den Chrome-Browser. In beiden Fällen wird es notwendig sein, die grafische Gestaltung für den Breakpoint „Voice“ zu erstellen sowie eine eindeutige Meta-Klassifizierung zu schaffen, die es ermöglicht, jede Funktion eines Shops oder einer Website im Sinne eines Befehlsinterpreters eindeutig zu adressieren.

Wir können uns vorstellen, dass die Adressierung basierend auf „data-voice“- Attributen innerhalb des HTML-Quellcodes ein erster Schritt sein wird, um auf Befehle im Sinne von Funktionsaufrufen oder Datenquellen des Voice-Interfaces reagieren zu können. Wie sich dann grafische Oberfläche, Interaktionsflüsse und Feedback-Lösungen konkret darstellen, wird sich zeigen – wir sind gespannt und bereit, den Weg voranzugehen.

Bitte beachte unsere Community-Richtlinien

Schreib den ersten Kommentar!

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.