Woran ich beim Redigieren denke (2019)
(evaparish.com)- Beim Redigieren geht es, bevor man Sätze glättet, darum zu prüfen, was ein Text tatsächlich sagen will und wer seine Leser sind; dieselben Grundprinzipien lassen sich auf E-Mails, Dokumente, Blogs und Romane anwenden
- Wenn man am Anfang und Ende eines Textes den Kernpunkt erneut aufgreift und statt Verweisen wie „this/that“ ein Substantiv ergänzt, verlieren Leser den Kontext nicht und die Klarheit steigt
- Entfernt man unnötige Wörter, macht Anweisungen zum Imperativ und zerlegt lange Sätze sowie „of/for“-Konstruktionen, wird Bedeutung schneller vermittelt
- Passiv, Adverbien, Fachjargon und Floskeln können Akteure, genaue Bedeutung und Zielgruppe verwischen; besser sind konkrete Verben und Erklärungen
- Gutes Redigieren heißt nicht, Regeln blind zu befolgen, sondern die Wortwahl bewusst auf die zu vermittelnde Botschaft auszurichten und überflüssige Formulierungen zu streichen
Zuerst festlegen, was der Text tatsächlich sagt
- Bevor man auf Satzebene redigiert, sollte man zuerst prüfen, ob der Text tatsächlich das sagt, was er sagen soll
- Für jeden Text eine persönliche Präambel (preamble) zu schreiben, schafft Kriterien für die Bearbeitung
- Die Kernfragen lauten: „Was ist die Hauptaussage?“ und „Für wen schreibe ich?“
- Diese Informationen oben ins Dokument schreiben und beim Schreiben und Redigieren mit dem tatsächlichen Inhalt abgleichen
- Wenn man den Punkt eines Blogbeitrags nicht in ein oder zwei Sätzen zusammenfassen kann, ist es schwierig, einen konsistenten Text zu schreiben
- In den Kreativkursen von Writers Studio wird zu jeder Aufgabe eine Präambel geschrieben, die die beabsichtigte Erzählerstimme, den Ton und die Stimmung enthält; die Bewertung konzentriert sich weniger auf Geschmack als auf Technik und darauf, ob die Absicht erreicht wurde
Wiederholung hält die Leser bei der Stange
- Auch wenn der Kernpunkt schon klar genug wirkt: Wenn man ihn am Anfang und am Ende des Textes erneut formuliert, können Leser der Aussage besser folgen
- Für Dokumentations-Tutorials eignet sich meist eine Struktur, die zuerst erklärt, was getan wird, dann die Schritte liefert und anschließend überprüft, ob alles korrekt ausgeführt wurde
- Auch bei Blogbeiträgen passt es, das Thema einzuführen, es im Hauptteil zu entwickeln und am Ende eine kurze Zusammenfassung zu geben
- Wiederholung ist auch auf sprachlicher Ebene nötig
- Statt nur Demonstrativpronomen wie „this“ und „that“ zu verwenden, sollte man ein Substantiv ergänzen, das sagt, worauf sie sich beziehen
- „To solve this shortage“ ist klarer als „To solve this“
- „Successfully authenticating will take you to the home screen“ ist eindeutiger als „That will take you to the home screen“
- Was sich für den Autor wie Wiederholung anfühlt, ist für Leser eine Klarstellung, die den Text leichter nachvollziehbar macht
Vereinfachen: Wörter ohne Bedeutung entfernen
- Die wichtigste Arbeit beim Redigieren besteht darin, Wörter zu streichen, die nichts zur Bedeutung beitragen
- „You will need to run this script“ lässt sich zu „Run this script“ kürzen
- „You can aid in readability by making sure…“ lässt sich zu „Make sure…“ kürzen
- Wenn es keinen besonderen Grund gibt, sollte man so schnell wie möglich zum Punkt kommen und die Bedeutung nicht unter überflüssigen Wörtern und dekorativen Satzstrukturen begraben
-
Anweisungen in den Imperativ umwandeln
- In Anweisungen sind „You should X“ und „You can X“ knapper, wenn man sie in den Imperativ des Verbs umformuliert
- Aus „You should save the file to your home directory“ wird „Save the file to your home directory“
- Diese Änderung reduziert die Wortzahl und führt Leser direkt zur Handlung
-
„of“- und „for“-Konstruktionen reduzieren
- Konstruktionen mit aufeinanderfolgenden „of“ oder „for“ werden effizienter, wenn man die Informationen vor dem Substantiv platziert
- Aus „The manager of the team responsible for marketing“ wird „The marketing team’s manager“
- Der umgestellte Satz hilft Lesern, die Bedeutung schneller zu erfassen, ohne ihr Verständnis bei jedem Teilsatz korrigieren zu müssen
-
Lange Sätze aufteilen und Kommas setzen
- Lange Sätze sollte man besser in mehrere kurze Sätze aufteilen
- Im Beispiel mit dem Acme-Projekt enthielt ein einzelner Satz Milestone, Serverumgebung, Verbesserungen der Build-Zeit und einen Vergleich mit dem XYZ plan; die überarbeitete Fassung trennte dies in drei Sätze
- Die überarbeitete Fassung vermittelt getrennt, dass die Non-Staging-Server in der Foobaz-Umgebung laufen, dass der Build auf unter 10 Minuten gesunken ist und dass er im XYZ plan zuvor über eine Stunde gedauert hatte
- Kommas an den richtigen Stellen helfen Lesern, den ersten Teil zu verarbeiten, bevor sie den Rest lesen
- „If you’re looking for me, I’ll be in my office“
- „Due to the fog, our flight was delayed“
- Wenn ein Nebensatz am Satzanfang steht, ist ein Komma nötig; dieses Komma wird zu einem Verarbeitungspunkt, der das Lesen erleichtert
Formulierungen reduzieren, die Akteure und Bedeutung verwischen
-
Passiv entfernen
- Das Passiv verschleiert, wer oder was eine Handlung ausführt
- Wenn man Passivkonstruktionen ins Aktiv umformuliert, können Leser die Handlung der richtigen Person oder Sache zuordnen, wodurch der Satz klarer wird
- „The fire alarm was pulled and the building was evacuated“ macht die Akteure sichtbar, wenn man schreibt: „The fire marshal pulled the alarm and the employees evacuated the building“
- „Millions of dollars were embezzled from the company“ zeigt mit „Two executives embezzled millions of dollars from the company“, wer es getan hat
- Schreibt man in einer Systembeschreibung „An alert is triggered and the job is started“, bleibt offen, welcher Dienst die Benachrichtigung auslöst und welche Komponente den Job startet
- Wenn technische Dokumentation den Handelnden nicht benennt, sinkt die Präzision
-
Statt Adverbien konkrete Verben und Beschreibungen verwenden
- Adverbien lassen sich fast immer durch ein konkreteres Verb oder eine genauere Beschreibung ersetzen
- In „He laughed loudly“ lässt „loudly“ Leser raten, wie laut oder wie das Lachen genau war
- Wenn eigentlich gemeint ist, dass er so laut lachte, dass sich das ganze Restaurant umdrehte, ist es konkreter, diese Situation direkt zu beschreiben
- Adverbien wie „Basically“ und „Essentially“ werden oft als Absicherung verwendet; besser ist es, sie zu entfernen und direkt zu sagen, was gemeint ist
Wissen und Ton der Leser nicht voraussetzen
-
Abkürzungen und Konzepte erklären
- Wenn man über ein vertrautes Thema schreibt, vergisst man leicht, welches Hintergrundwissen Lesern fehlen könnte
- Abkürzungen und Initialwörter sollten beim ersten Auftreten ausgeschrieben und die Abkürzung in Klammern ergänzt werden; danach reicht die Abkürzung
- „TTFB“ schreibt man zuerst als „time to first byte (TTFB)“
- Wenn ein Konzept zum ersten Mal erscheint, hilft eine kurze Erklärung, damit Leser folgen können
- TTFB misst die Zeit vom Absenden einer HTTP-Anfrage durch den Nutzer bis zum Laden des ersten Bytes durch den Browser
- Es wird als Kennzahl für die Reaktionsfähigkeit einer Website verwendet
- Bei Bedarf kann man einen Link zum Weiterlernen anbieten, etwa time to first byte (TTFB) metric
-
Konsistenter Ton
- Der Ton eines Textes sollte, ob umgangssprachlich oder formell, einmal festgelegt und dann konsistent beibehalten werden
- Wenn ein Satz sehr umgangssprachlich beginnt und dann in akademische Formulierungen wechselt, kann das Leser verwirren oder ihre Aufmerksamkeit vom eigentlichen Inhalt abziehen
- Der Beispielsatz lässt sich in einem einheitlichen Ton umformulieren, etwa: „Am Anfang war ich vom neuen Framework begeistert, aber ich konnte die gewünschten Metriken nicht erfassen“
Fachjargon, Floskeln und visuelle Struktur glätten
-
Fachjargon und Floskeln vermeiden
- Zum Business-Jargon gehören Ausdrücke wie „deep dive“ und „low-hanging fruit“; in anderen Texten werden oft Floskeln wie Baseball-Metaphern verwendet
- Fachjargon setzt voraus, dass Leser zu der internen Gruppe gehören, die diese Ausdrücke verwendet
- Für Nicht-Muttersprachler des Englischen oder Leser, die mit Baseball-Kultur nicht vertraut sind, können Fachjargon und Floskeln es schwerer machen, dem Text zu folgen
- „tl;dr, if you can hack something together by EOD…“ enthält Abkürzungen und technischen Slang und klingt nicht wie eine Bitte
- „Can you deliver a prototype by the end of today?“ wird zu einer klaren Bitte, die das benötigte Ergebnis und die Frist direkt erfragt
-
Leerraum und Formatierung nutzen
- Leerraum ist in technischer Dokumentation wichtig und wirkt auch in Blogbeiträgen und E-Mails
- Lange Absätze sind besonders auf Computerbildschirmen schwer zu lesen und können dazu führen, dass Leser die Konzentration verlieren
- Wenn man die Seite visuell aufteilt, lassen sich Kernpunkte leichter finden
- Lange Absätze in mehrere kurze Absätze aufteilen
- Mit nützlichen Zwischenüberschriften Struktur schaffen und Lesern ermöglichen, zu den Abschnitten zu springen, die sie interessieren
- Zusammengehörige Punkte als Liste schreiben
- Wenn viele Informationen vermittelt werden, wie in Referenzdokumentation, kann eine Tabelle besser sein als eine Liste
- Fettmarkierungen verwenden, damit überfliegende Leser die wichtigsten Punkte erfassen können
Redigierphilosophie
- Die Redigierphilosophie lässt sich auf zwei Punkte reduzieren
- Nicht auf Adverbien, Fachjargon, Floskeln oder Absicherungen stützen, sondern genau sagen, was man meint
- Alle unnötigen Wörter entfernen
- Diese beiden Prinzipien bilden einen Rahmen, um den eigenen Text zu überarbeiten und Texte anderer zu bewerten
- Mit Übung entwickelt man den eigenen Stil und eigene Vorlieben; wenn man die Gründe kennt, ist es in Ordnung, von manchen Empfehlungen abzuweichen
- Ziel des Redigierens ist nicht, Regeln unkritisch zu befolgen, sondern sich des Sprachgebrauchs bewusst zu sein und Entscheidungen zu treffen, die zur beabsichtigten Botschaft passen
1 Kommentare
Hacker-News-Kommentare
Ich bin die Person, die diesen Artikel geschrieben hat. Es freut und ehrt mich, dass er bei so vielen Anklang gefunden hat. Nachdem ich ihn geschrieben hatte, bin ich meiner Neugier gefolgt und selbst Software Engineer geworden; nach ein paar Jahren Arbeit vermisse ich nun Rollen mit einem größeren Schreibanteil. Falls jemand eine hervorragende technische Redakteurin, Developer Advocate oder eine Rolle sucht, die Kommunikationskompetenz mit technischem Können verbindet, gebt mir bitte Bescheid. Ihr könnt mich über das Formular auf meiner Website (https://evaparish.com/contact) oder über LinkedIn kontaktieren.
Eines der Dinge, die mich beim Lesen technischer Dokumentation am meisten stören, ist, wenn Abkürzungen auftauchen, die den Lesern noch nicht vorgestellt wurden. Das wiederholt sich an mehreren Stellen in Projektdokumentationen, und wenn über die Jahre die Zuständigen wechseln, kommt es sogar dazu, dass niemand mehr weiß, wofür eine bestimmte Abkürzung eigentlich steht. Ich habe tatsächlich schon mehrfach die seltsame Situation erlebt, dass ein Team einen Dienst namens ABC entwickelt und wartet, aber niemand im Team weiß, wofür ABC steht. In solchen Fällen behandelt man ABC dann einfach wie einen Eigennamen, um zu vermeiden, einen neuen Namen zu wählen und alle zugehörigen Dokumente zu aktualisieren. Fiktives Beispiel: Um ein Access Token für CDIS zu erhalten, gehen Sie zur DMC von , klicken Sie in der linken Seitenleiste auf den Eintrag „CDIS“ und klicken Sie auf „Generate Access Token“, um das Token zu kopieren. Lieber würde ich es so lesen: Um ein Access Token für den Customer Data Indexing Service (CDIS) zu erhalten, gehen Sie zur Data Management Console (DMC) von , klicken Sie in der linken Seitenleiste auf den Eintrag „CDIS“ und klicken Sie auf „Generate Access Token“, um das Token zu kopieren.