Senior Technical Writer · tekom-zertifiziert
Struktur für technische Information – lesbar für Menschen, belastbar unter Regulierung, verlässlich für KI.
Ich analysiere und strukturiere Produktinformation für Maschinen, MedTech und andere regulierte Umgebungen. Darauf baut alles Weitere auf: Die vier Schwerpunkte unten zeigen, wohin diese Grundlage führt, verbunden durch die Informationsarchitektur.
Ich bin Ihre zentrale Ansprechperson. Ich analysiere und strukturiere Ihre Inhalte und übernehme danach die jeweilige Aufgabe. Ich lebe in der Schweiz und arbeite dort im Angestelltenverhältnis, für Organisationen im Ausland freiberuflich.
Schwerpunkte
In der Praxis überschneiden sich diese Bereiche. Die Informationsarchitektur hält sie zusammen: Sie legt fest, wie Inhalte gegliedert, benannt, verknüpft und gefunden werden. Die Schwerpunkte umreißen Arbeits- und Interessensfelder, keinen Katalog sämtlicher Spezialleistungen.
In der Mitte die Informationsarchitektur, darum die vier Schwerpunkte und ihre neun Fachgebiete. Wählen Sie einen Schwerpunkt oder ein Fachgebiet, um zu sehen, warum es wichtig ist, was dazugehört, wie ich daran arbeite und was folgt, wenn sich etwas ändert.
Verbindende Disziplin
Informationsarchitektur
Jeder Auftrag beginnt mit derselben Grundlage: Kontext, Inhalte und Prozesse verstehen, dann die Inhalte strukturieren. Die Informationsarchitektur hält die vier Schwerpunkte zusammen.
Die Ebene unter dem Text, die Inhalte auffindbar, wiederverwendbar und maschinenlesbar macht. Ich behandle sie als eigenständiges Fachgebiet, nicht als Nebenprodukt des Schreibens.
In der technischen Dokumentation bedeutet das Topic-Strukturen, Metadaten und Terminologie, die in XML-basierten Systemen tragfähig sind. In der Sicherheits- und Regulierungsarbeit bedeutet es, dass sich eine in der Risikobeurteilung ermittelte Gefährdung bis zum Warnhinweis in der Anleitung zurückverfolgen lässt. Im Learning Design bestimmt sie die Abfolge der Module.
Warum: Inhalte lassen sich nur finden, wiederverwenden und prüfen, wenn ihre Struktur festgelegt ist und nicht dem Zufall überlassen bleibt.
Was: Topic-Strukturen, Inhaltsmodelle, Metadaten und Navigation sowie die Verknüpfungen, die von einer Gefährdung in der Risikobeurteilung zum Warnhinweis in der Anleitung führen.
Wie: Ich analysiere vorhandene Inhalte und Prozesse und gliedere, benenne und verknüpfe die Inhalte dann so, dass gemeinsame Teile einmal gepflegt werden und Varianten kontrollierbar bleiben.
Was, wenn: Ändern sich ein Produkt, eine Vorschrift oder ein System, zeigt eine klare Struktur, welche Module betroffen sind, statt dass jedes Dokument durchsucht werden muss.
Glossare, kontrollierte Terminologie, Taxonomien und Wissensgraphen, die einem Begriff über Dokumente, Sprachen und Systeme hinweg eine eindeutige Bedeutung geben.
Warum: Bedeutet ein Begriff in verschiedenen Dokumenten Verschiedenes, ziehen Menschen und KI-Systeme aus denselben Inhalten unterschiedliche Schlüsse.
Was: Glossare, kontrollierte Terminologie, Taxonomien und Wissensgraphen, die jedem Begriff über Dokumente, Sprachen und Systeme hinweg eine eindeutige Bedeutung geben.
Wie: Ich erarbeite das Konzept: welche Begriffe es gibt, wie sie zusammenhängen und was sie nicht bedeuten dürfen. Die technische Umsetzung gehört nicht zu meinem Leistungsumfang.
Was, wenn: Rufen KI-Systeme Inhalte ab, begrenzt eine festgelegte Bedeutung, wie weit sich eine Antwort von der Quelle entfernen kann.
Produktinformation, die richtig, vollständig und nachvollziehbar sein muss.
Betriebsanleitungen, Montage- und Wartungsanleitungen und weitere Produktinformationen für Maschinen, MedTech und andere regulierte technische Umgebungen, erstellt in XML-basierten Systemen wie SCHEMA ST4, FrameMaker und Sirius CMS und ausgerichtet an IEC/IEEE 82079-1.
Warum: Betriebsanleitungen und andere Produktinformationen gehören zum Produkt. In regulierten Umgebungen müssen sie richtig, vollständig und verwendbar sein.
Was: Betriebs-, Montage- und Wartungsanleitungen für Maschinen, MedTech und andere regulierte technische Umgebungen, erstellt in XML-basierten Systemen und ausgerichtet an IEC/IEEE 82079-1.
Wie: Ich erstelle und überarbeite Inhalte im eingesetzten Redaktionssystem, abgestimmt auf die regulatorischen Anforderungen und mit Varianten, die von Anfang an mitgeplant sind.
Was, wenn: Kommt eine Produktvariante hinzu, werden bereits modular aufgebaute Inhalte erweitert, statt kopiert und neu geschrieben.
Sicherheitsbezogene Produktinformation, Dokumentation der Risikobeurteilung und CE-Koordination mit Bezug auf Maschinenrichtlinie, Maschinenverordnung, ISO 12100, ISO 13849 und IEC 62061.
Meine Rolle umfasst Dokumentation, Koordination und fachliche Unterstützung. Prüfung, Zertifizierung und die rechtliche Konformitätserklärung liegen beim Hersteller und den zuständigen Stellen.
Warum: Eine in der Risikobeurteilung ermittelte Gefährdung muss beim Warnhinweis in der Betriebsanleitung ankommen, ohne unterwegs verloren zu gehen oder sich zu verändern.
Was: Sicherheitsbezogene Produktinformation, Dokumentation der Risikobeurteilung und CE-Koordination mit Bezug auf Maschinenrichtlinie, Maschinenverordnung, ISO 12100, ISO 13849 und IEC 62061.
Wie: Ich analysiere den Kontext und verknüpfe Gefährdungen, Maßnahmen und Warnhinweise zu einer Nachweiskette, die den regulatorischen Anforderungen folgt.
Was, wenn: Ändert sich eine Anforderung, zeigen die Verknüpfungen, welche Warnhinweise betroffen sind. Prüfung, Zertifizierung und Konformitätserklärung liegen beim Hersteller und den zuständigen Stellen.
Was sich für die Dokumentation ändert, wenn KI Inhalte abruft, zusammenfasst und an ihrer Erstellung beteiligt ist – inhaltlich und regulatorisch.
Inhalte, die korrekt bleiben, wenn KI-Systeme sie abrufen, zusammenfassen oder wiederverwenden: klare Module, explizite Metadaten, belegte Quellen und festgelegte Grenzen dafür, was Automatisierung verändern darf.
Warum: KI-Systeme rufen Inhalte ab, fassen sie zusammen und verwenden sie wieder, ohne ihren Kontext zu kennen. Inhalte müssen diesen Kontext selbst mitbringen.
Was: Klare Module, explizite Metadaten, belegte Quellen und festgelegte Grenzen dafür, was Automatisierung verändern darf.
Wie: Ich lege fest, wo KI arbeiten darf und wo Menschen das Ergebnis prüfen, und bereite Inhalte so auf, dass Bedeutung und Quellen in einem gemeinsamen Content-Stamm mit ihnen verbunden bleiben.
Was, wenn: Fasst ein KI-System ein Modul zusammen, gehen Quellen und Grenzen mit, sodass sich das Ergebnis am Original prüfen lässt.
Wie der EU AI Act, der Cyber Resilience Act und verwandte Regelwerke beeinflussen, was Produktinformation enthalten muss, und wie Dokumentationsteams ihre Inhalte und Prozesse darauf vorbereiten können.
Warum: Der EU AI Act, der Cyber Resilience Act und verwandte Regelwerke verändern, was Produktinformation enthalten muss.
Was: Wie sich diese Regelwerke auf die Dokumentation auswirken und wie Dokumentationsteams ihre Inhalte und Prozesse darauf vorbereiten können.
Wie: Ich lese die Anforderungen aus Sicht der Dokumentation, lege Prüfpunkte für die Arbeit mit KI fest und verknüpfe jede Anforderung mit den Inhalten, die sie umsetzen.
Was, wenn: Tritt eine Regel in Kraft oder ändert sie sich, zeigen die Verknüpfungen, welche Inhalte und Prozesse betroffen sind. Die rechtliche Bewertung und die Konformität liegen beim Hersteller und den zuständigen Stellen.
Formate, mit denen Menschen technisches Wissen verstehen und anwenden.
Kompakte Microlearning-Formate und begleitende Micro-Videos zu technischen und regulatorischen Themen, derzeit vertieft durch Weiterbildung am Digital Learning Institute.
Warum: Zu wissen, dass es eine Regel gibt, heißt noch nicht, sie anwenden zu können. Technisches und regulatorisches Wissen braucht Lernschritte, die sich umsetzen lassen.
Was: Kompakte Microlearning-Formate und begleitende Micro-Videos zu technischen und regulatorischen Themen.
Wie: Ich lege Lernziele und Abfolge fest, schreibe die Inhalte und nutze für die Videos die Dramaturgie der TV-Arbeit. Derzeit vertiefe ich das durch Weiterbildung am Digital Learning Institute.
Was, wenn: Ändert sich das Thema, wird ein modularer Kurs Modul für Modul aktualisiert, statt neu gebaut zu werden.
Visuelle Erklärungen, Storytelling und Erfahrung in Video- und TV-Produktion, angewendet auf technische Themen, die sich allein über Text schwer erschließen.
Warum: Manche technischen Themen erschließen sich allein über Text schwer: Bewegungen, Abläufe, räumliche Zusammenhänge.
Was: Visuelle Erklärungen, Storytelling und Video, angewendet auf technische Themen.
Wie: Ich nutze Storytelling, Dramaturgie, Bild und Ton aus meiner TV- und Videoarbeit, in Lernformaten und in der Kommunikation für Entscheider.
Was, wenn: Wird ein Ablauf gezeigt statt beschrieben, kann der Text kurz bleiben und sich auf das konzentrieren, was das Bild nicht zeigen kann.
Produktkommunikation, die technisch korrekt bleibt – von der Positionierung über Launch-Texte bis zur PR –, sowie Beratung dazu, wie der Vertrieb von vorhandener technischer Dokumentation profitiert und wie sich technische Themen gegenüber Geschäftsführungen ohne Fachkenntnisse vermitteln lassen. Grundlage ist meine Erfahrung in Medien, PR und Marketingkommunikation seit 1994.
Warum: Technische Dokumentation enthält oft Informationen, die der Vertrieb nutzen kann, geschrieben für ein anderes Publikum.
Was: Produktkommunikation, die technisch korrekt bleibt, sowie Beratung dazu, wie der Vertrieb von vorhandener technischer Dokumentation profitiert und wie sich technische Themen gegenüber Geschäftsführungen ohne Fachkenntnisse vermitteln lassen.
Wie: Ich gehe von der vorhandenen Dokumentation aus und von den Entscheidungen, die Vertrieb und Geschäftsführung treffen müssen. Grundlage ist meine Erfahrung in Medien, PR und Marketingkommunikation seit 1994.
Was, wenn: Greifen Vertrieb und Dokumentation auf dieselben Inhalte zu, bleiben Produktaussagen im Einklang mit den technischen Fakten.
Arbeitsweise
Jeder Auftrag beginnt mit derselben Grundlage. Was danach entsteht, hängt von der Aufgabe ab: ein Content-Pooling-Konzept, ein Variantenmodell, eine Nachweiskette, eine Betriebsanleitung, ein Microlearning-Modul oder eine Beratung für den Vertrieb. Schreiben ist eine dieser Aufgaben, nicht das Ziel aller.
Im Kern liegt die Grundlage. Jede Aufgabe legt eine Schicht darum, und die Anforderungen der beteiligten Abteilungen rahmen das Ganze ein. Die Verbindungen zwischen Abteilungen und Aufgaben sind typische Beispiele; in einem Auftrag ergeben sie sich aus der Grundlage.
Jede Schicht ist weiter unten als Aufgabe beschrieben, jeweils mit einem simulierten Beispielauftrag als Stummfilm.
Kontext, Inhalte, Prozesse und Anforderungen erfassen: wer die Information in welchem Moment braucht, welche Regelwerke gelten, welche Quellen und Systeme vorliegen und welche Funktionen beteiligt sind.
Inhalte gliedern und benennen, Terminologie und Metadaten festlegen und Bezüge herstellen, etwa von der Risikobeurteilung zum Warnhinweis.
Nach der Grundlage fächert sich die Arbeit auf. Ein Auftrag kann eine dieser Aufgaben umfassen oder mehrere.
Konzepte für Begriffe, Beziehungen und Taxonomien, die Inhalten für Menschen und KI-Systeme eine eindeutige Bedeutung geben. Ich arbeite konzeptionell; die technische Implementierung gehört nicht zu meinem Umfang.
Konzepte, die die Anforderungen von R&D, V&V, Regulatory und Quality auf einen gemeinsamen Content-Stamm und einen gemeinsamen Change-Stamm zurückführen, während getrennte Unterlagen je Abteilung und/oder Anforderung bestehen bleiben, so wie Regulatory, Machine Safety Compliance und Quality sie festlegen.
Nachzulesen: Who can judge an AI model output? · EN 18286 certifies the system, not the company (AI TechDoc Press, Englisch, lesbar nach kostenloser Anmeldung)
Modelle für Produkt- und Dokumentvarianten, damit gemeinsame Inhalte einmal gepflegt und Abweichungen gezielt gesteuert werden.
Nachweisketten, die Anforderungen, Gefährdungen, Maßnahmen und Inhalte verbinden, auch für ein Qualitätsmanagementsystem, in dem KI eingesetzt wird. Prüfung, Zertifizierung und Konformitätserklärung bleiben beim Hersteller und den zuständigen Stellen.
Nachzulesen: EN 18286 certifies the system, not the company (AI TechDoc Press, Englisch, lesbar nach kostenloser Anmeldung) · Write it Safe. Prove it Safe. (Newsletter)
Inhalte erstellen oder überarbeiten, im jeweiligen Redaktionssystem und im passenden Format – vom Topic über die Betriebsanleitung bis zum Fachbeitrag.
Microlearning-Module und begleitende Micro-Videos zu technischen und regulatorischen Themen, mit Lernzielen, Abfolge und der Dramaturgie aus der TV-Arbeit.
Beratung dazu, wie der Vertrieb von vorhandener technischer Dokumentation profitiert und wie sich technische Themen gegenüber Geschäftsführungen ohne Fachkenntnisse vermitteln lassen.
Sieben kurze Filme ohne Ton, einer je Aufgabe. Jeder Film beginnt mit derselben Grundlage und folgt dann einem simulierten Auftrag. Branchen und Situationen sind erfunden; keiner davon ist ein Kundenprojekt. Die goldene Figur steht für mich.
Simuliertes Beispiel – kein Kundenprojekt
Auftrag: Ein Hersteller plant einen KI-Assistenten für seine Servicetechniker. In den Unterlagen hat ein Bedienelement mehrere Namen, und ein Begriff für eine andere Funktion wird als Synonym verwendet.
Vier Wörter für einen Taster. Eines davon meint etwas anderes.
1 · Verstehen
In den Unterlagen steht Not-Halt, E-Stop, Not-Halt-Taster und Not-Aus. Die Antworten des Assistenten widersprechen sich.
2 · Strukturieren
Die Begriffe werden gesammelt und verglichen. Not-Halt wird Vorzugsbenennung mit ihren Synonymen; Not-Aus bezeichnet eine andere Funktion und wird getrennt geführt.
Semantik und Ontologie
Beziehungen werden festgelegt: ist Teil von, warnt vor, wird geprüft durch. Um den Begriff entsteht ein kleines Begriffsnetz.
Semantik und Ontologie
Mit eindeutigen Begriffen kann der Assistent jetzt die Stellen finden, die zusammengehören.
Übergabe
Das Konzept geht an das Implementierungsteam des Herstellers. Die technische Umsetzung gehört nicht zu meinem Umfang.
Eine Bedeutung, für Menschen und für Maschinen.
Simuliertes Beispiel – kein Kundenprojekt
Auftrag: Ein Hersteller von Medizin- und Laborgeräten führt getrennte Unterlagen für R&D, V&V, Regulatory und Quality. Dieselben Inhalte werden viermal gepflegt und laufen auseinander.
Vier Abteilungen. Ein Produkt. Vier Fassungen desselben Warnhinweises.
1 · Verstehen
Jede Funktion führt eigene Unterlagen, und jede davon ist gefordert. Derselbe Warnhinweis steht in allen vier, jedes Mal anders formuliert.
2 · Strukturieren
Die Inhalte werden in Module gegliedert und benannt. Dieselben Module tauchen in allen vier Unterlagen auf.
Content-Pooling
Die gemeinsamen Module wandern in einen gemeinsamen Content-Stamm. Ein gemeinsamer Change-Stamm erfasst jede Änderung daran.
Content-Pooling
Die vier Unterlagen bleiben getrennt, so wie Regulatory, Machine Safety Compliance und Quality sie festlegen. Ihre gemeinsamen Module beziehen sie aus dem Content-Stamm.
Content-Pooling
Eine Änderung kommt herein. Sie durchläuft einmal den Change-Stamm und erreicht nachvollziehbar jede Unterlage, die das Modul verwendet.
Eine Änderung, einmal geprüft. Getrennte Unterlagen, einheitliche Inhalte.
Simuliertes Beispiel – kein Kundenprojekt
Auftrag: Ein Maschinenbauer liefert eine Maschine in drei Baugrößen, zwei Spannungsvarianten und mit mehreren Optionen. Jede Kombination hat eine eigene, fast gleiche Betriebsanleitung.
Zwölf Betriebsanleitungen. Eine Korrektur. Nur in einigen davon umgesetzt.
1 · Verstehen
Für jede Kombination aus Baugröße, Spannung und Option wurde eine Anleitung kopiert und angepasst. Jede Korrektur muss in jeder Kopie einzeln erfolgen.
2 · Strukturieren
Inhalte, die für alle Varianten gelten, werden als gemeinsam markiert, abweichende Inhalte als variantenspezifisch.
Variantenmanagement
Ein Variantenmodell beschreibt die Merkmale, die den Unterschied machen: Baugröße, Spannung, Option. Jedes variantenspezifische Modul wird seinen Merkmalen zugeordnet.
Variantenmanagement
Eine Konfiguration wird gewählt. Aus den gemeinsamen Inhalten und den passenden Modulen entsteht die Anleitung für genau diese Maschine.
Variantenmanagement
Eine Korrektur in den gemeinsamen Inhalten erfolgt einmal und erreicht alle Varianten.
Einmal pflegen. Gezielt abweichen.
Simuliertes Beispiel – kein Kundenprojekt
Auftrag: Für eine Maschine nach der Maschinenverordnung möchte der Hersteller jeden Warnhinweis der Betriebsanleitung auf seine Gefährdung, seine Schutzmaßnahme und seinen Nachweis zurückführen können.
Ein Warnhinweis in der Anleitung. Niemand kann mehr sagen, woher er kommt.
1 · Verstehen
Risikobeurteilung, Betriebsanleitung und Prüfnachweise liegen nebeneinander, ohne Verweise aufeinander.
2 · Strukturieren
Jede Gefährdung erhält eine Kennung. Die Kennungen tauchen in den Maßnahmen, den Warnhinweisen und den Prüfnachweisen wieder auf.
Nachweiskette
Eine Kette entsteht: Anforderung, Gefährdung, Schutzmaßnahme, Warnhinweis, Nachweis. Zwischen Maßnahme und Warnhinweis fehlt ein Glied.
Nachweiskette
Die Lücke geht an den Hersteller, der sie schließt. Die Kette ist vollständig.
Abgrenzung
Prüfung, Zertifizierung und Konformitätserklärung bleiben beim Hersteller und den zuständigen Stellen.
Jeder Warnhinweis hat einen Ursprung. Jeder Ursprung hat seinen Nachweis.
Simuliertes Beispiel – kein Kundenprojekt
Auftrag: Eine neue Maschine braucht eine Betriebsanleitung im Redaktionssystem des Herstellers. Die Quellen sind verstreut: Konstruktionsdaten, Notizen aus der Entwicklung und die Risikobeurteilung.
Die Maschine ist fertig. Die Betriebsanleitung noch nicht.
1 · Verstehen
Gespräche mit der Entwicklung zeigen, wer die Anleitung liest, in welcher Situation und mit welchem Vorwissen. Die Quellen werden gesammelt.
2 · Strukturieren
Eine Gliederung entsteht. Topics werden benannt, die Terminologie wird festgelegt.
Redaktion
Die Topics werden geschrieben: Handlungsanweisungen, Abbildungen und die Sicherheitshinweise aus der Risikobeurteilung.
Prüfung
Die Entwicklung prüft die Inhalte. Markierte Stellen werden überarbeitet und erneut geprüft.
Ausgabe
Die Anleitung wird aus dem Redaktionssystem in den geforderten Formaten ausgegeben, gedruckt und am Bildschirm.
Der digitale Zwilling war vollständig. Jetzt ist es auch die Nutzerinformation: geschrieben, geprüft, freigegeben.
Simuliertes Beispiel – kein Kundenprojekt
Auftrag: Ein Hersteller hat sein Verfahren zum sicheren Freischalten seiner Maschinen geändert. Die Servicetechniker sollen die Änderung lernen, ohne einen ganzen Schulungstag dafür einzuplanen.
Das Verfahren hat sich geändert. Die Gewohnheit nicht.
1 · Verstehen
Die Techniker arbeiten vor Ort, mit wenig Zeit und einem Tablet. Die Analyse klärt, was sie danach können müssen.
2 · Strukturieren
Lernziele werden als beobachtbare Handlungen formuliert. Drei kurze Einheiten bilden eine Abfolge.
Learning Design
Ein Storyboard für ein Micro-Video entsteht Einstellung für Einstellung, mit der Dramaturgie aus der TV-Arbeit.
Learning Design
Fragen prüfen jeden Schritt. Eine falsche Antwort führt zuerst zu einem Hinweis, dann zur Lösung.
Ergebnis
Ein Microlearning-Modul von etwa sieben Minuten ist fertig, für das Tablet vor Ort.
Kurz lernen. Sicher handeln.
Simuliertes Beispiel – kein Kundenprojekt
Auftrag: Der Vertrieb eines Herstellers soll einer Geschäftsführung ohne technischen Hintergrund erklären, was eine Sicherheitsfunktion leistet.
Die Technik ist gut. Das Gespräch nicht.
1 · Verstehen
Der Vertrieb stellt die Funktion in Fachbegriffen vor. Sie erreichen die Geschäftsführung nicht.
2 · Strukturieren
Die vorhandene technische Dokumentation beantwortet bereits vieles, was die Geschäftsführung wissen muss. Diese Stellen werden ermittelt.
Beratung
Ich berate den Vertrieb dazu, wie er diese Inhalte im Gespräch nutzt.
Ergebnis
Im nächsten Gespräch erfährt die Geschäftsführung, was die Funktion für das Unternehmen bedeutet.
Was in der Dokumentation steht, kann auch beim Verkaufen helfen.
Die Methodik hinter vielen dieser Aufgaben beschreibe ich in den Newslettern Cut Complexity — Create Clarity und Write it Safe. Prove it Safe. sowie auf AI TechDoc Press.
Publikationen
Öffentliche Inhalte von AI TechDoc, die zeigen, wie ich ein Thema angehe. Kundendokumente und interne Unternehmensunterlagen sind vertraulich und werden hier nicht veröffentlicht.
Blueprint · AI TechDoc Knowledge
Ein Plan für den Content-Lebenszyklus, wenn KI an der Erstellung und Pflege von Dokumentation beteiligt ist. Er beschreibt elf Phasen, ein Gate und zwei Grenzbereiche und fragt, wer in jeder Phase entscheidet und welche Verantwortung beim Menschen bleibt.
Context Card · AI TechDoc Knowledge
Eine Pathway-Map dazu, was bereitstehen muss, wenn ein KI-Agent in IT-Systemen, IoT-Flotten, der OT oder an Maschinen außerhalb seiner zulässigen Grenzen handelt: wie der Vorfall erkannt und eingedämmt wird und wie der Betrieb kontrolliert wieder aufgenommen wird, mit Routen für vier Rollen.
AI TechDoc ist eine Gruppe von Publikationen zu technischer Dokumentation, Regulierung und KI. Diese Website ist davon unabhängig: Sie zeigt mein berufliches Profil und verweist auf ausgewählte öffentliche Inhalte.
AI TechDoc Knowledge Veröffentlicht
Fachwissen zum Nachschlagen: Glossare, Context Cards und Blueprints.
AI TechDoc Press Veröffentlicht
Artikel, Analysen und redaktionelle Einordnung, erscheint als Newsletter auf Substack (in englischer Sprache).
AI TechDoc Learning Geplant
Lernpfade, Übungen und künftig Kurse. Eine Vorschau des KI-Lernpfads (in englischer Sprache) ist auf AI TechDoc Knowledge verfügbar; die Kurse sind in Vorbereitung.
Konzeptarbeit
Konzepte, die ich neben meiner Projektarbeit entwickle. Einige sind noch in Arbeit, andere sind als Blueprints veröffentlicht. Sie beschreiben, wie sich Dokumentation und ihr Kontext strukturieren lassen; keines davon ist eine Bestätigung der Konformität.
Ein Konzept für eine an der EU-Maschinenverordnung orientierte Betriebsanleitung, das auch den Cyber Resilience Act berücksichtigt. Es handelt sich um ein Arbeitskonzept, nicht um eine Bestätigung der Konformität.
Ein erweitertes Konzept für die Risikobeurteilung und ihre Dokumentation, das sich derzeit in Entwicklung befindet.
Ich berate zu zwei Fragen:
Sechs Blueprints auf AI TechDoc Knowledge, jeder ein Denkmodell für die technische Dokumentation. Auf den Seiten bin ich als Autorin genannt.
Wie Technische Redakteure Komplexität strukturieren, bevor sie schreiben
Der Reader’s Stack: wie Leser technische Information aufnehmen, verstehen und danach handeln
Der Machine’s Stack: wie aus Dokumentation Wissen wird, das Menschen und KI-Systeme nutzen können
Eine Kaskade von Definitionen für das Netzwerk hinter jeder KI-Antwort
Elf Stufen, ein Gate und zwei Grenzbereiche für die Dokumentation, die auch von der Maschine gelesen wird
Fünf Denkprozesse hinter vier Bildern: die eingezäunte Weide, das Wiederkäuen, Milch und Mist sowie Viehpfade am Hang
Weiterbildung
Abgeschlossene Qualifikationen und Fortbildungen sowie laufende Kurse.
Zertifizierung durch die tekom, den Fachverband für technische Kommunikation.
TÜV-Fortbildung zur technischen Dokumentation für Medizinprodukte, abgeschlossen im Dezember 2022.
Ausbildung bei CExpert (Dipl.-Ing. (FH) Ulrich Kessels), von TÜV Rheinland zertifizierte Lehrgangsmodule I bis V, abgeschlossen im Mai 2026.
Weiterbildung im Learning Design als Teil meines EdTech-Schwerpunkts.
Weiterbildung zum Einsatz von KI im E-Learning.
Über mich
Ich bin Senior Technical Writer und arbeite seit 2015 in der technischen Dokumentation. Die Grundlagen dafür entstanden früher: Ab 2010 habe ich in der technischen Koordination maritime Sicherheitsdokumentation bearbeitet, 2013 eine sechsmonatige tekom-Fortbildung absolviert und 2014 die tekom-Zertifizierung als technische Redakteurin erhalten.
Medien, PR und Marketingkommunikation gehören seit 1994 zu meiner Arbeit. Von 1994 bis 1996 und im Jahr 2000 war ich für NGOs in Kommunikation und PR tätig. Ab 1997 habe ich für einen Sender gearbeitet, 1998 ein Volontariat in Journalismus, TV-Redaktion und Magazinproduktion abgeschlossen und 2000 – 2001 TV-Programme für den panarabischen Raum entwickelt.
In der technischen Dokumentation habe ich für Maschinen, MedTech und andere regulierte technische Umgebungen gearbeitet. Meine Arbeit umfasst Informationsarchitektur, technische Dokumentation, CE-Koordination, Maschinensicherheit, sicherheitsbezogene Produktinformation, Risikobeurteilung und regulatorische Dokumentation. In der Medizintechnik betraf das nicht nur die Medizinprodukteverordnung (MDR), sondern auch die Anforderungen der US-amerikanischen Food and Drug Administration (FDA) und der chinesischen National Medical Products Administration (NMPA). Ich habe MDR-Zertifizierungen unterstützt.
Mein redaktioneller Werdegang – Journalismus, Storytelling, E-Learning-Formate sowie Video- und TV-Produktion – ergänzt meine Arbeit in der technischen Kommunikation; er ist nicht ihre Grundlage. Die Prinzipien der tekom und der technischen Kommunikation unterscheiden sich deutlich von der redaktionellen TV-Arbeit: Struktur, eindeutige Handlungsanweisungen und sicherheitsbezogene Information folgen eigenen Regeln. Die redaktionelle Seite bringt den Blick auf die lesende Person, auf die Reihenfolge und darauf, was ein Bild besser erklärt als ein Absatz. Heute verbinde ich beides in Microlearning-Formaten und Micro-Videos zu technischen und regulatorischen Themen.
Als Herausgeberin und Redakteurin veröffentliche ich Artikel und Analysen auf AI TechDoc Press und leiste Beiträge zu AI TechDoc Knowledge, wo Blueprints, Context Cards und eine Vorschau des KI-Lernpfads (in englischer Sprache) verfügbar sind. Meine beiden LinkedIn-Newsletter „Cut Complexity — Create Clarity“ und „Write it Safe. Prove it Safe.“ sowie die Case Notes unter Technical Documentation Expertise zeigen, wie ich an realen Themen arbeite.
Werdegang – Entwicklungslinien
Zusammenarbeit & Kontakt
Welche Form der Zusammenarbeit ich anbiete, hängt vom Standort der Organisation ab. In beiden Fällen arbeiten Sie direkt mit mir, nicht mit einem Team.
Ab sofort bis Weihnachten 2026
Kurze Projekte
Ab Januar 2027
Mittel- und langfristige Projekte
Deutschland · Großbritannien · USA · weitere Länder
Für Organisationen in Deutschland, Großbritannien, den USA und weiteren Ländern arbeite ich ausschließlich freiberuflich und projektbezogen.
Kurz-, mittel- und langfristige Projekte
In der Schweiz arbeite ich bei kurz-, mittel- und langfristigen Projekten im Angestelltenverhältnis, befristet oder unbefristet.
Schreiben Sie mir eine E-Mail. Die Schaltfläche öffnet Ihr E-Mail-Programm.