Senior Technical Writer · tekom-certified
Structure for technical information — readable for people, robust under regulation, reliable for AI.
I analyze and structure product information for machinery, MedTech and other regulated environments. Everything else builds on this groundwork: the four focus areas below show where it leads, with information architecture as the connecting discipline.
I am your single point of contact. I analyze and structure your content, and then take on the task at hand. I am based in Switzerland, where I work as an employee; for organizations abroad, I work freelance.
Focus areas
In practice these areas overlap. Information architecture holds them together: it decides how content is divided, named, related and found. The focus areas outline fields of work and interest, not a catalog of every specialist service.
Information architecture at the center, around it the four focus areas and their nine fields. Select an area or a field to see why it matters, what it covers, how I work on it and what follows when something changes.
Connecting discipline
Information architecture
Every assignment starts with the same groundwork: understand context, content and processes, then structure the content. Information architecture holds the four focus areas together.
The layer beneath the text that makes content findable, reusable and machine-readable. I treat it as a field in its own right, not as a by-product of writing.
In technical documentation, that means topic structures, metadata and terminology that hold up in XML-based systems. In safety and regulatory work, it means that a hazard identified in the risk assessment can be traced to the warning in the manual. In learning design, it shapes the sequence of modules.
Why: Content can only be found, reused and checked when its structure is decided rather than left to chance.
What: Topic structures, content models, metadata and navigation, and the links that lead from a hazard in the risk assessment to the warning in the manual.
How: I analyze the existing content and processes, then divide, name and relate the content so that shared parts are maintained once and variants stay under control.
What if: When a product, a regulation or a system changes, a clear structure shows which modules are affected, instead of every document having to be searched.
Glossaries, controlled terminology, taxonomies and knowledge graphs that give a term one clear meaning across documents, languages and systems.
Why: When one term means different things in different documents, people and AI systems draw different conclusions from the same content.
What: Glossaries, controlled terminology, taxonomies and knowledge graphs that give each term one clear meaning across documents, languages and systems.
How: I work out the concept: which terms exist, how they relate and what they must not mean. The technical implementation is not part of my scope.
What if: When AI systems retrieve content, a defined meaning limits how far an answer can drift from the source.
Product information that has to be correct, complete and traceable.
Operating manuals, assembly and maintenance instructions and other product information for machinery, MedTech and other regulated technical environments, created in XML-based systems such as SCHEMA ST4, FrameMaker and Sirius CMS and guided by IEC/IEEE 82079-1.
Why: Operating manuals and other product information are part of the product. In regulated environments, they have to be correct, complete and usable.
What: Operating manuals and assembly and maintenance instructions for machinery, MedTech and other regulated technical environments, created in XML-based systems and guided by IEC/IEEE 82079-1.
How: I write and revise content in the documentation system in use, in line with the regulatory requirements and with variants planned from the start.
What if: When a product variant is added, content that is already structured in modules is extended rather than copied and rewritten.
Safety-related product information, risk assessment documentation and CE coordination with reference to the Machinery Directive, the Machinery Regulation, ISO 12100, ISO 13849 and IEC 62061.
My role is documentation, coordination and professional support. Testing, certification and the legal declaration of conformity remain with the manufacturer and the responsible bodies.
Why: A hazard identified in the risk assessment has to reach the warning in the operating manual without being lost or changed on the way.
What: Safety-related product information, risk assessment documentation and CE coordination with reference to the Machinery Directive, the Machinery Regulation, ISO 12100, ISO 13849 and IEC 62061.
How: I analyze the context and link hazards, measures and warnings into an evidence chain that follows the regulatory requirements.
What if: When a requirement changes, the links show which warnings are affected. Testing, certification and the declaration of conformity remain with the manufacturer and the responsible bodies.
What changes for documentation when AI retrieves content, summarizes it and takes part in creating it — in substance and in regulation.
Content that stays accurate when AI systems retrieve, summarize or reuse it: clear modules, explicit metadata, cited sources and defined limits on what automation may change.
Why: AI systems retrieve, summarize and reuse content without knowing its context. Content has to carry that context itself.
What: Clear modules, explicit metadata, cited sources and defined limits on what automation may change.
How: I define where AI may work and where people check the result, and I prepare content so that its meaning and sources stay attached to it in a shared content base.
What if: When an AI system summarizes a module, its sources and limits travel with it, so the result can be checked against the original.
How the EU AI Act, the Cyber Resilience Act and related rules affect what product information has to contain, and how documentation teams can prepare their content and processes.
Why: The EU AI Act, the Cyber Resilience Act and related rules change what product information has to contain.
What: How these rules affect documentation, and how documentation teams can prepare their content and processes.
How: I read the requirements from the perspective of documentation, define checkpoints for work with AI and connect each requirement to the content that addresses it.
What if: When a rule takes effect or changes, the connections show which content and processes are affected. The legal assessment and conformity remain with the manufacturer and the responsible bodies.
Formats that help people understand technical knowledge and apply it.
Compact microlearning formats and accompanying micro-videos on technical and regulatory topics, currently deepened through continuing education at the Digital Learning Institute.
Why: Knowing that a rule exists is not the same as being able to apply it. Technical and regulatory knowledge has to be learned in steps that can be put into practice.
What: Compact microlearning formats and accompanying micro-videos on technical and regulatory topics.
How: I set learning objectives and a sequence, write the content and use the dramaturgy of TV work for the videos. I am currently deepening this through continuing education at the Digital Learning Institute.
What if: When the subject changes, a modular course is updated module by module instead of being rebuilt.
Visual explanations, storytelling and experience in video and TV production, applied to technical subjects that are hard to grasp from text alone.
Why: Some technical subjects are hard to grasp from text alone: movements, sequences, spatial relations.
What: Visual explanations, storytelling and video, applied to technical subjects.
How: I use storytelling, dramaturgy, picture and sound from my TV and video work, in learning formats and in communication for decision-makers.
What if: When a sequence is shown instead of described, the text can stay short and concentrate on what the picture cannot show.
Product communication that remains technically accurate, from positioning and launch texts to PR, and advice on how sales can benefit from existing technical documentation and how to present technical subjects to executives without technical expertise. Based on my experience in media, PR and marketing communication since 1994.
Why: Technical documentation often contains information that sales can use, written for a different audience.
What: Product communication that remains technically accurate, and advice on how sales can benefit from existing technical documentation and how to present technical subjects to executives without technical expertise.
How: I start from the existing documentation and from the decisions that sales and executives have to make, based on my experience in media, PR and marketing communication since 1994.
What if: When sales and documentation draw on the same content, product statements stay consistent with the technical facts.
How I work
Every assignment starts from the same groundwork. What follows depends on the task: a content pooling concept, a variant model, an evidence chain, an operating manual, a microlearning module or advice for sales. Writing is one of these tasks, not the destination of all of them.
The groundwork sits at the core. Each task adds a layer around it, and the requirements of the departments involved frame the whole. The connections between departments and tasks are typical examples; in an assignment, they follow from the groundwork.
Each layer is described as a task further down, each with a simulated sample assignment as a silent film.
Capture context, content, processes and requirements: who needs the information at which moment, which regulations apply, which sources and systems exist and which functions are involved.
Divide and name content, define terminology and metadata, and establish links, for example from the risk assessment to the warning.
After the groundwork, the work branches out. An assignment can include one of these tasks or several.
Concepts for terms, relations and taxonomies that give content an unambiguous meaning for people and AI systems. I work on the concept; the technical implementation is not part of my scope.
Concepts that bring the requirements of R&D, V&V, regulatory and quality back to a shared content base and a shared change base, while maintaining separate documents for each department and/or requirement, as defined by Regulatory, Machine Safety Compliance and Quality.
Read more: Who can judge an AI model output? · EN 18286 certifies the system, not the company (AI TechDoc Press, free sign-up to read)
Models for product and document variants, so that shared content is maintained once and differences are controlled deliberately.
Evidence chains that connect requirements, hazards, measures and content, also for a quality management system that uses AI. Testing, certification and the declaration of conformity remain with the manufacturer and the responsible bodies.
Read more: EN 18286 certifies the system, not the company (AI TechDoc Press, free sign-up to read) · Write it Safe. Prove it Safe. (newsletter)
Create or revise content in the documentation system in use and in the right format — from a topic to an operating manual or a specialist article.
Microlearning modules and accompanying micro-videos on technical and regulatory subjects, with learning objectives, sequence and the dramaturgy of TV work.
Advice on how sales can benefit from existing technical documentation and how to present technical subjects to executives without technical expertise.
Seven short films without sound, one for each task. Each film starts with the same groundwork and then follows one simulated assignment. The industries and situations are invented; none of them is a client project. The figure in gold stands for me.
Simulated example — not a client project
Assignment: A manufacturer plans an AI assistant for its service technicians. In the documents, one control device has several names, and a term for a different function is used as a synonym.
Four words for one button. One of them means something else.
1 · Understand
The documents say emergency stop, E-stop, emergency stop button and emergency switching off. The assistant’s answers contradict each other.
2 · Structure
The terms are collected and compared. Emergency stop becomes the preferred term with its synonyms; emergency switching off names a different function and is kept apart.
Semantics and ontology
Relations are defined: is part of, warns against, is checked by. A small concept network forms around the term.
Semantics and ontology
With unambiguous terms, the assistant can now find the passages that belong together.
Handover
The concept goes to the manufacturer’s implementation team. The technical implementation is not part of my scope.
One meaning, for people and for machines.
Simulated example — not a client project
Assignment: A manufacturer of medical and laboratory equipment keeps separate documents for R&D, V&V, regulatory and quality. The same content is maintained four times and drifts apart.
Four departments. One product. Four versions of the same warning.
1 · Understand
Each function keeps its own documents, and each of them is required. The same warning appears in all four, worded differently each time.
2 · Structure
The content is divided into modules and named. The same modules show up in all four documents.
Content pooling
The shared modules move into one shared content base. A shared change base records every change to them.
Content pooling
The four documents stay separate, as Regulatory, Machine Safety Compliance and Quality define them. They take their shared modules from the content base.
Content pooling
A change comes in. It passes the change base once and reaches every document that uses the module, traceably.
One change, checked once. Separate documents, consistent content.
Simulated example — not a client project
Assignment: A machine builder supplies one machine in three sizes, two voltage versions and with several options. Each combination has its own, nearly identical operating manual.
Twelve operating manuals. One correction. Made in only some of them.
1 · Understand
For each combination of size, voltage and option, a manual was copied and adapted. Every correction has to be made in every copy.
2 · Structure
Content that applies to every variant is marked as shared. Content that differs is marked as variant-specific.
Variant management
A variant model describes the features that make the difference: size, voltage, option. Each variant-specific module is assigned to its features.
Variant management
A configuration is selected. The manual for exactly this machine is compiled from the shared content and the matching modules.
Variant management
A correction in the shared content is made once and reaches every variant.
Maintain once. Differ deliberately.
Simulated example — not a client project
Assignment: For a machine under the Machinery Regulation, the manufacturer wants every warning in the operating manual to be traceable to its hazard, its protective measure and its evidence.
A warning in the manual. Nobody can say any more where it comes from.
1 · Understand
The risk assessment, the operating manual and the test records exist side by side, without references to each other.
2 · Structure
Every hazard gets an identifier. The identifiers appear again in the measures, the warnings and the test records.
Evidence chain
A chain forms: requirement, hazard, protective measure, warning, evidence. Between measure and warning, one link is missing.
Evidence chain
The gap goes back to the manufacturer, who closes it. The chain is complete.
Scope
Testing, certification and the declaration of conformity remain with the manufacturer and the responsible bodies.
Every warning has an origin. Every origin has its evidence.
Simulated example — not a client project
Assignment: A new machine needs an operating manual in the manufacturer’s documentation system. The sources are scattered: design data, notes from development and the risk assessment.
The machine is finished. The operating manual is not.
1 · Understand
Talks with development show who will read the manual, in which situation and with what prior knowledge. The sources are collected.
2 · Structure
An outline forms. Topics are named and the terminology is defined.
Writing
The topics are written: instructions, figures and the safety messages derived from the risk assessment.
Review
Development reviews the content. Marked passages are revised and checked again.
Output
The manual is produced from the documentation system in the required formats, in print and on screen.
The digital twin was complete. Now the user information is too: written, reviewed, released.
Simulated example — not a client project
Assignment: A manufacturer has changed its procedure for isolating its machines safely. The service technicians are to learn the change without a full training day.
The procedure has changed. The habit has not.
1 · Understand
The technicians work on site, with little time and a tablet. The analysis settles what they need to be able to do afterwards.
2 · Structure
Learning objectives are written as observable actions. Three short units form a sequence.
Learning design
A storyboard for a micro-video is drawn shot by shot, with the dramaturgy of TV work.
Learning design
Questions check each step. A wrong answer first leads to a hint, then to the solution.
Result
A microlearning module of about seven minutes is ready, for the tablet on site.
Learn briefly. Act safely.
Simulated example — not a client project
Assignment: A manufacturer’s sales team is to explain to an executive without a technical background what a safety function contributes.
The technology is good. The conversation is not.
1 · Understand
Sales presents the function in technical terms. They do not reach the executive.
2 · Structure
The existing technical documentation already answers much of what the executive needs to know. These passages are identified.
Advice
I advise the sales team on how to use this content in the conversation.
Result
In the next conversation, the executive hears what the function means for the business.
What the documentation says can also help to sell.
I describe the methods behind many of these tasks in the newsletters Cut Complexity — Create Clarity and Write it Safe. Prove it Safe. and on AI TechDoc Press.
Publications
Public work from AI TechDoc that shows how I approach a subject. Client documents and internal company material are confidential and are not published here.
Blueprint · AI TechDoc Knowledge
A plan for the content lifecycle when AI takes part in creating and maintaining documentation. It describes eleven stages, one gate and two boundaries, and asks who decides at each stage and which responsibilities remain with people.
Context card · AI TechDoc Knowledge
A pathway map of what has to be in place when an AI agent acts outside its permitted boundary in IT systems, IoT fleets, OT and on machines: how the breach is detected, contained and followed by a controlled return to operation, with routes for four roles.
AI TechDoc is a group of publications on technical documentation, regulation and AI. This website stands on its own: it presents my professional profile and links to selected public content there.
AI TechDoc Knowledge Published
Reference knowledge: glossaries, context cards and blueprints.
AI TechDoc Press Published
Articles, analyses and editorial perspective, published as a newsletter on Substack.
AI TechDoc Learning Planned
Learning paths, exercises and, later, courses. A preview of the AI learning path is available on AI TechDoc Knowledge; the courses are in preparation.
Concept work
Concepts I develop alongside my project work. Some are still in development, others are published as blueprints. They describe ways of structuring documentation and its context; none of them is a confirmation of conformity.
A concept for an operating manual aligned with the EU Machinery Regulation that also takes the Cyber Resilience Act into account. It is a working concept, not a confirmation of conformity.
An extended concept for risk assessment and its documentation, currently being developed.
I advise on two questions:
Six blueprints on AI TechDoc Knowledge, each a thinking model for technical documentation. The pages name me as the author.
How technical writers structure complexity before they write
The reader’s stack: how readers take in, understand and act on technical information
The machine’s stack: how documentation becomes knowledge that people and AI systems can use
A cascade of definitions for the network behind every AI answer
Eleven stages, one gate and two boundaries for documentation that the machine also reads
Five thinking operations behind four images: the fenced pasture, rumination, milk and dung, and cattle trails on the slope
Professional Development
Completed qualifications and courses currently in progress.
Certification from tekom, the professional association for technical communication.
TÜV course on technical documentation for medical devices, completed in December 2022.
Training at CExpert (Dipl.-Ing. (FH) Ulrich Kessels), course modules I to V certified by TÜV Rheinland, completed in May 2026.
Continuing education in learning design, part of my focus on EdTech.
Continuing education on the use of AI in e-learning.
About
I am a Senior Technical Writer and have worked in technical documentation since 2015. The groundwork came earlier: from 2010, I worked on maritime safety documentation as a technical coordinator, in 2013 I completed six months of tekom training, and in 2014 I received my tekom certification as a technical writer.
Media, PR and marketing communication have been part of my work since 1994. From 1994 to 1996 and again in 2000, I worked in communication and PR for NGOs. From 1997, I worked for a broadcaster, and in 1998 I completed a journalism traineeship in TV editorial work and magazine program production. In 2000 and 2001, I worked on TV program development for the pan-Arab region.
In technical documentation, I have worked for machinery, MedTech and other regulated technical environments. My work covers information architecture, technical documentation, CE coordination, machine safety, safety-related product information, risk assessment and regulatory documentation. In MedTech, this meant working not only with the Medical Device Regulation (MDR) but also with the requirements of the US Food and Drug Administration (FDA) and of China’s National Medical Products Administration (NMPA). I have supported MDR certifications.
My editorial background — journalism, storytelling, e-learning formats, and video and TV production — complements my work in technical communication; it is not its foundation. The principles of tekom and of technical communication differ considerably from editorial TV work: structure, unambiguous instructions and safety-related information follow rules of their own. The editorial side adds attention to the reader, to sequence and to what an image can explain better than a paragraph. Today I bring both together in microlearning formats and micro-videos on technical and regulatory topics.
As a publisher and editor, I publish articles and analyses on AI TechDoc Press and contribute to AI TechDoc Knowledge, where blueprints, context cards and a preview of the AI learning path are available. My two LinkedIn newsletters, “Cut Complexity — Create Clarity” and “Write it Safe. Prove it Safe.,” and the case notes on Technical Documentation Expertise show how I work on real topics.
Career — lines of development
Collaboration & Contact
The form of collaboration I offer depends on where the organization is based. In both cases, you work directly with me, not with a team.
From now until Christmas 2026
Short projects
From January 2027
Medium- and long-term projects
Germany · United Kingdom · United States · other countries
For organizations in Germany, the UK, the US and other countries, I work on a project-based freelance basis only.
Short-, medium- and long-term projects
In Switzerland, I work as an employee on a fixed-term or permanent basis, for short-, medium- and long-term projects.
Write to me by email. The button opens your email program.