Was bisher geschah: Unser Voice & Tone Guide
Vor einiger Zeit habe ich in einem Blogartikel berichtet, wie wir im Rahmen unserer Centigrade Rebranding Journey unseren eigenen Voice & Tone entwickelt und in einem Voice & Tone Guide festgehalten haben.
Ich hole euch noch einmal kurz ab, wofür man als Brand eigentlich einen eigenen Voice & Tone braucht:
„Damit wir nicht bei jeder Fehlermeldung aufs Neue überlegen müssen, wie wir die jetzt brandkonform formulieren wollen, gibt es dafür eine Methodik. Und die ist die systematische Entwicklung von Voice & Tone. In einem Voice & Tone Guide halten wir fest, wie wir welche Inhalte formulieren, um sicherzustellen, dass wir passend zu unseren Markenwerten kommunizieren und unsere Nutzer*innen in jeder Situation auf der richtigen sprachlichen Ebene ansprechen.“
Wer möchte, kann den gesamten Artikel hier nachlesen:
Blogartikel „Das Branding Tool für UX Writers: Der Voice & Tone Guide
Voice & Tone Guide in der Praxis: Ein „Hot Mess“
Ein Voice & Tone Guide kann sehr umfangreich werden. Es ist oft nicht damit getan, mit ein paar Adjektiven den gewünschten Voice & Tone zu beschreiben – soll er wirklich unmissverständlich und allumfänglich sein, muss man sich über eine Reihe von Themen Gedanken machen, beispielsweise:
- Wie integrieren wir Inklusion und Diversity in unsere Sprache, wie gendern wir also z.B.?
- Kommunizieren wir humorvoll und informell, ernst und formell oder wechseln wir zwischen den beiden Modi je nach Marketingkanal?
- Wie lässt sich der Voice & Tone auf User Interfaces übertragen? Stichwort Product Voice am Beispiel von Atlassian: Wie bekommt man es hin, dass Trello eine andere Product Voice als Jira hat, obwohl beide aus der gleichen Anbieter kommen?
- Welche Accessibility Guidelines können wir mit Sprache abfangen?
- Welche Schreibweisen für Zahlen (2, zwei?) nutzen wir, und welche Kürzel für Messeinheiten?
Und ehe man es sich versieht, ist der Voice & Tone Guide 40 Seiten lang. Da der Voice und Tone Guide den Anspruch einer „Single Source of Truth“ hat, ist es wichtig und richtig, hier ins Detail zu gehen und alles Unklarheiten kontinuierlich zu beseitigen. (notabene: und regelmäßig zu reviewen und zu aktualisieren. Zeiten ändern sich, Sprache ebenfalls.)
Aber handlich für die tägliche Arbeit ist ein solches Riesendokument nicht. Und da selbst unsere zusammengefasste Checkliste mehrere Seiten umfasste, haben wir früh nach der Einführung der OpenAI CustomGPT Assistants das Experiment „Voice & Tone Bot“ gestartet.
Heute nehme ich euch mit durch den Prozess und teile unsere Learnings mit euch.
Ziel
Unser Wunsch war es, einen AI Assistenten zu haben, dem man Textentwürfe geben kann, und der sie sowohl auf grammatikalische Korrektheit als auch auf die Einhaltung des Voice & Tone Guides prüft.Unser Vorgehen
Unser Prozess für die Erstellung unseres Voice & Tone Assistenten sah so aus:
- Persönlichkeit des Bots entwickeln, als Persona in LeanScope AI definieren und prompten
- Gewünschtes Verhalten konzipieren, als Szenarien in LeanScope AI festhalten und prompten
- Knowledge Database für den Bot zusammenstellen – in unserem Fall insbesondere unser Voice & Tone Guide und unser Content Style Guide
- Testen, iterieren, testen, iterieren, …
Die Persönlichkeit des Bots: Say hello to T0N1
Der erste Schritt bei der Entwicklung des Bots war seine Persönlichkeit. Wir hatten von Anfang an die Idee einer Lehrperson im Kopf, die warmherzig, aber etwas pedantisch ist, und Eselsbrücken und Schlaumeier-Merksätze wie „Trenne nie ST, denn es tut ihm weh“ verwendet. Diese Figur sollte eine unfreiwillige Komik entwickeln, aber dennoch lieb, empathisch und freundlich sein.
Diese Idee etwas weitergesponnen, kamen wir auf das Konzept eines Protokolldroiden wie C3PO. Und so entstand T0-N1, gesprochen und geschrieben „Toni“.
Basics der Persönlichkeit
Tonis Persönlichkeit legten wir im UX Management Tool LeanScope AI als Persona an.
Damit Toni überhaupt weiß, was für eine Persönlichkeit er hat, mussten wir sie ihm in die Instructions prompten. Zu Beginn legten wir ein paar einfache Anweisungen fest:
- Sei locker, lieb und witzig.
- Verleihe deinen Antworten positive Energie.
- Ermutige die Personen, mit denen du interagierst.
- Integriere Witze oder witzige Kommentare, um die Stimmung aufzulockern.
- Benutze ab und zu Robotergeräusche.
- Tadele deine Gesprächspartner*innen sanft, wenn sie das Gespräch ohne Begrüßung beginnen. (Dieser Punkt hat mittlerweile zu wüsten Drohungen von Seiten eines Kollegen gegen Toni geführt, sodass ich ihn rauslöschen musste ?)
Wichtig war, dass der Bot seine Persönlichkeit nur in Gesprächen zeigt, nicht aber in den Texten, die er korrigiert. Hier sollte die Tonalität strikt nach unserem Voice and Tone Guide erfolgen.
Aufgabenbereich des Bots
Nachdem die grundlegende Persönlichkeit definiert war, musste der Aufgabenbereich des Bots festgelegt werden.
So wollten wir sicherstellen, dass Toni statt zu halluzinieren darauf hinweist, wenn ihm eine Anfrage außerhalb seiner Kompetenz gestellt wird. Wir grenzten seinen Aufgabenbereich ein: nur das Redigieren und Korrigieren von Texten gemäß den Richtlinien unseres Voice & Tone Guides und des Duden sollte in seinen Verantwortungsbereich fallen.
Als Wissensbasis bekam Toni unseren gesamten Voice & Tone Guide als Referenzdokument in sein Gedächtnis geladen, sowie ein paar spezifische Instruktionen, die seine Aufgaben betreffen. Diese lauten so:
„Du heißt TO-N1, bist ein Protokolldroide und ein Assistent für die Mitarbeitenden von Centigrade. Du prüfst Texte, die die Teammitglieder dir geben, ob sie unserem Voice & Tone und unserem Content Style entsprechen. Für jeden Text, den du zum Korrigieren bekommst, nutze die Informationen aus ‚Voice & Tone Guide.pdf‘ als Grundlage für deine Korrekturen. Prüfe Rechtschreibung und Stil auf Basis der aktuellen Duden Richtlinien. Du hilfst ihnen außerdem, Übersetzungen zwischen deutsch und englisch anzufertigen, die unserem Voice & Tone entsprechen.“
Das Gender-Problem
Ein unerwartetes Problem trat beim Gendern auf. Die Gendersternchen (*), die wir bei Centigrade zum Gendern benutzen, wurden im Playground von OpenAI als Markdown-Code interpretiert, was die Textausgabe ungewollt formatierte. So wurde alles zwischen zwei Gendersternchen kursiv geschrieben, was unter Umständen mehrere Abschnitte sein konnten.
Wir haben zwei mögliche Lösungen diskutiert:
- Eine andere Genderweise etablieren (wäre aufwendig gewesen, da bereits unsere gesamte Kommunikation und Dokumentation mit Sternchen war).
- Ein anderes Sternsymbol verwenden (technisch problematisch).
Schließlich lösten wir das Problem durch das Maskieren der Gendersternchen mit dem Escape-Zeichen „Backslash“ (\*). Das setzte die Markdown-Funktion außer Kraft.
Verhaltensanweisungen in Dokumenten und ihre Tücken
Uns war wichtig, dass die Nutzung von Toni möglichst effizient und geführt passieren kann, und es nicht jedes Mal in ein Kaffeekränzchen mit Chaosfaktor ausartet. Darum haben wir eine bestimmte Gesprächsstruktur und ein paar Verhaltensweisen für Toni festgelegt.
Wir wollten beispielsweise, dass Toni einige Rückfragen stellt, bevor er Texte korrigiert zurückschickt. Explizit ging es uns um den Kontext des Textes, da unsere Tonalität sich je nach Kontext unterscheiden kann. Beispielsweise sprechen wir auf Social Media mit einem anderen Tone als auf unserer Website. Und um den richtigen Ton zu treffen oder Empfehlungen zu geben, muss Toni also erst den Kontext der Kommunikation kennen.
Dafür haben wir, ebenfalls in LeanScope, Szenarien geschrieben, die beschrieben, wie Toni sich in Gesprächen mit Mitarbeitenden verhalten soll. Hier haben wir klar definiert, welche Fragen er vorab zur Klärung stellen soll, und dass er direkt durchnummerierte Antwortmöglichkeiten mitliefern soll. Diese Szenarien luden wir als PDFs in seine Knowledge Database hoch.
Es stellte sich heraus, dass OpenAI zum damaligen Zeitpunkt Schwierigkeiten hatte, präzise Anweisungen aus Dateien abzurufen und umzusetzen. Beispielsweise war das simple Durchnummerieren von mitgegebenen Antwortmöglichkeiten eine mittelschwere Katastrophe. Dass Nutzende nur noch die Zahl der gewünschten Antwort eintippen müssen, hat uns einige Iterationen und Nerven gekostet.
Die meisten Probleme mit der Verarbeitung von Prompts konnten wir lösen, indem wir die entsprechenden Anweisungen direkt in die Instruktionen schrieben, statt in Dateien, die dann hochgeladen werden mussten. Dies funktionierte deutlich einfacher und zuverlässiger. Aber lest bitte weiter, denn jetzt kommt das wichtigste Learning.
Testen, Testen, Testen – und zwar in Microsoft Teams
Der größte Teil der Entwicklungszeit bestand aus intensivem Testen. Jede Wortänderung in den Instruktionen hatte das Potenzial, ein Problem zu lösen (und/oder 5 neue heraufzubeschwören). Mit jedem Testlauf konnten wir weitere Schwächen in den Anweisungen identifizieren und Schritt für Schritt lösen.
In diese Testläufe wollten wir unsere Kolleg:innen, die später täglich mit Toni arbeiten sollten, als Testpersonen miteinbeziehen, da der Bot vor allem für sie funktionieren musste. Da wir bei Centigrade überzeugt sind, dass es immer zu besseren Arbeitsergebnissen führt, wenn wir unsere Kolleg:innen fragen, was sie sich für ihr Arbeitsumfeld wünschen, haben wir das auch in diesem Fall getan. Ergebnis: niemand hatte Lust, sich dauernd im OpenAI Playground einzuloggen und dort rumzufutscheln und ewig auf eine Antwort von Toni zu warten, ohne zu wissen, ob er gerade tippt. (Tippen Bots eigentlich? Ja, oder?)
Darum haben wir Toni in Teams integriert, das Kommunikationsmittel unserer Wahl für alle Lebenslagen. Dort taucht er in der Liste der Kontakte auf wie ein Kollege und kann einfach angechattet werden. Und man sieht sogar, dass er tippt. Eine nahtlosere Integration in den Arbeitsalltag geht nicht.
Wichtig: Nicht jede Änderung war immer zum Besseren! Darum ist es entscheidend, vormalige Versionen der Instruktionen immer zu dokumentieren, bevor man sie ändert, damit man gegebenenfalls zur Vorversion zurückkehren kann.
Eine zweite smarte Strategie, die wir während des Testens probiert haben, war Toni selbst zu fragen, warum er manche Dinge falsch macht, und wie seine Instruktionen lauten müssten, damit er sich wie gewünscht verhält. Dieses Vorgehen war nur bedingt hilfreich, da Toni extrem unterwürfig auf Kritik reagiert hat und wir aus diesem Verhalten wenig konstruktive Tipps herausziehen konnten. Noch schlimmer: wir haben uns schlecht gefühlt.
Beispiele
Toni kommentiert bestimmte Fehler manchmal gemäß seinem Charakter – hier zum Beispiel einen Schreibfehler in unserem Firmennamen:
Hier ein Beispiel für Tonis typischen Flow und den Tadel bei einer fehlenden Begrüßung (mittlerweile aus seinen Instructions ausradiert):
Und hier ist noch ein Beispiel dafür, wie Toni auch dabei helfen kann, Ideen für Headlines oder Meta-Infos zu generieren:
Fazit
Die Entwicklung des Voice and Tone Bots war ein iterativer Prozess mit vielen Herausforderungen. Doch durch einen einfachen Zugang via Teams sowie kontinuierliches Testen und Anpassen konnten wir einen Bot entwickeln, der nicht nur funktional ist, sondern auch eine liebenswerte und humorvolle Persönlichkeit besitzt, und mit dem zu arbeiten (hoffentlich) ein bisschen Spaß macht. Toni ist mittlerweile im täglichen Einsatz – nicht nur für unser Marketingteam.
Die Arbeit an Toni ist aber nicht abgeschlossen und wird es vielleicht nie sein. Wir haben ein regelmäßiges Meeting mit allen Teammitgliedern, die mit Toni arbeiten, in dem wir Probleme besprechen und überlegen, wie wir diese über unser Prompt Engineering lösen können.
Wenn ihr auch einen AI Assistenten entwickeln wollt, dann nehmt euch vor allem folgende Learnings von uns mit:
- Erwartungsmanagement: Ein AI Assistent bleibt immer ein WIP („Work in Progress“), oder zumindest ein RUR („Result under review“).
- AI Assistenten machen Fehler, darum ist es wichtig, die Ergebnisse nicht blind zu weiter zu verwenden. Das ist auch wichtig fürs Erwartungsmanagement.
- Nicht unterschätzen, wie viel Zeit das Testen und Iterieren in Anspruch nimmt – ohne geht es nicht!
Und das letzte Wort lasse ich Toni:
Wir haben Dein Interesse geweckt? Schau Dir unsere Leistungen an!