Zum Inhalt springen

Kategorie: Redaktion



Bedienungsanleitungen im Wandel der Zeit

Die Bedienungsanleitung für den Mercedes Typ 170 Da aus dem Jahr 1950 hatte 44 Seiten. Das ist heute kaum vorstellbar. Anleitungen verändern sich und zwar nicht nur, weil Produkte sich verändern. Auch die Benutzer und ihr Umgang mit Medien und Informationen tragen dazu bei.

Die Frage, ob Bedienungsanleitungen bzw. Anwenderdokumentationen, wie wir sie heute kennen, noch zeitgemäß sind, ist daher berechtigt. Sind sie für den Benutzer noch die erste Wahl, wenn er bei der Bedienung eines Programms, eines Geräts oder einer Maschine Hilfe braucht? Oder sucht er sich über andere Kanäle und Medien Informationen? Welcher Redakteur oder Mitarbeiter im technischen Support hat noch nicht die Erfahrung gemacht, dass ein Benutzer eine Frage stellt, obwohl es in der Bedienungsanleitung bzw. in der Anwenderdokumentation eines Softwareproduktes ganz klar eine Antwort darauf gibt? Ist es wirklich so, dass der Benutzer zu faul zum Lesen ist? Solche Situationen haben eher damit zu tun, dass Benutzer in der Regel Anleitungen nicht wie Romane von der ersten bis zur letzten Seite durchlesen, sondern meistens unter Zeitdruck die Antwort auf eine bestimmte Frage suchen. Wenn sie sie nicht gleich finden, geben sie relativ schnell auf.

Für den Benutzer ist dann diese Erfahrung negativ behaftet. Für das Unternehmen sind Rückfragen mit einem zusätzlichen Aufwand verbunden. Das ist Grund genug, sich Gedanken darüber zu machen, warum solche Situationen entstehen und wie man dem Benutzer besser helfen kann.

In den letzten Jahren hat sich hinsichtlich Informationsvermittlung bereits viel getan. Mit DITA (Akronym für Darwin Information Typing Architecture), das im Jahr 2005 als OASIS-Standard verabschiedet wurde, wurde die Dokumentation in Topics strukturiert. Ein Topic sollte wiederverwendbar sein und eine Informationseinheit darstellen, die ein einzelnes Thema knapp abhandelt. Ein ähnliches Prinzip kommt bei der Organisation vieler Onlinehilfen für Softwareprodukte zum Einsatz. Bei Benutzerinformationen geht der Trend in Richtung knapper Informationseinheiten, die für sich stehen und eine konkrete Fragestellung klären. Je nach System, Informationsziel und Hardware haben die dargebotenen Informationen unterschiedliche Größen und Eigenschaften, aber auch gemeinsame Merkmale wie die knappe Größe und den Fokus auf eine eigenständige Fragestellung. In diesem Sinne verabschiedete im April dieses Jahres eine Fachgruppe der Tekom den iiRDS-Standard, ein Format für den Austausch intelligenter Informationen zwischen verschiedenen Systemanbietern.

Somit verändert sich langsam die Beschaffenheit der Inhalte für die Benutzer. Einerseits merkt man dies an den Veränderungen in den Bedienungsanleitungen selbst, andererseits entstehen parallel zu den Anleitungen neue Inhaltsformen und Medien, die verstärkt Aufgaben übernehmen, die bisher den Bedienungsanleitungen vorbehalten waren.

Was sind die Besonderheiten dieser neuen Informationselemente? Sie betreffen im Wesentlichen folgende drei Punkte:

  1. Größe, Inhalt und Struktur der Informationseinheiten.
  2. Sprache der Informationseinheiten.
  3. Formate, Endformate und Metadaten.

Redakteure erstellen häppchenweise Inhalte (zum Beispiel Topics), die in der Regel eine einzige Frage knapp beantworten. Bei dieser Frage kann es darum gehen, wie ein bestimmtes Ergebnis erreicht werden kann ("Wie stelle ich den Druck des Verdampfers ein?"). Es kann auch eine allgemeine Information sein ("Was ist das Funktionsprinzip des Drucksensors?"). Oder auch eine allgemeine Beschreibung ("Mit diesem Programm, können Sie folgende Aufgaben lösen …"). Wichtig ist, dass jede Informationseinheit als Ganzes steht und in sich schlüssig ist. Wie umfangreich der Inhalt ist, hängt von der Art der Informationsvermittlung und vom verwendeten Medium ab. Ein Topic in einer Onlinehilfe bietet mehr Flexibilität als die knappe Rückmeldung eines ServiceBots oder ein Text auf einem Smartphone. Auch kann das Informationselement nur ein Textfragment von einigen Zeilen sein. Nützlich ist, wenn der Benutzer eine Orientierungshilfe darüber erhält, wie diese Einheiten zusammenhängen und welche Alternativwege ihm für die Lösung seines Problems bzw. für die Beantwortung seiner Frage zur Verfügung stehen.

