Hauptkompetenz: Liebevoll mit den Entwicklern «chifle»

In unserem Artikel «UX-Writing. Wer, was und vor allem, warum?» haben wir bereits beschrieben, welche Kompetenzen das UX-Writing erfordert und wie die Aufgabe dieses Felds aussieht. Ein Beispiel für Anwendungsfälle von UX-Writing-Prozessen, wie sie konkret aussehen können und wie die Technische Redaktion darin eingebunden werden kann, möchte ich anhand eines konkreten Kundenprojekts erläutern, das ich nun schon fast ein Jahr lang begleiten darf.

Mein erstes und bisheriges Hauptprojekt als UX-Writerin war eine Art sanfter Einstieg in die Arbeit. Ich begleitete die Entwicklung einer internen Software für den Geräteservice. «Hmm, aber für interne Software lohnt sich doch der Aufwand für eine UX-Optimierung kaum», mag hier jetzt ein Gedanke sein. Im Falle meines Kunden kam die Entscheidung auch erst nach einer schmerzlichen Erfahrung. Der Vorgänger der neuen Software hatte vielen Servicetechnikern Kopfschmerzen und verschwendete Zeit beschert. Besonders in Ländern, in deren Landessprachen das Programm nicht übersetzt worden war, passierten Fehler aufgrund kompliziert formulierter englischer Anleitungen sowie unnötiger Prozessschlaufen. Das Geld, das bei der UX gespart worden war, ging also beim Support wieder verloren. Deshalb wurde bei der Neuaufsetzung neben einer simpleren Architektur auch auf einen UX-Writer aus der Technischen Doku (also mich) gesetzt. Für dieses Projekt konzentrierte ich mich rein auf die GUI-Texte, die ich auf sprachliche Korrektheit, Verständlichkeit und Usability überprüfte.

Vorteile von UX-Writing

Damit gab aber auch bei diesem vergleichsweise überschaubaren Programm schon genug zu tun, denn durch die Tatsache, dass ein meist mehrköpfiges Team von Entwicklerinnen und Entwicklern an einer Software arbeitet, ergeben sich schnell Inkonsistenzen und im schlimmsten Fall beinahe gegensätzliche Formulierungen. Zusätzlich erschwert wird das Ganze, wenn die Texte auf Englisch verfasst werden, diese Sprache jedoch für die allermeisten Beteiligten eine Fremdsprache ist.

Zu meinem Glück ist das Reviewen von GUI-Texten bei dem betreffenden Kunden keine brandneue Idee mehr, von der man das Research & Development noch umständlich hätte überzeugen müssen. Vielmehr wurden UX- und Reviewprozesse schon vor ein paar Jahren in die Entwicklungsarbeit integriert und werden von den Projektleitenden und dem Produktmanagement geschätzt, da sie eine eindeutige Qualitätserhöhung und damit bessere Verkäuflichkeit der Produkte darstellen.

Ganz grundsätzlich sieht der Ablauf folgendermassen aus:

Entwickler verfassen GUI Texte ⇒ UX Writer parst Texte in Lokalisierungstool ⇒ UX Writer prüft Texte ⇒ UX Writer veranlasst Übersetzungen

In agilen Projekten ist dies aber natürlich kein starrer, einmaliger Prozess, sondern iterativ und fortwährend. So parse ich während der gesamten Entwicklungszeit immer die neuesten Texte aus dem Repository und kläre fortwährend eine Menge Dinge ab. Auch die Übersetzung veranlassen wir gestaffelt, damit zwischen den einzelnen Übersetzungen mögliche Schwachstellen ausgebügelt werden können.

Prozessbegleitendes Arbeiten

Bei meinem nächsten Projekt geht es um die Bediensoftware für die prestigeträchtigste (und demzufolge teuerste) Gerätelinie der Division, bei der das UI natürlich nicht nur mit der hohen Qualität der Hardware mithalten muss, sondern auch ein eigenes Verkaufsargument darstellt. Bei diesem Projekt steige ich sozusagen ein Level auf, denn ich werde bereits bei der Erstellung der Mockups (also der digitalen Entwürfe) einbezogen. Ich werde mich also in Zukunft regelmässig mit den Kolleginnen und Kollegen vom GUI-Design um auf den ersten Blick triviale, aber in der Anwendung wichtige Details in den Bedienungstexten und der Architektur (liebevoll) streiten (oder «chifle», wie das hier in der Schweiz auch heisst).

Punkte, die bei beiden Projekten sehr wichtig sind, sind etwa die folgenden:

• Sprachliche Korrektheit
• Einhaltung der Terminologie (und der Vorgaben der Unternehmenskommunikation)
• Berücksichtigung der Zielgruppe
• Verständlichkeit und Einfachheit der Texte
• Optimierung der Usability
• Optimierung der Texte für die Übersetzung

Unschwer zu erkennen: Für Technische Redakteure sind das alles Themen, die wir im Blut haben und im Redaktionsalltag bereits anwenden. Mit dem Wissen, das wir in der Dokumentation bereits umsetzen, können wir auch in die Software eingebettete Bedienungsanleitungen und -hinweise benutzerfreundlicher gestalten und damit das Benutzererlebnis deutlich verbessern. Zunutze kommt uns natürlich auch, dass wir es gewohnt sind, Informationen über sieben Ecken zusammenzutragen.

Die praktische Seite

Die Tools für eine reibungslose Integration des UX-Writings sind bereits vorhanden. Für meinen Kunden arbeite ich zum Beispiel mit SDL Passolo, mit dem die GUI-Quelltexte aus dem Repository wie in einem CAT-Tool verwaltet werden können (so kann auch die Einheitlichkeit der Texte über mehrere Projekte hinweg sichergestellt werden). Nur die Zieltexte müssen in einem einmaligen Prozess im Code eingebunden werden. Um die Texte auch auf Usability prüfen zu können, werden mir die Demoversionen des Programms auf meinem Rechner verfügbar gemacht und ich kann jeweils den aktuellen Build abrufen. Und für den Fall, dass ich trotzdem mal nicht weiterkomme und nicht weiss, wo genau ein Text verwendet wird, arbeite ich eng mit den Entwicklern (die praktischerweise direkt übern Flur sitzen) zusammen. So habe ich die Erfahrung gemacht, dass die Leute von der Entwicklung da recht entspannt sind und sich gerne die Zeit nehmen, kurz etwas zusammen anzuschauen. Bei einer Tasse Kaffee diskutieren sie auch mal lang und breit über Terminologie mit mir.

Die Arbeit macht mir grossen Spass und ist bisher für alle Beteiligten sehr lehrreich. Auch für die Produkte ist dieser am Anfang vielleicht als Umweg wahrgenommene Prozess nur gewinnbringend. Denn auch bei Software gilt: Was nicht verstanden wird, wird nicht befolgt.