Wie Alexa, Siri und Co die E-Commerce-Welt revolutionieren

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 Assistent - per Sprache, spricht Fragen oder Befehle ein. Das Ergebnis ist jedoch gerade bei Skills, dass diese dann auf die Webseite 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 wird.

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 ändern, 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 viel, 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 Online-Shops zu entwickeln beziehungsweise die aktuellen um sprachunterstützende Eingabe-Optionen zu erweitern.

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 Webseite 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 voran zu gehen.