Skip to content
readit
readit

leben, technik und kommunikation

  • werkstatt
    • appseits
    • dokumentation
    • software
    • praxistipps
    • referenzen
  • thinkware
    • Gesellschaft
    • public
    • Reisebilder
    • Lyrik
  • Nach­richt an mich
    • Datenschutz
    • Impres­sum
readit
readit

leben, technik und kommunikation

Kommentieren oder Korrigieren?

24.01.201617.08.2018

Heute mal wieder ein Beitrag aus der Waschküche des Technischen Redakteurs: es geht um das ganz beliebte Thema „Korrekturlauf”.
OMG!

Korrekturläufe sind bei allen Beteiligten im Dokumentationsprozess so beliebt wie Kopfläuse im Kindergarten: Je seltener, desto besser.
Aber genau wie Kopfläuse sind sie unausweichlich.
Im Gegensatz zu jenen possierlichen Mitbewohnern sind sie nämlich sogar notwendig für die Verbesserung der Dokumentation. Sie verbessern den Informationsfluss zum Benutzer. Streng genommen ermöglichen sie sogar erst einen richtigen Umgang mit dem Produkt, denn vor dem Korrekturlauf ist die Dokumentation nur eine Niederschrift dessen, was der Redakteur vom Produkt und seiner Nutzung verstanden hat.
Der Korrekturlauf hilft dem Redakteur dabei, zumindest seine Ansprüche an die Information mit denen seines Auftraggebers abzustimmen. Dahinter steht die Hoffnung, dass der Auftraggeber auch gleichzeitig seine Benutzer soweit kennt, dass die Sicht des Benutzers mit der des Auftraggebers deckungsgleich ist.
Als Technischer Redakteur kennt man ja nur zwei Ecken des Dreiecks — die Benutzererwartung kennt man nicht. Dafür sind Korrekturläufe aber auch nicht gedacht.

Was heißt „Korrektur”?

Da der Korrekturlauf die Sicht des Auftraggebers oder des SME ((SME = „Subject matter expert”, also Fachkundiger des Produkts)) mit der des Redakteurs abgleichen und die Dokumentation „richtig” stellen soll (nichts anderes bedeutet Korrektur), handelt es sich also um eine rein fachliche Angelegenheit:

  • Sind die Abläufe in der richtigen (sprich: durchführbaren) Reihenfolge?
  • Sind die richtigen Bezeichnungen verwendet worden?
  • Ist das Produkt richtig beschrieben und die richtigen technischen Daten enthalten?
  • Sind alle Sicherheitshinweise beachtet worden?
  • …

Ein Korrekturlauf ist keine persönliche Angelegenheit, bei der Geschmäcker aufeinanderprallen („Also ich würde das ja lieber fett kennzeichnen!”) oder grundsätzliche Fragen zum Nutzungsspektrum des Produkts geklärt werden („Es könnte natürlich sein, dass wir das Produkt auch in einem Jahr online verkaufen und der Anwender dann keine Vorkenntnisse hat.”)
So etwas muss vorher geklärt werden, damit der Redakteur dies bei der Erstellung berücksichtigen kann, denn die Nacharbeit kann sehr zeitaufwändig sein (und ist daher sehr unbeliebt, denn ein Beteiligter zahlt dabei immer drauf).
Was auch nicht auftreten darf, ist eine grundsätzliche Infragestellung des gesamten Dokumentationsprozesses oder irgendwelche Ergänzungen („Wir haben da noch die Varianten B und C, lässt sich das noch schnell hineinkopieren?”). Auch das sind Fragen, die eigentlich in die Konzeptphase gehören — oder in einen anschließenden Dokumentationsprozess.

Und was machen die Kommentare?