Sprachlich müssen sich die Inhalte nicht zwangsläufig wesentlich vom Stil einer Bedienungsanleitung unterscheiden. Bei Mensch- Maschine-Schnittstellen (Human-Maschinen- Interfaces - HMI) bzw. Bots (ChatBots, ServiceBots) ist die Sprache allerdings deutlich knapper und standardisierter. Sehr kurze Sätze, Verzicht auf Füllwörter und normierte Fachterminologie sind die Haupteigenschaften. Im Dialog mit dem Benutzer ist es jedoch sehr wichtig, dass seine Sprache verstanden wird. Hier hilft eine deskriptive Terminologie, die möglichst viele Synonyme zu der Fachterminologie eines Unternehmens sammelt und erfasst. So können Brücken zwischen der Sprache des Benutzers und der Firmensprache gebaut werden (Tempomat für Geschwindigkeitsregelanlage).

Für den Übersetzer kann die Übersetzung von autonomen Informationseinheiten bedeuten, dass er nicht immer unbesehen Inhalte aus Translation-Memorys wiederverwenden kann, die u.U. für eine andere Situation erstellt wurden. Bezugswörter ("Ersetzen Sie es mit einem neuen") oder bestimmte Fachwörter wie "Behälter" (Was für ein Inhalt?), "Speicherplatz" (Ort oder Größe?) weisen eventuell auf einen anderen Kontext hin. Bei der Lokalisierung von ChatBot-Inhalten kann sogar das sprachliche Wissen von Übersetzern von großem Nutzen sein, denn jede Sprache kennt unterschiedliche Möglichkeiten, eine Frage zu stellen ("Wie schalte ich das Display aus?", "Wo ist der Ausschaltknopf für den Bildschirm?", usw.).

Heutzutage basieren die meisten Formate auf XML. Diese Formate eignen sich für die Erzeugung von Informationen für eine Vielfalt von Geräten, vom Bedienterminal über mobile Geräte bis hin zur Datenbrille.

XML bietet den Vorteil, zusätzlich zum sichtbaren Text, semantische Auszeichnungen (über die Bedeutung von Inhalten) und Metadaten zu erfassen. Diese Daten erleichtern die Suche nach bestimmten Informationstypen, etwa nach einer Prozedur, nach einer alternativen Benennung, nach einer Teilenummer, um nur einige zu nennen. Somit ist es unter anderem möglich, gezielt eine Information zu liefern, auch wenn unterschiedliche Benutzer mit unterschiedlichen Formulierungen nach dieser Information suchen.

Noch prägt die traditionelle Dokumentation die Arbeit von Redakteuren und Übersetzern. Aber mit der Verbreitung neuer Medien und Technologien wie Mensch-Maschine-Schnittstellen und ChatBots entstehen neue Formen der Informationserstellung und –übersetzung, die die Arbeit von Redakteuren und Übersetzern beeinflussen. Umso wichtiger werden auch in diesem Zusammenhang die Terminologiearbeit und die Qualitätssicherungsverfahren, denn trotz Verteilung der Informationen auf viele Einheiten und Medien braucht man dieselben standardisierten Inhalte.

Projekttagebuch

Für viele Profi-Sportler ist es Routine: Sie führen ein Tagebuch und tragen dort ihre Trainingsdaten ein wie Tagesform, erbrachte Leistung oder Beschwerden. Beim Projektmanagement von Übersetzungen ist ein Tagebuch allerdings weniger verbreitet, obwohl es sich als sehr nützliches Instrument für eine erfolgreiche Projektarbeit erweisen kann.

Größere Übersetzungsprojekte mit einer Vielzahl von Dateien und Sprachen können sich als sehr komplex und fehleranfällig erweisen. Nicht selten muss der Projektmanager über mehrere Wochen viele Prozessschritte und Hunderte von Bearbeitungszuständen überwachen, mit mehreren Übersetzern, technischen Fachleuten oder Auftraggebern kommunizieren. Das Projektwissen ist auf viele Köpfe verteilt.

Zwar gibt es am Markt eigenständige bzw. in Translation-Memory-Systemen integrierte Verwaltungsprogramme für Projekte, aber nur wenige liefern die Instrumente für ein systematisches Erfassen des Projektlebens. Daher bietet sich das Führen eines elektronischen Projekttagebuchs als nützliche Ergänzung zu den gängigen Mitteln des Projektmanagements an. So lässt sich mit einem Blick feststellen, was im Verlauf des Projekts geschehen ist. Das ist z. B. praktisch, wenn ein Mitarbeiter nach seinem Urlaub zurückkommt und das Projekt weiterführt bzw. wenn am Ende des Projektes nach möglichen Fehlerursachen gesucht wird.

