h1

Leichte Sprache oder nicht?

31. Januar 2014

ECM-Berater schreiben deutlich mehr Word-Texte, als Programm-Code. Daher habe ich mich schon immer intensiv mit der Verständlichkeit von Fachtexten auseinandergesetzt.

Sofern es der Kunde nicht anders wünscht, nutze ich die vorzügliche Information-Mapping-Methode, um die Informationen aufzubereiten. Ich versuche den Empfehlungen von Wolf-Schneider und anderen Autoren zu folgen.

Nun bin auf einen Ansatz gestoßen, deutsche Texte für geistig Behinderte und schlecht deutsch Sprechende aufzubereiten: „Leichte Sprache„. Und dieser Ansatz entspricht über weite Strecken den Vorgaben für gute technische Dokumentation.

Bestätigt das den Verdacht mancher Geisteswissenschaftler, daß die in der Software-Industrie Tätigen geistig zurückgeblieben sind? Nein. Aber technische Texte folgen eigenen Regeln:

  • Sie sollen niemanden beeindrucken.
  • Sie müssen nicht schön sein.
  • Sie sollen unmißverständlich klar sein.

Ironie, abwechslungsreiche Wortwahl, tief geschachtelte Nebensätze, ausgefallene Fremdwörter, doppelte Verneinung können jeden verwirren – auch Hochintelligente. Solche Texte liest man langsamer (bei belletristischen Büchern durchaus mit Genuß!). Aber genau das will man bei technischen Texten nicht.

Welche Regeln kann man nun übernehmen von der „Einfachen Sprache“?

  • Benutzen Sie einfache Wörter!
    Benutzen Sie Wörter, die einen Sachverhalt genau beschreiben!
  • Vermeiden Sie Fremdwörter!
  • Benutzen Sie immer die gleichen Wörter für die gleichen Dinge!
  • Benutzen Sie kurze Wörter!
  • Verzichten Sie auf die meisten Abkürzungen!
    („d. h.“ sollte man ausschreiben)! Gut bekannte Abkürzungen helfen aber.
  • Benutzen Sie Verben!
  • Schreiben Sie im Aktiv – nie im Passiv!
    („Ein Event wird ausgelöst“ verrät uns nicht, wer das Event auslöst. Und genau darauf kommt es im technischen Text an.)
  • Vermeiden Sie den Konjunktiv!
    (ein Konjunktiv im Text sollte sie anblinken: Haben Sie jedesmal auch die Bedingung für dieses mögliche Ereignis dazugeschrieben?)
  • Schreiben Sie positiv – vermeiden Sie Verneinungen!
  • Vermeiden Sie Redewendungen!
    (viele technische Texte werden später übersetzt. Wird der Übersetzer diese Redewendung verstehen?)
  • Schreiben Sie kurze Sätze mit einfachem Satzbau!
    In jedem Satz nur eine Aussage!
  • Vermeiden Sie Fragen im Text!
  • Lösen Sie sich von übernommenen Texten! Kürzen Sie sie! Schreiben Sie sie um! Erfinden Sie Beispiele!
  • Schreiben Sie linksbündigen Flattersatz!
  • Machen Sie viele Absätze und Überschriften!
  • Drucken Sie wichtige Satzteile fett!
  • Fügen Sie oft erklärende Bilder ein!
  • Wenn Ihr Leser etwas nicht versteht, dann war ihr Text schlecht.

Ein paar Regeln würde ich jedoch trotzem mißachten in meinen Texten.

  • Eingeführte Fachbegriffe helfen – wenn alle die Fachbegriffe verstehen. Sicherheitshalber sollte man sie aber zu Beginn definieren. (Zu „SOA“ alleine habe ich schon etliche grundverschiedene Definitionen gelesen.)
  • Lange Wörter kann man durch Bindestriche gliedern. All zu rigoros widerspricht es aber unseren Lesegewohnheiten und schadet der Verständlichkeit.
  • Den Genitiv lasse ich nicht sterben. Der schmälert bei gebildeten Lesern nicht die Verständlichkeit – behaupte ich.
  • Bildhafte Sprache kann durchaus helfen. Gerade die abstrakten Softwarekonstrukte werden verständlicher, wenn wir eine Parallele aus der Alltagswelt heranziehen.
  • Jahreszahlen und Zahlen müssen exakt in Ziffern angegeben werden. Wenn die „Aufbewahrungsfrist 20 Jahre“ beträgt, hilft es niemanden von einer „Vernichtung nach langer Zeit“ zu reden. Auch wenn wir uns das bildlich besser vorstellen können.
  • In Softwarekonzepten darf man auch keine Scheu vor Zahlen mit vielen Ziffern oder Prozentangaben haben.
  • Zahlen schreibe ich nur als Ziffern, wenn ich wirklich die Zahl meine. Ich denke, daß „es gibt drei Spezialfälle“ zu weniger Mißverständnissen führt.
  • Einen Satz mit „Oder“ zu beginnen kann man machen. Konsequent durchgeführt führt das aber zu einer Staccato-Satzmelodie, die das Lesen womöglich wieder verlangsamt.
  • Definitiv muß man ständig auf andere Textstellen verweisen. Die Information-Mapping-Methode empfiehlt auch Redundanz (alles was ich zur Fragestellung meines aktuellen Kapitels wissen muß soll ich auch in meinem Kapitel finden). Aber in der Praxis läßt sich so ein Text schlecht warten und wäre teilweise extrem lang.
  • Schrifttypen mit Serifen sind bei gedruckten Texten nachweislich schneller zu lesen. Und Courier hat Vorteile bei Codestellen.
  • Pro Satz eine neue Zeile wäre schon etwas rigoros. Die extrem hilfreichen Aufzählungen mit Spiegelstrichen führen allerdings zu einem ähnlichen Effekt.
  • Ich nutze Silbentrennung. Ich würde aber davon ablassen, wenn ich einen Nachweis lesen würde, daß sie die Lesegeschwindigkeit bremst.
  • Es könnte schon sinnvoll sein, einen Seitenumbruch nur am Satzende zu machen. Aber da wir Texte ständig überarbeiten, kämen wir mit den manuellen Seitenumbrüchen nicht mehr hinterher.

Wenn Sie selbst Texte schreiben: Schauen Sie mal die unprätentiösen Worterklärungen bein Hurraki an! Das macht doch Lust, die vielen kursierenden Blähworte zum Platzen zu bringen, oder?

Ein Leitbild für meine Texte ist: Ein aufgeweckter Zehnjähriger sollte sie verstehen. Wenn ich das jemals schaffe, dann schreibe ich selbst ein Buch über gute technische Texte.

Ein Kommentar

  1. […] Hier geht es zum Artikel von Ulrich Bähr: Leichte Sprache oder nicht? […]



Hinterlasse einen Kommentar