Ein sehr beliebtes Missverständnis während des Korrekturlaufs sind allerdings Kommentare. Auch wenn in der Software diese Funktion „Comments” heißt, sind Kommentare und Korrekturen grundverschieden:
Kommentare kann nämlich jeder abgeben („Finde ich irgendwie doof.”), sie sind aber nicht hilfreich bei der Korrektur, da sie keine klare Anweisung enthalten, was denn korrigiert werden soll.
Und dazu zählen auch Kommentare, mit denen sich schon in der Schule Deutschlehrer unbeliebt machten: „Quatsch!”, „Falsch!”. Sie verlangen vom Redakteur, der das Produkt ja am wenigsten kennt, eine fachliche Antwort zu geben, die nicht zu seinem Aufgabengebiet gehört. Was soll der Redakteur mit einem Kommentar anfangen, der lediglich aus einem Fragezeichen besteht? Ignorieren? Ablehnen? Alles ändern — und wenn ja, wie?
In diesem Stadium braucht der Redakteur klare Anweisungen, was richtig ist — und wenn es falsch sein sollte, wie es dann richtig ist. Der Redakteur muss nämlich sonst rückfragen und das kostet Zeit. Oder einen neuen Korrekturlauf. Und dann geht das Eingrenzen der Unklarheiten wieder von vorne los.
Für den Redakteur bedeutet das: Unklarheiten im Erstellungsprozess beseitigen (oder auf einen neuen Dokumentationsprozess verschieben) und Verständnisfragen nicht erst im Korrekturlauf unterbringen.
Für den Auftraggeber/SME bedeutet das: Im Korrekturlauf keine Fragen stellen, sondern Antworten geben.

Also wie jetzt?

Ein Korrekturlauf ist wie eine mathematische Iteration: je schneller die Unklarheiten und Fehler beseitigt werden, desto weniger Wiederholungen benötigt man.
Und desto weniger Ärger gibt es. Dann sind nämlich auch Korrekturläufe richtig gut. Wir wollen ja alle gute Arbeit liefern.

Teilen mit:

  • Auf Mastodon teilen (Wird in neuem Fenster geöffnet) Mastodon
  • Auf WhatsApp teilen (Wird in neuem Fenster geöffnet) WhatsApp
  • Einen Link per E-Mail an einen Freund senden (Wird in neuem Fenster geöffnet) E-Mail
  • Auf Bluesky teilen (Wird in neuem Fenster geöffnet) Bluesky
  • Mehr
  • Drucken (Wird in neuem Fenster geöffnet) Drucken
  • Auf LinkedIn teilen (Wird in neuem Fenster geöffnet) LinkedIn
  • Auf Telegram teilen (Wird in neuem Fenster geöffnet) Telegram
  • Auf Pinterest teilen (Wird in neuem Fenster geöffnet) Pinterest

Gefällt mir:

Gefällt mir Wird geladen …
technische dokumentation ArbeitdokumentationInformationsprozesseKommunikationTechnische Kommunikation

Beitragsnavigation

Previous post
Next post

Related Posts

dokumentation

tekom goes mobile

27.10.201721.02.2019

Wer wie ich eigentlich seltener auf eine so große Veranstaltung wie die tekom geht und sich über die neuesten Entwicklungen und Erkenntnisse der Technischen Dokumentation…

Teilen mit:

  • Auf Mastodon teilen (Wird in neuem Fenster geöffnet) Mastodon
  • Auf WhatsApp teilen (Wird in neuem Fenster geöffnet) WhatsApp
  • Einen Link per E-Mail an einen Freund senden (Wird in neuem Fenster geöffnet) E-Mail
  • Auf Bluesky teilen (Wird in neuem Fenster geöffnet) Bluesky
  • Mehr
  • Drucken (Wird in neuem Fenster geöffnet) Drucken
  • Auf LinkedIn teilen (Wird in neuem Fenster geöffnet) LinkedIn
  • Auf Telegram teilen (Wird in neuem Fenster geöffnet) Telegram
  • Auf Pinterest teilen (Wird in neuem Fenster geöffnet) Pinterest

Gefällt mir:

Gefällt mir Wird geladen …
Read More
appseits

Adobe Creative Cloud App: Closing the loop

01.11.201925.06.2020

