How to Create and Deliver Intelligent Information

Hereingefallen – Stolperfallen bei der Recherche

Großartige Möglichkeiten eröffnen sich durch intelligente Informationen. Bevor Informationen jedoch intelligent werden können, müssen sie zuerst recherchiert werden. Für das Verwalten, Verteilen und Abfragen intelligenter Informationen gibt es viele Methoden und Werkzeuge, für die Recherche jedoch nicht.

Wie dir die Auseinandersetzung mit intelligenter Informationsabfrage und  -bereitstellung ausgerechnet bei der Recherche helfen kann, zeigt folgende Geschichte, die sich tatsächlich zugetragen hat.

Recherchefall

Auf den Recherchetermin für ein neues Gerät hatte ich mich gründlich vorbereitet: Die Dokumentation des Vorgängergeräts, die Risikobeurteilung und das Pflichtenheft hatte ich gelesen, eine Checkliste mit Recherchefragen erarbeitet und die schriftliche Erlaubnis eingeholt, die Recherche mit einer Videokamera aufzuzeichnen, sodass ich keine umfangreichen Notizen zu schreiben brauchte.

Der Produktmanager begrüßte mich freundlich und führte mich direkt zum Entwickler und dem eigens bereitgestellten Gerät. Sofort begannen wir eine Variante der intelligenten Informationsabfrage und -bereitstellung – das Recherche-Interview. Der Entwickler präsentierte ein Meisterstück der Technik, ging detailliert auf alle Anschlüsse, Bedienelemente, Einstell- und Justage-Möglichkeiten ein und demonstrierte die Konfiguration und Durchführung der verschiedenen Funktionen.

Stunde um Stunde verging, während ich alles genau filmte und meine Checkliste mit Recherchefragen nach und nach abhakte. Der Entwickler erklärte jede Einzelheit bis hin zu einer Schaltfläche auf dem Touchscreen, mit der man die Bedienoberfläche für dreißig Sekunden deaktivieren konnte. Vor meinem geistigen Auge vervollständigte sich die Wer-macht-was-Matrix mit der Benutzergruppe „Reinigungspersonal“ und der Tätigkeit „putzt den Touchscreen“. Es lief perfekt.

Als letztes – das Batteriesymbol begann gerade im Display der Videokamera zu blinken – verkündete der Entwickler voller Stolz:

„Alles, was ich Ihnen heute an diesem alten Gerät gezeigt habe, gibt es in der nächsten Gerätegeneration nicht mehr. Das neue Gerät wird vollständig mit einer Client-Software bedient, die wir gerade extern programmieren lassen. Sie sollen ja die Softwareanleitung dazu erstellen …“

Ich hatte ein Problem.

Recherchefallen

Ich bin gleich in mehrere Fallen getappt, die ein Technischer Redakteur bei der Recherche unbedingt vermeiden muss:

  • Ich habe die vorab erhaltenen Unterlagen falsch interpretiert. Da in der Dokumentation des Vorgängergeräts keine Client-Software erwähnt wurde, habe ich im Vorfeld nicht nachgefragt, ob eine Geräte- oder eine Softwareanleitung erstellt werden soll.
  • Ich habe dem Entwickler zu viel Initiative überlassen. Dadurch habe ich die entscheidende Information zu spät bekommen.
  • Ich habe zugelassen, dass der Entwickler sich durch meine Videokamera dazu aufgefordert fühlte, etwas Filmreifes zu präsentieren.
  • Mein Hauptfehler aber war, dass ich die Perspektive des Entwicklers übernommen habe, der stets das Produkt und seine Merkmale und Eigenschaften im Zentrum sieht. Dieser Fehler ist besonders schwerwiegend, weil aus reinem Produktrecherchematerial dann später allzu leicht eine Produktbeschreibung entsteht – und keine nutzergerechte Anleitung, die nach Tätigkeiten, Aufgaben und Rollen gegliedert ist.

Zurück auf Start

Dass es dennoch eine gute Anleitung wurde, kam wie folgt:

  1. Ich war mittlerweile müde, hatte nur noch eine halbe Stunde Zeit und war nicht auf Softwarerecherche vorbereitet. Daher holte ich mein Smartphone heraus und verwendete die iiRDS-Spezifikation, die ich auf der Anfahrt im Zug durchgelesen hatte, als Checkliste für meine Recherche.
  2. Ich scrollte bis zu den Software-Domain-Klassen und stellte zu jedem Label meine Fragen an den Entwickler, was mir alle softwarerelevanten Informationen einbrachte.
  3. Die iiRDS-Hauptklasse InformationType erinnerte mich daran, die geplanten Rollen, Rechte und Freigaben der Softwarebenutzer zu erfragen.
  4. Der Abschnitt über funktionale Metadaten brachte mich darauf, die Zusendung einer Liste der Status-, Warn- und Fehlermeldungen der Software zu erbitten.

Mit diesen Informationen – und den später per E-Mail zugesendeten Screenshots – konnte ich eine vollständige und nutzerfreundlich nach Tätigkeiten gegliederte Anleitung erstellen, weil ich bei der Recherche keinen Aspekt vergessen hatte.

Fazit

Der iiRDS ist ein genialer Entwurf, denn die für die intelligente Informationsabfrage und -bereitstellung standardisierten Metadaten liefern auch eine strukturierte Vorlage für die Recherche. Gerade die Informationsart-Metadaten helfen dabei, Recherchefragen zu stellen, die nicht das Produkt, sondern seine Benutzer und deren Aufgaben, Rollen und Rechte betreffen. In der Entwicklerperspektive steht das Produkt im Zentrum. Der Technische Redakteur braucht den Blick aufs Ganze. Dabei kann er sich gerne vom universalen Ansatz des iiRDS leiten lassen.

Abbildung: iiRDS-Metadaten für Tätigkeiten mit Hard- und Software

Möchtest du noch mehr über Stolperfallen bei der Recherche wissen?

Weitere Stolperfallen bei der Recherche – und wie du diese (nicht nur mithilfe des iiRDS) umgehen kannst – lernst du auf der tekom-Jahrestagung im Fachvortrag TA04 kennen. Im iiRDS Café erhältst du Informationen und Präsentationen zu iiRDS aus erster Hand.


Roland Gleißner

Roland Gleißner

Roland Gleißner ist seit 2001 Technischer Redakteur, seit 2019 bei der tecteam GmbH, für die er sich auch im iiRDS-Konsortium engagiert. Sein Interesse gilt dem klugen Standardisieren, Modularisieren und Klassifizieren von Technischer Dokumentation.
Roland Gleißner

Letzte Artikel von Roland Gleißner

Like it? Share it! Spread the Word...

Sag uns jetzt deine Meinung per Kommentar!