TLDR;

1. Kurz (und bündig)

"Benutzer hören selten zu, um komplexe verbale Informationen zu integrieren oder zu behalten." [1] Außerdem wollen sie nicht, es ist anstrengend. Deshalb sollte der gesprochene Text sehr kurz sein. Sehr gut ist dies im folgendem Beispiel beim Google Assistant umgesetzt, weniger gut bei ChatGPT:

Der Text von ChatGPT ist nicht gesprochen. Dennoch sollte er so gestaltet sein, dass man auf einen Blick die Antwort erhalten kann. Das nächste Problem dieser zu langen Antwort ist, dass neben der richtigen Antwort auch die falsche dabei ist. "Ein Fuß entspricht etwa 30,48cm" das ist richtig. "die Anzahl der Fuß durch 30,48 teilen, um die Länge in Zentimeter zu erhalten." Demzufolge sind 1 Fuß gleich 0,033cm. Unser Ratschlag an ChatGPT: Wenn du geschwiegen hättest, wärest du ein Philosoph gewesen.

2. Texte ergänzen gesprochene Sprache

Wenn ein Bildschirm vorhanden ist, sollte dieser verwendet werden um, wenn nötig einen präziseren oder umfangreicheren Text zu zeigen. Der gesprochene Inhalt muss die Frage dennoch beantworten, da Sprachassistenten über gesprochene Sprache funktionieren. Für die zusätzlichen Informationen gilt, dass der Text übersichtlich sein sollte. Entweder indem er kurz ist oder durch die Darstellung – zum Beispiel als Tabelle.
Dies ist sehr gut umgesetzt bei Siri und Google Assistant, wenn man nach dem Wetter fragt. Die sprachliche Antwort beinhaltet hier eine Angabe der Temperatur als Grad-Zahl oder als Äußerung wie: "Es ist ein kühler Tag" oder "Vergiss nicht deine Jacke mitzunehmen". Die grafische Angabe enthält die Details:

3. Rückfragen – Benutzer-Feedback ermöglichen

Wenn man nicht sicher ist, was der Nutzer will, dann kann man ihn fragen. Ein Beispiel dafür:

Nutzer: "Ich habe Hunger."
Cortana: "Du könntest mich nach Rezepten oder einem Restaurant in der Nähe fragen."

Das System war nicht sicher, was die Intention ist. Hier gibt es verschiedene Lösungsmöglichkeiten: Ein System kann raten. Wenn das System falsch rät, wird der Nutzer annehmen, dass das System unfähig ist.
Lediglich darauf hinzuweisen, dass die Anweisung unklar ist z. B. "Das habe ich nicht verstanden." oder "Dabei kann ich dir nicht behilflich sein." erklärt nicht, wie es zum Missverständnis gekommen ist. Infolgedessen kann der Fehler nicht behoben werden und das System wird als unfähig betrachtet.

Die Frage sollte nach dem Muster "Du kannst A oder B" bzw. "Meinst du A oder B" formuliert sein. Die Tonation sollte implizieren, da kommt noch was, sodass klar ist, es gibt noch weitere Möglichkeiten. vergleiche [2]

4. Kontext betrachten

Die vorherigen Fragen und Antworten zu betrachten ist hilfreich. Ein Nutzer der wiederholt Umrechnungen wünscht, dem kann eine angezeigte Tabelle hilfreicher sein als immer wieder eine kurze Antwort.
Dies gilt nur, wenn ein Bildschirm vorhanden ist. Die grafische Darstellung erlaubt es dem Nutzer diese zu überfliegen und selbst die nötigen Informationen herauszufinden. Deshalb auch eine Tabelle. Ein Fließtext mit den selben Informationen ist möglich. Gesprochener Text sollte hingegen nach "1. Kurz" formuliert werden.

Ein Nutzer der wiederholt die gleiche oder ähnliche Fragen stellt, wünscht eine andere Antwort, als die, die schon gegeben wurden. (Oder er testet das System.)

