Raus aus der Endlosschleife: Reviewprozesse in der Technischen Redaktion optimieren

Erst vergangene Woche hat mir eine Kollegin ihr Leid geklagt. Als Rückmeldung zu einer Anleitung hat sie aus der Fachabteilung eines Projektpartners ein eingescanntes Dokument zurückbekommen. Die Korrekturen: handschriftlich, in verschiedenen Farben, teilweise schwer zu lesen.

Was für die einen einfach und effizient ist, erzeugt bei anderen eine Menge Arbeit und mitten in einem qualitätsgetriebenen Arbeitsschritt neue Qualitätsrisiken. Wenn Sie in einer Technischen Redaktion arbeiten oder eine Redaktion leiten, haben Sie Ähnliches vermutlich auch schon erlebt. Aber wie gestaltet man die Reviewprozesse in der Technischen Redaktion besser?

Bedürfnisse und Standards klar kommunizieren

Wir werden gleich auch über sinnvolle Software-Unterstützung reden. Aber tatsächlich ist der erste Schritt hin zu einem funktionierenden Reviewprozess ein vollkommen nicht-technischer: Damit die Korrekturschleifen nicht zur Endlosschleife werden, müssen die Technische Redaktion als Auftraggeberin und die Leute, die den Review durchführen, ein gemeinsames Verständnis für die Aufgabe finden.

Was soll gereviewt werden? Und in welcher Form? Manchmal reichen bereits wenige Hinweise in diese Richtung, um gute Rückmeldungen zu bekommen und unnötige Arbeit einzusparen. Ich habe mir zum Beispiel angewöhnt, meinen Review-Partner:innen mitzugeben, wie vertieft sie sich ein Dokument ansehen sollen. Geht es um einen detaillierten Review, in dem jede Zeile und jedes Wort geprüft werden muss? Oder geht es erst einmal um eine grundlegende Rückmeldung zu ganz bestimmten Themen – und noch gar nicht ums große Ganze?

Sehr hilfreich ist auch, wenn man den Reviewern vorgibt, wie sie ihre Korrekturen zurückmelden sollen. Wenn das Medium für die Rückmeldung PDF sein soll, dann bitte mit der Kommentarfunktion. Keine handschriftlichen Eintragungen, keine unplatzierten Kommentare. Wenn das Transfer-Medium Word ist: Bitte nichts nachformatieren – keine Listen und keine Seitenumbrüche – auch keine Logos austauschen. Das ist unnötige Liebesmüh – vor allem, wenn der Datenmaster ein Redaktionssystem ist.

Ein letzter Punkt in dieser Rubrik: Mit zum Briefing an meine Reviewer gehört auch immer, dass sie komplexe Korrekturbedarfe nicht durch Kommentierung oder den Versuch des Komplettumbaus einer Textpassage oder des ganzen Dokuments rückmelden sollen. Wenn etwas so grundlegend geändert werden muss, dass die Kommentierung oder Korrekturanweisung zu Einzelheiten nicht ausreichen, braucht es ein Gespräch. Redaktion und Fachleute müssen noch einmal reden, es braucht Nachrecherche und einen neuen Entwurf für die betroffenen Inhalte. Das spart eine Menge Ärger und Emotionen – und unter dem Strich auch sehr viel Arbeit.

Was ich hier als lose Tipps formuliere, lässt sich natürlich auch formalisieren. Das ist dann sinnvoll, wenn Sie als Redaktion große Mengen an Content erzeugen mit hohen Qualitätsstandards und vielen Schnittstellen zu unterschiedlichen Reviewern. In diesem Fall ist es wichtig, dass sie den Reviewprozess explizit definieren und z. B. in einem Review-Leitfaden festhalten.

Einen Reviewer-freundlichen Rückmeldekanal finden

Bisher haben wir nur über PDF und Word gesprochen. Vielleicht denken Sie: Das ist ja ganz nett – aber lässt sich auf dieser Basis ein professioneller und stabiler Reviewprozess aufbauen? Aus Erfahrung kann ich sagen: Ja, das geht prinzipiell schon. Allerdings nur dann, wenn alle Beteiligten sehr diszipliniert arbeiten.

Aber natürlich geht es gesteuerter, effizienter und bequemer.  Das Idealbild aus Prozesssicht wäre, wenn Redaktion und Reviewer auf derselben Plattform arbeiten. In einem Unternehmen, in dem die Technische Dokumentation in einem XML-Redaktionssystem wie SCHEMA ST4 entsteht, ist das technisch kein Problem. Problem gelöst?

Was den Rückmeldekanal angeht, hängt der ganze Erfolg eines Reviewprozesses davon ab, ob die Reviewer den angebotenen Kanal akzeptieren und ob sie ihn sicher und einfach bedienen können. Das ist der Grund, warum sich viele unserer Kunden gegen eine direkte Einbindung der Reviewer ins Redaktionssystem entschieden haben. Die aus Redaktionssicht absolut notwendige Kleinteiligkeit der Inhalte in wiederverwendbaren und mit zahlreichen Metadaten klassifizierten Modulen ist den Expert:innen aus Entwicklung und Konstruktion kaum zumutbar. Auch dass die Inhalte nicht im Endlayout erscheinen, ist für viele Reviewer eine schwierige Hürde.

Uns hat dieses Dilemma dazu bewogen, eine HTML-basierte Lösung als Reviewkanal zu entwickeln. Sie lässt sich per Knopfdruck aus dem Redaktionssystem erzeugen. Die Reviewer sehen auch in umfangreichen Zusammenstellungen auf einen Blick, wo ihre Rückmeldung gefragt ist. Ihre Korrekturen und Anmerkungen können sie in Formularfeldern hinterlegen. Es können mehrere Reviewer parallel arbeiten – und die gesammelten Rückmeldungen gehen strukturiert und standardisiert an die Redaktion zurück.

Wie sieht der Reviewprozess in Ihrer Technischen Redaktion aus?

Mein Fazit: Wenn Sie einen funktionierenden Reviewprozess etablieren wollen, müssen Sie die Bedürfnisse von Redaktion und Reviewern gleichermaßen berücksichtigen. Es braucht Klarheit über den Prozess und die Vorgaben, und einen Rückmeldekanal, der den Prozess möglichst vollständig unterstützt. Und der vor allem die Bedürfnisse der Reviewer berücksichtigt. Wie viel Klarheit haben Sie in Ihrem Reviewprozess erreicht? Und wo spüren Sie noch schmerzliche Lücken?

Übrigens – unseren HTML-basierten Reviewkanal stellen wir bald hier im Blog vor und im kommenden Jahr wird es dazu auch ein Webinar geben, zu dem ich Sie gerne heute bereits einlade.