Aber wie soll ein solches Projekttagebuch aussehen? Welche Informationen gehören dazu? Das Wichtigste ist zuerst einmal, dass der Projektmanager alle Projektereignisse chronologisch (mit Datum und möglichst auch mit Uhrzeit) erfasst. Falls mehrere Personen das Tagebuch führen, muss auf jeden Fall der Name des Verfassers auch mitprotokolliert werden.

Erfasst werden unterschiedliche Ereignisse wie Beauftragung, wichtige Mails, bestimmte Aktionen (wie Dateneingang oder Lieferung), Meetings (und Beschlüsse), Kommunikation oder Vereinbarungen. Am besten ist es, wenn bereits von Anfang an mit typischen Informationskategorien gearbeitet wird, sodass bei Bedarf eine gezielte Informationssuche anhand dieser Kategorien (z. B. über eine Filterfunktion von Excel) erfolgen kann. Beispiel: "Gibt es in der Kategorie ‚ToDo‘ eine Aufgabe, die den Status ‚offen‘ hat?". Da in der Regel Projekte nicht einmalig sind, macht es Sinn, diese Kategorien zu standardisieren. Beispiele für solche Kategorien sind: "Kommunikation mit Kunden, Kommunikation mit Lieferanten, Verarbeitungsschritt, Kosten, Anweisung/Vereinbarung, ToDo".

Von besonderer Bedeutung sind Informationen, die im Projektverlauf Gegenstand von Diskussionen sein könnten. Es geht u. a. um Anweisungen, die der Auftraggeber dem Dienstleister oder der Projektmanager dem Übersetzer erst zu einem späteren Zeitpunkt erteilt, wenn das Projekt bereits angelaufen ist. So kann es z. B. sein, dass eine Anweisung zur Terminologie erst nach der Lieferung eines Projektteils erfolgte und diese Information ohne Projekttagebucheintrag einige Wochen später nicht mehr zu rekonstruieren ist. Die Verwunderung ist dann groß, wenn Vorgaben in der Übersetzung nicht umgesetzt wurden.

Beim Protokollieren von Aktionen, die von Problemen unterschiedlicher Natur (technisch, sprachlich oder organisatorisch) begleitet werden, ist es im Sinne künftiger Verbesserungsmaßnahmen wichtig, diese Probleme genau zu beschreiben und zu dokumentieren und dabei die möglichen Ursachen zu nennen. Es geht um Fragen Wer, Was, Wie, Womit und mit Welchem Ergebnis umgesetzt hat. Beispiel: "Bei der Projektvorbereitung hat der EDV-Mitarbeiter in der Datei ABC.XLIFF einige Sätze falsch segmentiert. Es hat sich herausgestellt, dass der Text unbekannte Abkürzungen enthielt, die das Übersetzungssystem als Satzende interpretiert hat."

Auch das Erfassen etwaiger Abweichungen zwischen Plan und Ergebnis kann nützlich sein, etwa: "Die französische Qualitätssicherung des Magazintextes durch XY hat 3 Stunden länger gedauert. Die vorgegebenen Artikelbezeichnungen stimmten nicht immer mit der Terminologie überein und mussten geklärt werden."

Nach Abschluss eines Projektes bildet das Projekttagebuch eine wichtige Grundlage für Abschlussbesprechungen, bei denen es darum geht, die Organisation und die Durchführung des Projekts zu bewerten. Daraus lassen sich Lösungsideen und Verbesserungen für künftige Projekte ziehen. Auch können Tagebucheinträge Informationen über Aktionen enthalten, die noch durchzuführen sind, wie z. B. das nachträgliche Korrigieren der Terminologie in einem Translation-Memory.

Im Falle von Meinungsunterschieden zwischen Projektteilnehmern (Übersetzungsdienstleister, Übersetzer oder Auftraggeber) helfen die Informationen aus dem Projekttagebuch, die Diskussion zu versachlichen und Ursachen zu identifizieren. Auch können sie im Falle von nicht selbst verschuldetem Mehraufwand die Forderungen eines Projektteilnehmers untermauern.

Ideal wäre es, wenn die gängigen Projektmanagement-Programme, ob eigenständig oder in Übersetzungsumgebungen integriert, eine Tagebuchfunktion anböten. Zwar lässt sich vieles durch Nachforschen und Sichten von Notizen und Korrespondenz rekonstruieren, aber das ersetzt die Möglichkeiten nicht, die ein Tagebuch bietet.

Obwohl das Führen eines Tagebuchs mit einem gewissen Aufwand verbunden ist, gehört es zu den Best-Practices des Projektmanagements. Es ist ein wichtiges Instrument zur Projektsteuerung und für die kontinuierliche Verbesserung von Unternehmensprozessen.

  • 1