5. Barge-in ist wichtig

Menschen können ihren Dialog dadurch optimieren, dass sie (konstruktive) Unterbrechungen zulassen.

"Wer macht mir eine Pizza?"
"Es gibt verschiedene Möglichkeiten eine Pizza zu bekomme…"
"Nein, wie nennt man den Beruf."
"Achso… Pizzabäcker."

In solchen Fällen ist es für Menschen üblich und effizient elliptisch zu reden. Um menschlicher zu reagieren, besseren Dialog zuzulassen und schlicht effizienter zu sein, muss es erlaubt sein, ein System zu unterbrechen. Insbesondere dann, wenn die Eingaben geschrieben sind und deshalb keine Einbuße in der Erkennungsgenauigkeit zu erwarten sind.

Bei gesprochener Sprache ist es üblich lauter zu werden, wenn man jemanden korrigieren möchte und es ist natürlich, das man gleichzeitig spricht. Die Barge-in Lautstärke-Schwellwerte könnten also höher sein und das System könnte in einem solchen Fall einige Sekunden leiser weiterreden, bis es sicher ist, dass Barge-in passiert. Anschließend normal weiterreden, wenn kein Barge-in passiert oder zuhören, wenn Barge-in festgestellt wurde.

Barge-in gibt uns nicht nur eine neue Frage, sondern unter Umständen auch die Information, dass der letzte Antwortversuch unbefriedigend ist. Vorrausgesetzt die letzte Anfrage wird, dem Sinne nach, wiederholt.

6. Erster und letzter Text unwichtig

Der Nutzer versteht mit geringerer Wahrscheinlichkeit die ersten Worte einer Antwort, da er sich an Lautstärke und Tonation der Antwort anpassen muss, deshalb sollten die ersten Worte unwichtig sein. Auf die Frage "Wie spät ist es?" also lieber "Es ist 13: 15 Uhr." Antworten als "13: 15 Uhr." Genau das gleiche gilt für das Ende des gesprochenen Texts. Wenn kein Barge-in verwendet wird, ist zu beachten: "Nicht mehr als 100ms sollten zwischen Textende und Bereitschaft für Benutzereingabe vergehen"[3], das bedeutet so Balentine, dass die Nachricht rigoros getrimmt werden sollte. Die Aufnahmen beinhalten also keine Stille am Ende und teilweise werden die Endlaute gekürzt.

7. Erwartungskonformität

Ein Nutzer löst in einem System Aktionen aus. Wenn diese länger andauern, muss das System darauf hinweisen, dass es noch arbeitet. Bei Sprachassistenten sollten diese Hinweise auch auditiv übertragen werden. Je nach Persönlichkeit des Systems können diese Hinweise anders ausfallen. Ein professionelles System sagt: "Einen Moment bitte." "Gleich sind wir so weit", "jetzt geht es los", ein "menschliches" System könnte "Ähm…", "hmm", "Aja…", "So…" sagen. Dies signalisiert dem Nutzer

1. dass die Anfrage aufgenommen wurde,
2. dass sie verarbeitet wird und,

So kann man die Aufmerksamkeit des Nutzers wieder auf das System lenken, bevor die Antwort gegeben wird.

• [1] Balentine, Bruce/David P. Morgan(1999): How to Build a Speech Recognition Application, A Style Guide for Telephony Dialogues, Kapitel 2.1.5.1. Übersetzung J Dahms
• [2] Balentine, Bruce/David P. Morgan, (1999): How to Build a Speech Recognition Application, A Style Guide for Telephony Dialogues,Kapitel 2.7.2.3.
• [3] Balentine, Bruce/David P. Morgan, (1999). How to Build a Speech Recognition Application, A Style Guide for Telephony Dialogues,Kapitel 2.1.4.1. Übersetzung J Dahms

PS: Die Quellenangabe stellt eine Leseempfehlung dar. / ISBN: 0967127815 ISBN-Suche bei DuckDuckGo