Wenn die Rede von Apps ist, die mit der Cloud kommunizieren, dann endet die Vorstellung der meisten Anwender etwa dort, wo der Router sein Kabel…

Teilen mit:

  • Auf Mastodon teilen (Wird in neuem Fenster geöffnet) Mastodon
  • Auf WhatsApp teilen (Wird in neuem Fenster geöffnet) WhatsApp
  • Einen Link per E-Mail an einen Freund senden (Wird in neuem Fenster geöffnet) E-Mail
  • Auf Bluesky teilen (Wird in neuem Fenster geöffnet) Bluesky
  • Mehr
  • Drucken (Wird in neuem Fenster geöffnet) Drucken
  • Auf LinkedIn teilen (Wird in neuem Fenster geöffnet) LinkedIn
  • Auf Telegram teilen (Wird in neuem Fenster geöffnet) Telegram
  • Auf Pinterest teilen (Wird in neuem Fenster geöffnet) Pinterest

Gefällt mir:

Gefällt mir Wird geladen …
Read More
dokumentation

Wahl der Waffen, Teil III: Wiki oder Onlinehilfe?

15.08.201503.11.2018

(Bildquelle siehe unten) Alle wollen weg vom Papier. Auch in der Technischen Dokumentation stehen Dokumentationsverantwortliche und Redakteure oft vor der Entscheidung: soll ich einer vermeintlichen…

Gefällt mir:

Gefällt mir Wird geladen …
Read More

Sonst noch was:

  • Produktiver als jeder Montag: Aufgabenverwaltung mit monday.com
  • Aufgabenverwaltung: Work smarter, not harder
  • SVG zähmen leicht gemacht
  • Giro D'Etruria: Toskana und die Emilia Romagna 2025
  • MadCap Flare und Atlassian Confluence: das Powercouple
  • JIRA: Das Monster der Aufgabenverwaltung
  • Radfahren im Bayerischen Wald: Unterwegs am 49. Breitengrad
  • Tools for fools
  • Kommunikation kanalisieren
  • Onlinehilfen: Form follows function
  • Taskworld, der Kopfschmerzvermeider
  • Japan parforce

Beliebt:

  • Bequem schnarchen
  • Brauchen wir wirklich internationalen Klimaschutz?
  • Bombenalarm am Eiffelturm!
  • Rot, 1
  • Selbstständigkeit: To be or not to be
  • Führend in was?
  • Was für die Hartformatierer
  • Zwei für Alles
  • Documents: Im Labyrinth der Datencloud
  • Lieber Peer, es ist auch mein Geld!

Klima und Umwelt

  • Klima vor Acht Das Ziel von KLIMA° vor acht ist es, Fernsehsender zu überzeugen, wissenschaftlich fundierte Klimaberichterstattung zu produzieren, die täglich zur besten Sendezeit ausgestrahlt wird und so viele Zuschauer wie möglich erreicht.

Blog via E-Mail abonnieren

Gib deine E-Mail-Adresse an, um diesen Blog zu abonnieren und Benachrichtigungen über neue Beiträge via E-Mail zu erhalten.

Gern gelesen

  • Bequem schnarchen
  • Brauchen wir wirklich internationalen Klimaschutz?
  • Bombenalarm am Eiffelturm!
  • Rot, 1
  • Selbstständigkeit: To be or not to be
  • Führend in was?
  • Was für die Hartformatierer
  • Zwei für Alles
  • Documents: Im Labyrinth der Datencloud

Hinweis

Es bestehen zu keinen der in diesem Blog genannten Unternehmen und Personen geschäftliche Beziehungen in der Form, dass ich für Werbung oder Vermarktung Geld oder geldwerte Zuwendungen erhalte.

Rechtliches

  • Datenschutz
  • Impressum
Datenschutz und Cookies: Diese Website verwendet Cookies. Wenn du die Website weiterhin nutzt, stimmst du der Verwendung von Cookies zu.

Weitere Informationen, beispielsweise zur Kontrolle von Cookies, findest du hier: Cookie-Richtlinie
©2026 readit | WordPress Theme by SuperbThemes
%d