Recherche ist zeitaufwendig, anstrengend und erfordert neben Analysekompetenz auch Hartnäckigkeit, sehr gute Beobachtungsgabe und Aufgeschlossenheit. Mit gründlicher, umfassender Recherche beginnt die Arbeit jedes Technischen Redakteurs.
Eine gründliche Recherche ist elementar wichtig und die entscheidende Grundlage dafür, wie nutzbar, zugeschnitten und geeignet die Inhalte sind, die ein Technischer Redakteur während eines Projekts erarbeitet.
Die Recherchetätigkeit konzentriert sich dabei aber nicht bloß auf den Projektbeginn, sondern erstreckt sich vielmehr über den gesamten Prozess.
Wie der Name schon sagt, folgt ein Produktentstehungsprozess stets einem Verlauf, er besteht aus einer Reihe von Aktionen oder Schritten, die notwendig werden, um ein bestimmtes Ziel zu erreichen. Jeder Schritt bringt neue Istzustände mit sich und diese Änderungen machen es immerzu erforderlich, weitere Recherchen anzustellen, um seine Erkenntnisse während des Projektverlaufs entsprechend anpassen zu können.
(Tipp: Für eine bessere Lesbarkeit beim Hineinzoomen öffnen Sie das PDF im externen Adobe Reader)
Produktrecherche
Ein Technischer Redakteur ist ein wichtiger Teil des Produktteams. Während sich die Entwickler zumeist auf einen bestimmten Aspekt des Produkts konzentrieren, ist es die Aufgabe eines Technischen Redakteurs, stets das komplette Produkt während seiner gesamten Produktlebensdauer im Blick zu haben.
Dabei ist es unerheblich, ob es sich um ein Hardware-Produkt oder um ein Software-Programm, eine browserbasierte Webanwendung, eine Website oder eine Handy-App handelt.
Ein Technischer Redakteur muss das Produkt in seiner Gesamtheit verstehen, um entscheiden zu können, welche Informationen er auf welche Weise seiner Zielgruppe zur Verfügung stellt.
Er befasst sich unter anderem mit den folgenden Fragen:
- Was macht das Produkt?
- Welchen Zweck hat das Produkt?
- In welchem Kontext wird das Produkt angewendet?
- Welche Funktionen hat das Produkt?
- Wie werden die Funktionen korrekt verwendet?
- Kann das Produkt fehlbedient werden?
- Wie reagiert das Produkt auf Fehlbedienungen?
- Welche Interaktionselemente hat das Produkt?
- Wie wird das Produkt installiert und eingerichtet?
- Welche Informationen müssen zusätzlich bereitgestellt werden, weil sie wichtig sind für den Produktanwender? Aus welchem Grund sind sie wichtig für den Produktanwender?
- Geht von dem Produkt eine Gefahr aus?
- Wie wird das Produkt aktualisiert oder ggf. gewartet?
Um diese Frage beantworten zu können, muss sich der Technische Redakteur eingehend mit dem Produkt, aber auch mit dem Entwicklerteam auseinandersetzen. Er muss das Verhalten des Produkts verstehen, sich aber auch vergewissern, dass das tatsächliche Verhalten mit der Intension des Entwicklers übereinstimmt.
Mögliche Recherchequellen sind neben den Entwicklern auch z. B. Vorgängermodelle, das Lastenheft, in dem die Kundenanforderungen formuliert sind und – ganz wichtig – die Produktprototypen.
Nichts gibt mehr Aufschluss über ein Produkt als das Produkt höchstselbst. Es ist zwingend notwendig, dass derjenige, der für das Produkt schreibt, auch testet, ob das, was er schreibt, auch tatsächlich so zutrifft.
Technischer Redakteur und Entwicklerteam stehen daher im ständigen Austausch miteinander und das während der gesamten Produktlebensphase: Produkte, vor allem digitale Produkte, werden stets aktualisiert. Durch die Aktualisierung werden Produktparameter verändert, was wiederum zur Folge hat, dass sich Texte ändern (müssen).
Wichtige Informationen für den Produktanwender
Neben der Produktrecherche ist auch die Recherche über die Zielgruppe wichtig. Hier stellen sich vor allem folgende Fragen:
- Welche Ziele hat der Produktanwender?
- Welche Informationen benötigt der Produktanwender, um sein Ziel zu erreichen? Und welche nicht?
Bei mir stehen diese beiden Fragen stets im Zentrum und deren Beantwortung zeigt, was eine echte Kernkompetenz eines jeden Technischen Redakteurs ist: die Fähigkeit, wichtige Informationen von unwichtigen Informationen zu unterscheiden. Welche Informationen bringen dem Produktanwender einen tatsächlichen Mehrwert und ermöglichen es ihm, sein Ziel zu erreichen und welche Informationen sind völlig irrelevant für die Erledigung seiner Aufgaben, haben vielleicht sogar einen negativen Effekt, weil sie ihn von der Sache ablenken bzw. überfordern?
Doch es gibt noch weitere Fragen:
- Was sind die Ziele meiner Produktanwender?
- Welche Informationen sind nötig, um dem Produktanwender den vollen Funktionsumfang zugänglich zu machen?
- Welche Vorkenntnisse/Erfahrungen hat der Produktanwender? (Wie knüpfe ich an dieses Vorwissen an?)
- Welches Wissen kann ich voraussetzen?
- Worauf legt der Produktanwender wert?
- Welche Anforderungen/Erwartungen hat der Produktanwender?
- Welches Feedback gibt der Produktanwender?
- Wobei braucht der Produktanwender Hilfe/Unterstützung?
- Welche Kaufanreize hat der Produktanwender?
- Wie alt ist sind die Produktanwender?
- Welche Bedingungen müssen erfüllt sein, um den Produktanwender zufriedenzustellen? Und welche, um ihn zu begeistern?
- Wo ist die Toleranzschwelle des Produktanwenders? Wann ist sie überschritten?
Die Beantwortung dieser Fragen ist nicht immer so leicht, wobei das Finden derer stark davon abhängt, um welches Produkt es sich handelt und wie stark es im digitalen Kontext steht.
Früher®, also noch vor gut 15 Jahren, glich das Schreiben von z. B. Bedienungsanleitungen einer kommunikativen Einbahnstraße. Es wurden nach bestem Wissen und Gewissen Informationen auf weißen Blättern Papier zusammengetragen, diese gebündelt, ausgedruckt, zum Produkt gelegt und ihnen eine gute Reise gewünscht. Mögen die Informationen dem Produktanwender nützlich sein.
Soziale Medien – Oh Spieglein, oh Spieglein, …
Doch die Zeiten haben sich vor allem durch Social Media und dem digitalen Fortschritt (der auch mittlerweile in Deutschland angekommen ist…) drastisch geändert. Es ist nun möglich, aus erster Hand von unseren Produktanwendern zu erfahren, wie sie das Produkt finden, was gut daran ist, was schlecht daran ist, was verbesserungswürdig ist und warum sie das Produkt einem anderen Produkt vorziehen.
Während man zwar immer noch wertvolle Informationen zur Beantwortung der Fragen von der Supportabteilung/Kundenhotline, dem Service-/Wartungspersonal vor Ort und dem Vertrieb erhält, ist der Ort der unbegrenzten Möglichkeiten mittlerweile das World Wide Web (natürlich neben Amerika, dem gelobten Land *hüstel*).
Auf Social-Media-Plattformen und in Internetforen werden Produkte diskutiert, Produktanwender berichten in Blogs und Vlogs von Stärken und Schwächen und erstellen umfangreiche Produkt-Reviews.
Es ist großartig und lehrreich, z. B. Youtubern zuzusehen, wie sie Produkte bedienen. Und schließlich lohnt es sich auch sehr, bei seiner Recherche die Kommentare der Bewertungsportale miteinzuschließen, denn hier werden echte Schwächen und Ärgernisse offengelegt, aber auch Stärken gegenüber der Konkurrenz betont.
Feedback erwünscht!
Doch wie bereits erwähnt, hängt das Feedbackverhalten der Produktanwender auch stark vom Produkt selbst und vor allem von dem Produktentstehungsprozess ab.
Die Entwicklung von der Wasserfall-Methode hin zu agilen, iterativen Prozessen eröffneten dem Technischen Redakteur ganz neue Möglichkeiten. Bei dem Wasserfall-Vorgehensmodell wurde ein Projekt sequenziell umgesetzt, das heißt, Kundenanforderungen wurden im Lastenheft gesammelt, das Projekt kalkuliert und geplant, die Anforderungen in dem Produkt verbastelt, die Dokumentation erstellt und dem Kunden im fertigen Zustand (mit mehr oder weniger Zeitverzug als ursprünglich versprochen) ausgeliefert.
Dies hat sich mit der agilen Arbeitsweise drastisch verändert. Bei dieser Methode nimmt die Kollaboration mit dem Kunden einen erhöhten Stellenwert ein. Feedback-Schleifen mit den Kunden sind gang und gäbe. Alle am Prozess beteiligten Personen (eben auch der Technische Redakteur) profitieren davon, denn das Produkt kann so lange angepasst und mit dem Kunden abgestimmt werden, bis der Kunde am Ende das Produkt bekommt, das er sich vorgestellt hat.
Was treibt die Konkurrenz?
Damit sich ein Kunde für ein Produkt entscheidet, muss er sich zwangsweise gegen ein anderes Produkt entscheiden. Es ist also wichtig, die Konkurrenzprodukte zu kennen, um besser zu sein als sie.
Hier spielt vor allem auch das Anwendererlebnis eine zentrale Rolle, denn wer denkt, dass sich ein Produkt nur über seine Funktionen verkauft, der irrt gewaltig. Und es irrt sich zweimal, wer denkt, dass ein Technischer Redakteur nichts mit UX zu tun hat. Hierzu gibt es in Kürze einen eigenen Blogartikel.
Fragen, die sich einem Technischen Redakteur stellen müssen, sind z. B. folgende:
- Gibt es Konkurrenzprodukte?
- Welche Werte strahlt die Konkurrenz aus? Wie groß ist deren Reputation?
- Wie stark ist die Konkurrenz? Wie groß ist deren Marktanteil?
- Was macht das Konkurrenzprodukt besser? Was macht es schlechter?
- Was können wir besser machen als die Konkurrenz?
- Welche Technologien setzt die Konkurrenz ein?
- Wo gibt es Überschneidungen mit der gemeinsamen Zielgruppe? Wie groß sind sie?
- Was treibt unsere Kunden zur Konkurrenz?
Bei der Beantwortung dieser Fragen helfen uns Internet, Fachartikel, Pressemitteilungen oder Produktankündigungen. Sie informieren sowohl Kunden als auch Konkurrenz über anstehende Produktneuigkeiten. Wer sogar die Möglichkeit hat, die Konkurrenzprodukte ausgiebig zu testen – prima!
Damit das eigene Produkt besser ist als das der Konkurrenz, muss es einen Mehrwert demgegenüber haben und der Produktanwender muss diesen Mehrwert natürlich auch erkennen. Er muss sein Ziel einfacher und schneller erreichen und es muss besser zu ihm passen, und sei es nur wegen der Tonalität.
Zielgerichtete, nützliche Informationen, konsistent aufbereitet und immer dann, wenn sie gebraucht werden – das ist nicht nur ein schönes Nice-to-have, es ist ein echter Wettbewerbsvorteil.
Wasserdichte Informationen
Die Recherche von gesetzlichen Anforderungen, Richtlinien und Normen ist ein weiterer wichtiger, nicht zu unterschätzender Teil.
Die Dokumentation von sicherheitstechnischen Aspekten des Produkts (Stichwort: Bestimmungsgemäßer Gebrauch/vernünftigerweise vorhersehbare Fehlanwendung) spielt hier eine zentrale Rolle, denn es gibt eine Vielzahl von Produkten, für die das sehr relevant ist, z. B. für Maschinen, die unter die Maschinenrichtlinie fallen.
Welche Gesetze müssen eingehalten werden und welche Normen auf welche Art und Weise angewendet werden? Dies müssen die Hersteller sehr sorgfältig prüfen. Auch für Softwareprodukte gelten Standards (z. B. die Normenreihe ISO/IEC/IEEE 26511 – 26515, die DIN EN ISO 14915 oder die DIN EN ISO 9241), die als Richtlinie dienen können.
Einen Teil der Recherche übernimmt oft ein Technischer Redakteur. Zunächst muss er sammeln, welche normativen Vorgaben für die Art Produkt, für das er Inhalte erstellt, relevant sein könnten. Von den gängigsten Normen sollte er während seiner Ausbildung/seines Studiums gehört haben, was zunächst eine gute Ausgangsbasis ist. Alles, was darüber hinaus denkbar wäre, muss gründlich erarbeitet werden.
Mögliche Quellen für Gesetzestexte, Regelwerke und normative Anforderungen wären z. B.:
- Deutsches Institut für Normung (DIN)
- Europäische Kommission
- Normenorganisationen
- Gremien & Expertenräte
Die Recherche nach diesen Informationen ist nicht einfach, aber notwendig. Viele Unternehmen unterschätzen und vernachlässigen diesen Aspekt. Die Folgen davon können weitreichend sein, z. B. dann, wenn jemand zu Schaden kommt.
Wie gut also, dass es Technische Redakteure gibt.
Gemeinsame Sprache finden
Wir haben also unterschiedliche Benennungen für denselben Begriff (also für dieselbe Sache) in der Produktdokumentation, auf dem Lieferschein, in der Preisliste, in der Marketingbroschüre und auf der Website.
Wenn nun die einzelnen Abteilungen miteinander über das Projekt kommunizieren, führt das zwangsläufig zu einigen Missverständnissen und behindert die internen Abläufe (z. B. durch mehrmaliges Rückfragen).
Teuer kann es noch dazu werden, wenn externe Dienstleister, wie z. B. Übersetzer mit diesen Texten arbeiten müssen. Doch damit nicht genug, denn wenn die Produktanwender mit unterschiedlichen Benennungen konfrontiert werden, dann leidet darunter vor allem die Verständlichkeit enorm. Im schlimmsten Fall wächst darüber der Unmut der Anwender und die Akzeptanz für das Produkts schwindet Zusehens. Keine Terminologiearbeit ist keine Lösung.
Terminologie zieht sich wie ein roter Faden durch das Berufsleben jedes Technischen Redakteurs. Eine klare Kommunikation mit dem Produktanwender kommt nicht ohne konsistent verwendete, exakt definierte Terminologie aus.
Doch bis dahin ist es ein langer Weg. Und wie nahezu jeder Arbeitsschritt von Technischen Redakteuren, beginnt er unter anderem mit Recherche:
- Gibt es bereits festgelegte Unternehmensterminologie?
- Liegen Begriffsdefinitionen vor?
- Welche Benennungen werden exklusiv im Unternehmen verwendet?
- Welche Benennungen werden synonym verwendet?
- Gibt es Benennungen, die nicht verwendet werden dürfen/sollen?
- Welche Vorzugsbenennungen gibt es?
- Kann bzw. muss Terminologie aus bestehenden Texten extrahiert werden?
- Welche Schreibweisen können vereinheitlicht werden?
- Für welche Begriffe müssen neue Benennungen gefunden werden?
Als gute Quellen, um bestehende Unternehmensterminologie aufzuspüren, eignen sich z. B. bestehende Dokumentationen, Marketingtexte, Angebotstexte, aber auch Übersetzungen. In manchen Unternehmen gibt es außerdem schon so etwas wie Wortlisten oder Glossare.
Auch hier kommt dem Technischen Redakteur seine ausgeprägte Gabe der Beobachtung und des guten Zuhörens entgegen, wenn er Kollegen bei der Arbeit „über die Schulter schaut“ oder ganz gezielt Informationen abfragt.
Wenn es in weiteren Schritten der Terminologiearbeit darum geht, Terminologie zu definieren, zu beschreiben und Regeln für deren Verwendung festzulegen, helfen Quellen wie etwa:
- Fachgerichtete Terminologiedatenbanken von Hochschulen
- Fachzeitschriften von Verbänden
- Enzyklopädien und Lexika
- Fachliteratur
- Fachgebietsspezifische Terminologiesammlungen und -bände
- (Mehrsprachige) Datenbanken von normativen Einrichtungen
- Normentexte
- Spezialisierte Web-Verzeichnisse/Suchmaschinen, z. B. von Universitäten
- Seriöse Internetquellen
Selbstverständlich müssen Quellen stets sorgfältig geprüft werden. Um nur einige Aspekte der Quellenprüfung zu nennen: Welche Herausgeber stecken hinter den Informationen? Wie aktuell sind die Quellen?
Mehr zum dem Thema Terminologie beleuchte ich später in dieser Reihe.
Prozesse verstehen
Die bestehenden Prozesse zu kennen und zu verstehen ist ein wichtiger Kern der Arbeit eines jeden Mitarbeiters. Ein Technischer Redakteur hat noch dazu ein besonderes Interesse an der Prozesslandschaft, die sich um sein Aufgabengebiet spannt, da eine verständliche Kommunikation sehr durch standardisierte und (teil)automatisierte Prozesse profitiert.
Dafür empfiehlt es sich zunächst die existenten Prozesse zu analysieren und Antworten auf folgende brennende Fragen zu finden:
- Welche Prozesse gibt es?
- Wie sehen die dazugehörigen Workflows aus?
- Welche Tools werden verwendet?
- Wer ist verantwortlich für welche Ergebnisse?
- Welche Rollen gibt es?
- Wer ist der Ansprechpartner für wen?
- Welche Qualitätsstandards werden angelegt?
- Gibt es bereits Checklisten und Vorgaben?
- Wo und wodurch verzögert sich der Prozess?
- Welche Fehlerquellen gibt es?
- Wobei treten häufig Missverständnisse auf?
- Was sind potenzielle Prozessschwachstellen?
- Welche Aufgaben werden erledigt, die eigentlich nirgendwo dokumentiert sind?
- Wer weiß was?
In der Regel gibt es für bestehende Prozesse Prozessbeschreibungen und Workflow-Diagramme. Aber nicht jeder Prozess ist dokumentiert.
Dort liegt das Problem: Prozesse, die nicht dokumentiert sind, Ansprechpartner, die nicht benannt sind oder Rollen, die nicht vergeben wurden, führen zu allerlei Problemen und Missverständnissen.
Um diese Schwachstellen aufzuspüren, hilft ein Blick in die Besprechungsprotokolle, Reportings und in dokumentierte Projektnachbesprechungen. Bei allen vorausgesetzt, dass sie existieren.
Das Unternehmensorganigramm kann helfen, potenzielle Ansprechpartner und Informationswege aufzudecken.
Und schließlich ist, wie bei jeder Art Recherche die Befragung von Mitarbeitern und eine genaue Beobachtungsgabe unerlässlich.
Resümee
Die Recherche nimmt einen sehr großen Teil des Tätigkeitsumfangs eines Technischen Redakteurs ein und bildet dessen Arbeitsbasis. Sie ist das A und O der Technischen Kommunikation. Je gezielter die Fragen, desto genauer die Antworten und desto besser die Chancen auf verständliche Inhalte und grandiose Produkte.
Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren
Dieser Blogartikel gehört zu der Blogreihe:
