Becoming a Certified Conversation Designer

Wir weisen einem Bot unbewusst so oder so Charaktereigenschaften zu – mit der Entwicklung einer authentischen Bot-Persönlichkeit kann der Conversation Designer diesen Prozess steuern. Dabei kommt es auf einige spannende Raffinessen an: z.B. die Haltung des Bots in der Beziehung zum Nutzenden, seine Hintergrundgeschichte und konkrete Eingarten seiner Kommunikation.

Die Haltung des Bots (“Register”) lässt sich anhand von 2 interdependenten psychologischen Dimensionen und deren Zwischenstufen charakterisieren: dominant vs. submissive & averse vs. friendly. Damit erhält man eine gute Richtlinie für ein konsistentes Bot-Verhalten.
Durch eine Hintergrundgeschichte kann die Persönlichkeit lebendiger erscheinen: Wo kommt der Bot als Person her, was sind zentrale Aspekte seines Werdegangs und was sind seine Vorlieben.
In den Eigenarten der Kommunikation wird die Persönlichkeit für den Nutzenden wiedererkennbar: bei der Stimme spielen z.B. Körperform oder “aural smile” eine Rolle, beim Chat z.B. Einsatz von Emojis oder Interpunktion. Dazu kommt ein Set aus typischen Formulierungen in Standard-Dialogsequenzen wie Begrüßung oder Entschuldigungen (Idiolekt).

Sobald die Use Cases geklärt sind ist die Versuchung groß, direkt mit der Planung der Konversationen loszulegen. Das habe ich bei meinem Trainings-Projekt “Virtuelles Ich” für meine Website gemacht. Wie man sich Dialogverläufe vorstellt und wie sie tatsächlich ablaufen, sind oft zwei verschiedene Dinge. Um die Mensch-Maschine-Interaktion sich möglichst natürlich entfalten zu lassen, bedarf es daher eines einfachen aber wirkungsvollen Prinzips: an den Anfang des Prozesses wird ein Beispiel-Dialog zwischen 2 Menschen gestellt; einer spielt eine konkrete User Persona, ein anderer spielt die Bot-Persönlichkeit. Damit dieses “Improvisationstheater” funktioniert, werden die Akteure ausführlich gebrieft, u.a. mit Infos zum physischen und sozialen Kontext des Dialogszenarios, zu den Zielen und psychischen Verfassung der User Persona und zu den Fähigkeiten und Verantwortlichkeiten des Bots. Auf Basis des Beispieldialogs gilt es dann, die Dialogstruktur in einem Flowchart abzubilden. Das Chart kann nun noch optimiert und für weitere Verläufe angepasst werden, hat aber eben seinen Ursprung in natürlicher Kommunikation.

Bot und Mensch haben in einer Konversation unterschiedliche Bedürfnisse: während der Mensch z.B. Empathie und zielgerichtete Hilfsbereitschaft braucht, ist der Bot auf das Erkennen von Sprachhandlungsfunktionen (“Intents”), die Bezugnahme auf gespeicherte Entitäten und das Herstellen von Kontext angewiesen. Beim Texten vieler Dialogverläufe kommt es daher nicht nur darauf an, sich am Vorbild zwischenmenschlicher Kommunikation zu orientieren (ein Kommunikationslinguist kennt die entsprechenden Prozesse 🙂 ). Manchmal muss man sich eben der besagten Diskrepanz im Mensch-Maschine-Dialog unterordnen.
Im Chat oder Gespräch würden wir z.B. auch nicht eine Liste von 7 Optionen runterrattern, sondern sie sinnvoll strukturieren, um eine Entscheidung zu erleichtern. Wir würden auch nicht eine Frage in der selben Formulierung mehrfach wiederholen. Allerdings können wir ein Sprecherwechsel (“Turn-Taking”) nur mit Blick & Gestik markieren oder mal das Fragezeichen nicht mit texten – ein Chatbot (oder Voice Assistant) sollte hier eindeutig agieren und einen Turn möglichst immer mit einer Frage inkl. Fragezeichen übergeben.

Die berühmte 80-20-Regel gilt auch im Conversation Design: 80% der Nutzer folgen 20% der Dialogverläufe. Es ist daher ratsam, den Aufwand auf den Head der Konversationen zu konzentrieren, dem sogenannten Happy Conversation Design. Im Long Tail wird dann über das Kosten-Nutzen-Verhältnis kritisch geprüft, welche Edge Cases sich lohnen integriert zu werden.
Wie man einen vermeintlichen Edge Case durch intelligentes Texten mit einem Standard-Szenario abfängt, hat ein tolles Beispiel aus dem Online-Kurs gezeigt: ein “Butler”-Bot kann für Urlauber einen Tisch in nächstgelegen Restaurants reservieren, Instruktionen fürs Kochen in der Unterkunft bereit stellen oder einen Lieferservice beauftragen. Was, wenn die Restaurants, die den Ansprüchen der Nutzer (asiatisch, vegan, familienfreundlich, etc.) genügen bereits ausgebucht sind? Sollte man nach Kompromissen suchen, die vielleicht irgendwie doch gefallen könnten? Einfacher ist hier, auf den Standard-Use Case “Lieferservice” zu verweisen und die Nutzenden dazu einladen, sich das Essen des Wunschrestaurants liefern zu lassen.