Fallstricke bei der Standardisierung von technischem Content

Fallstricke bei der Standardisiserung von technischem Content

Ohne Standardisierung – da werden Sie mir sicher zustimmen – ist moderne Technische Redaktion nicht machbar. Ein Handbuch oder eine mobile Dokumentation, in dem jeder Warnhinweis anderen Regeln folgt, in dem man Handlungsschritte nicht von beschreibenden Informationen unterscheiden kann oder die verwendete Terminologie nach Kraut und Rüben anmutet – das will keiner.

Und das nicht hauptsächlich deswegen, weil so ein Durcheinander irgendwie nicht „schön“ wäre. Es geht vielmehr darum, dass nur eine nachhaltige Standardisierung das empfindliche Gleichgewicht herstellen kann zwischen den heutigen Anforderungen an Technischen Content:

  • redaktionelle Qualität
    (Stichworte Nutzbarkeit, Verständlichkeit, User Experience, Rechtssicherheit)
  • effiziente Datenhaltung und -verarbeitung
    (Stichworte Content-Maintenance, Wiederverwendbarkeit, Übersetzbarkeit, Kosteneffizienz)
  • und die universelle Verwendbarkeit des Contents
    (Stichworte Medienneutralität, mobile Dokumentation, Content Delivery, Content Integration).

Also nochmals die Frage: Braucht es Standardisierung? – Natürlich!

Gerade weil der Bedarf so hoch ist und an einer gelungenen Standardisierung so viel hängt, empfiehlt es sich, beim Standardisieren mit Bedacht vorzugehen. Denn schlimmer als keine Standardisierung ist eine misslungene.

Darum will ich im Blogpost heute drei Fallstricke ins Visier nehmen, die ich für besonders gefährlich halte.

Falle 1: Die Technik wird’s schon richten

Ich erinnere mich noch gut an das Entsetzen eines Kollegen in einem Projekt, wo es eigentlich „nur“ darum ging, DITA-XML in die ebenfalls XML-basierte Datenbank eines modernen Redaktionssystems zu migrieren. Technisch gesehen war der DITA-Code einwandfrei, die Inhalte waren aber vollkommen unsemantisch erfasst. So hatten zum Beispiel besonders findige Redakteure bestimmte XML-Tags anstatt zum Strukturieren von Inhalten zum Layouten verwendet – weil sich damit Grafiken so hübsch positionieren ließen.

Ein Datenbestand – verwaltet auf Basis eines internationalen Standards, und trotzdem durchgehend korrupt und eigentlich kaputt. Es waren massive manuelle Eingriffe notwendig und einiges an Entwicklerintelligenz, um dieses Projekt schließlich zum Erfolg zu bringen.

Was dieses Beispiel deutlich zeigt: Begreift man Standardisierung als rein technische Herausforderung, greift man zu kurz. Hier hat ein durchdachtes Content-Konzept gefehlt und ein Redaktionsleitfaden, der dieses Konzept zuverlässig in die Arbeitswelt der Redakteure transportiert.

Falle 2: Genauigkeit an der falschen Stelle

Standardisierung kann allerdings auch fehlschlagen, wenn man einem ausgearbeiteten Content-Konzept folgt, das falsche Schwerpunkte setzt. Vor Augen habe ich bei meinem zweiten Beispiel die Anleitungen eines Industrieunternehmens, die gerade erst auf Basis einer bekannten Strukturierungsmethode für Technische Kommunikation komplett umgearbeitet worden waren.

Das ist bestimmt kein Fehler. Nimmt man eine dieser Anleitungen zur Hand, kann man zum Beispiel jedem Warnhinweis und jeder Handlungsanweisung attestieren, dass sie einem strikten Standard folgen. Auch das ist eine gute Sache.

Die Genauigkeit im Detail – und hier liegt das Problem des dahinterliegenden Content-Konzepts ­– sorgt aber nicht automatisch für gut anwendbare Dokumente. Gut zu sehen ist das am Beispiel der Warnhinweise: Jeder Warnhinweis für sich ist 100 Prozent konsistent. Nur wird der Leser an vielen Stellen der Anleitungen mit ganzen Kaskaden aus drei, vier und mehr aufeinanderfolgenden Warnhinweisen überfrachtet.

Das Ende vom Lied: Die im Detail sauberst aufgesetzten Inhalte funktionieren nicht als Dokument und überfordern die Leser. Der grundlegende Zweck, dass die Anleitungen die sichere Anwendung der Produkte gewährleisten sollen, wird durch diesen Standard am Ende sogar konterkariert. Mit trauriger Konsequenz.

