Die Welt ist voller Brillenträger und es gibt sehr viele unterschiedliche Brillen. Viele davon tragen wir auf der Nase. Es gibt aber noch andere Brillen, die nicht direkt auf die Nase gesetzt werden, sondern eher in unseren Köpfen verankert sind.
Bedienoberflächen sind ein Beispiel dafür, dass sowohl Entwickler als auch Anwender jeweils Brillen tragen.
Der Entwickler einer Maschine sieht deren Bedienoberfläche mit seiner Brille funktionsbezogen. Er sieht, welchen Prozess eine Schaltfläche auslöst, und er kennt das Ergebnis des Prozesses. Wenn der Entwickler also eine Schaltfläche „Sperrbolzen 2 auf Endposition“ nennt, liest sich das mit seiner Brille sehr gefällig. Es spiegelt eben genau die Funktion wider, die er bis ins Detail kennt. Der Entwickler weiß, dass man mit dieser Funktion eine Tür verriegelt.
Die Brille des Anwenders ist eher aufgabenbezogen „getönt“. Er sieht dem Produkt nicht unbedingt an, dass es einen Sperrbolzen hat, und weiß wahrscheinlich nicht, was es mit der Endposition von Sperrbolzen 2 auf sich hat. Der Nutzer will vielleicht einfach eine Tür abschließen. Seine Brille erwartet eine Schaltfläche mit einem Text, der für ihn der Lösung seiner Aufgabe entspricht. Vielleicht drückt er dazu tatsächlich die Schaltfläche „Sperrbolzen 2 auf Endposition“. Vielleicht tut er das, ohne in der Betriebsanleitung nachzulesen, weil er vermutet, dass ein Sperrbolzen etwas mit Verriegeln zu tun hat. Im besten Fall landet er einen Zufallstreffer, in ungünstigen Fällen verursacht er einen Sachschaden oder jemand wird verletzt. Wahrscheinlich liest er nach dem Drücken etwas wie „Sperrbolzen 2 Endposition OK“, runzelt die Stirn und weiß nicht, ob er die Tür nun wirklich verriegelt hat.
Wenn der Anwender in der Betriebsanleitung Hilfestellung sucht, hat er allenfalls zusätzlich eine Lesebrille auf. Die hilft ihm aber wenig, wenn auch die Betriebsanleitung von Entwicklern geschrieben wurde, die in erster Linie technisches Detailwissen verewigt haben. Vielleicht findet der Anwender Inhalte zu Sperrfunktionen, Prozessabläufen und Maschinenzuständen. Möglicherweise werden zur Bezeichnung der Schaltflächen dieselben Begriffe verwendet, die auf der Bedienoberfläche dargestellt werden. Wahrscheinlich gibt es Abweichungen, weil irgendwann mal ein Schließriegel statt eines Sperrbolzens verwendet wurde. Die Betriebsanleitung konnte seitdem vielleicht nicht mehr überarbeitet werden, weil der Entwickler seiner Hauptaufgabe nachgehen musste. Der Anwender liest also in der Betriebsanleitung einen Satz wie „Drücken Sie die Schaltfläche Schließriegel 2 auf Endposition, um die Sperrfunktion von Zulaufklappe 1 zu aktivieren“. Nicht nur, dass der Anwender nicht versteht, wie er mit dem Produkt umgehen soll. Er scheitert auch an der Rückmeldung des Produkts und die eigentliche Hilfestellung der Betriebsanleitung führt nur zu noch mehr Verwirrung. Hohe Qualität wird anders wahrgenommen. Spätestens an diesem Punkt will der Anwender die Sonnenbrille aufsetzen und Feierabend machen.
Produkte, die die Anforderungen und Erwartungen des Anwenders nicht berücksichtigen, geraten heute schnell ins Abseits. Wie aber kann man diese Anforderung erfüllen und komplexe Produkte und Bedienungen einfach und verständlich machen? Wie erzeugt man „Usability“ und „Smart Information“?
Hier kommt die Technische Redaktion ins Spiel. Ich habe als Technischer Redakteur ein Bewusstsein dafür entwickelt, dass es Brillen gibt, und mir eine Reihe davon zugelegt. So kann ich im Projektalltag die Brille des Entwicklers aufsetzen, um Funktionen zu verstehen. Das ist für mich die wichtigste Voraussetzung, um zu wissen, wovon ich schreibe. Bei der redaktionellen Tätigkeit wechsle ich zur Brille des Nutzers, denn ich will die Inhalte ja so aufbereiten, dass dieser sie leicht verstehen kann.
Da liegt es nahe, auch bei der Gestaltung von Bedienoberflächen mitzuwirken. Dazu analysiere ich z. B. die wesentlichen Eigenschaften des Anwenders, seine Zielsetzungen und Aufgaben. Dadurch kann ich helfen, Oberflächen zu gestalten, die Bedienfehler vermeiden und intuitiv bedienbar sind. Indem die Redaktion auch Usability-Aspekte berücksichtigt, können zielgruppengerechte Benennungen (Terminologien) der Bedienoberfläche nach einem vordefinierten Konzept aufgebaut werden. So richtig spannend wird es dann noch, wenn Redaktionssystem und Programmierumgebung miteinander verknüpft sind, sodass die Softwaretexte aus einer Quelle kommen und somit die Benennungen in Dokumentation und Produktoberfläche immer konsequent gleich sind.
So wird der Erstellprozess effizienter und der Nutzer findet sich viel besser zurecht – eine Win-win-Situation, die allen dient. Übrigens: Die Schaltfläche heißt jetzt "Tür verriegeln".