Dieses Beispiel ist leider kein Einzelfall. Immer wieder begegnen wir in der Beratung Standardisierungs-Ansätzen, die die Konsumenten der Informationen mit ihren zielgruppenspezifischen Informationsbedürfnissen einfach unbeachtet lassen. Und so entsteht trotz Standardisierung systematischer Murks.

Falle 3: Standardisierung vorbei an denen, die die Standards einhalten sollen

Das Stichwort „Zielgruppen“ eignet sich sehr gut als Übergang zum letzten Fallstrick. Wenn man Zielgruppen in Zusammenhang mit Standardisierung nennt, meint man meist wie ich gerade in meinem zweiten Beispiel die Konsumenten oder Leser von Informationen und Dokumenten. Aber es gibt im Umfeld der Standardisierung noch eine weitere Zielgruppe: Die Leute, die für die Erstellung des Contents zuständig sind und die sorgfältig definierten Standards anwenden sollen.

Was passiert, wenn Verfasser und Standards nicht zusammenpassen? Richtig: Die Standards bleiben auf der Strecke, die Verfasser sind frustriert, weil ihnen Unwilligkeit oder Nachlässigkeit unterstellt wird. Was als Standard gut gemeint ist, entwickelt sich zu einem echten Hemmschuh und Konfliktthema.

Dieses Dilemma habe ich schon in mehr als einem Unternehmen erlebt. Da sollen Entwickler große Teile der Software-Dokumentation schreiben – als „Hilfe“ bekommen sie dazu einen 150-seitigen Redaktionsleitfaden. Eine Zumutung für jemanden, der kein Textprofi ist.

Woanders soll der Support gleich nach Bearbeitung eines Support-Falls im Ticketsystem die möglichen Abhilfen nach ganz festen Regeln dokumentieren, sodass der Content direkt in eine Knowledge-Base übernommen werden kann. Gut gemeint – maximale Content-Qualität gleich am Entstehungsort der Information. Wenn aber das Telefon in Dauerschleife klingelt, ist das zeitlich schlicht nicht machbar.

In solchen Fällen tun wir mit unseren Kunden das, was erst einmal wie das Gegenteil von Standardisierung anmutet: Wir kehren mit eisernem Besen durch den Redaktionsleitfaden. Wir nehmen uns alle Schreibregeln vor und bewerten sie im Hinblick auf Wichtigkeit und Anwendbarkeit. Da können von 150 Seiten Redaktionsleitfaden durchaus einmal nur noch 15 übrig bleiben. Aber: Lieber weniger relevante Regeln, die eingehalten werden, als ein Regeluniversum, das nur in der Theorie funktioniert.

Wo stehen Sie?

Wo drückt bei Ihnen der Schuh in Sachen Standardisierung? In welche Fallen sind Sie schon getappt? Lassen Sie uns gerne in Gespräch kommen, wenn Sie sich einen erfahrenen Sparringspartner wünschen, um Ihre Standardisierung zum Erfolg zu führen.

2 Gedanken zu „Fallstricke bei der Standardisierung von technischem Content

  1. Man sollte nicht „das Kind mit dem Badewasser…“
    Die neue ISO 82079-1 kann eine gute Basis für jedes Dokumentationsprojekt werden.
    (a) Artikel 5.3.3. – Minimalism „Minimalism shall be applied“ – Wenn eine Dokumentationsteam nach den 4 Regeln des Minimalismus ihre Doku organisiert ist sie sicher, sie arbeitet nach den „modernen“ Methoden und kann ihren Inhalt mehrmals wiederverwenden. Sie arbeitet auch medienneutral
    (b) In Sachen Warnhinweise unterscheidet die Norm zwischen „signal words for harm to persons“ und „Signal words for damage to property“
    Und, damit die Doku vor lauter Warnhinweise nicht mehr brauchbar wird, empfehlt es sich, folgende Artikel zu lesen:
    – « Warnings: superfluous Warnings are Hazardous » https://www.nngroup.com/articles/information-pollution/
    – „Lawyers are destroying the usability of American products “
    https://www.asktog.com/columns/049Lawyers.html

    Zum Schluss noch: liebe Kollegen „Use your brain!“ Der Endverbraucher ist nicht dumm!!!!

    • „Use your brain“ – volle Zustimmung. Das ist genau das, was wir in Zusammenarbeit mit unseren Kunden tun, wenn wir Standards aufräumen oder neu etablieren. Das „zusammen mit dem Kunden“ ist uns deswegen so wichtig, weil auch Normenquellen und Best Prac­tices interpretiert werden wollen/müssen, wenn es um ein ganz konkretes Unternehmen mit seinen oftmals komplexen Anforderungszusammenhängen und ganz eigenen Redaktionsprozessen geht. Eine spannende Sache – jedes Mal wieder.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.