How to write user documentation for medical devices and software in 2026

Published: August 18, 2026.

Your device passed bench testing, software validation, and clinical trials. Then the FDA issued a deficiency letter because your Instructions for Use (IFU) did not trace warnings back to the risk analysis. Or the notified body flagged your label during the conformity assessment because a symbol did not match the current version of ISO 15223-1. These are not rare exceptions. They are the most common audit findings in medical device documentation, and they happen because teams treat labeling as a graphic artifact instead of a regulated user interface.

This article provides general guidance and does not constitute legal or regulatory advice. Always consult with your regulatory and legal teams for specific compliance requirements.

• What User Documentation Means in MedTech
• The Regulatory Landscape in 2026
• What Documentation You Actually Need to Produce
• Paper IFU vs. Electronic IFU: What the Comparison Actually Shows
• The Documentation Development Process
• Hidden Complexities Nobody Warns You About
• Scenarios: When This Works and When It Does Not
• Real Examples from the Industry
• Documentation Analytics: What to Measure
• Hybrid Approaches That Actually Work
• Conclusion

What User Documentation Means in MedTech

User documentation for medical devices is not a user manual in the consumer electronics sense. It is a regulated user interface that includes every piece of information the manufacturer supplies to ensure safe and effective use. Under EU MDR Article 2(49), labeling covers labels, IFUs, and any other information, indication, image, or symbol accompanying the device, including promotional materials. The FDA treats labeling under 21 CFR Part 801 and, for IVDs, Part 809. IEC 62366-1:2015+AMD1:2020 explicitly includes labeling and instructions as part of the user interface scope.

This means your IFU, quick-start guide, on-screen prompts, packaging inserts, and even the error messages in your software are all user documentation. They must be accurate, verifiable, consistent with the risk management file, and designed for the intended user under expected use conditions.

The Regulatory Landscape in 2026

FDA QMSR and Human Factors

On February 2, 2026, the FDA's Quality Management System Regulation (QMSR) took effect, replacing the previous Quality System Regulation and incorporating ISO 13485:2016 by reference. The FDA states that this action harmonizes the FDA's CGMP regulatory framework with that used by other regulatory authorities. This harmonization means that IEC 62366-1 conformance now aligns with FDA human factors expectations through ISO 13485 clause 7. The FDA recognizes IEC 62366-1 as a consensus standard, which means manufacturers can submit a Declaration of Conformity instead of re-explaining every detail.

However, the FDA did not find ISO 13485's labeling and packaging controls adequate, so QMSR Section 820.45 adds explicit requirements. As noted by regulatory analysts, the FDA wants to ensure that QMSR requires manufacturers to inspect the accuracy of device labels with respect to certain elements prior to release, documenting that inspection. This is more detailed than the current QSR and reflects the agency's view that labeling errors are not paperwork problems. They are patient safety problems.

EU MDR and the Information Requirements

MDR (EU) 2017/745 Annex I Section 23 exhaustively lists the minimum particulars for labels and IFUs: manufacturer identity, UDI, device name, intended purpose, lot or serial number, expiry date, warnings, precautions, and CE marking with the notified body number where relevant. Symbols must comply with ISO 15223-1. Deviating or outdated symbols lead directly to conformity assessment findings.

The IFU must be available in the official language of every Member State where the device is marketed, which can mean up to 24 language versions. Electronic instructions for use (eIFU) are permitted under Implementing Regulation (EU) 2021/2226, as revised by (EU) 2025/1234, but only under defined conditions and predominantly for professional users. For lay users, paper IFU remains the default rule. eIFU for lay users is subject to strict conditions under Regulation (EU) 2021/2226 and is not universally permitted.

IEC 62366-1 and the Usability Engineering File

IEC 62366-1:2015+AMD1:2020 defines a nine-step usability engineering process that produces auditable evidence at every stage. The standard requires a Use Specification documenting intended users, use environments, and user interface scope. From there, teams identify safety-related UI characteristics, known and foreseeable hazards, and hazard-related use scenarios. The process feeds into formative evaluations during development and a summative evaluation for validation.

The Usability Engineering File (UEF) is the evidence package that documents the entire process. Auditors typically probe four areas: use specification completeness, use error to hazard linkage, scenario selection rationale, and risk control hierarchy. If labeling shows up as the primary risk control without evidence that inherent safe design and protective measures were evaluated first, the finding is almost automatic.

What Documentation You Actually Need to Produce

The exact document set depends on device classification, intended user, and market, but most medtech companies produce the following core artifacts:

• Instructions for Use (IFU): The primary document describing intended purpose, device description, warnings, precautions, installation, operation, maintenance, cleaning, disposal, and manufacturer contact information. For active devices, this is often called the user manual.
• Label: Written, printed, or graphic information on the device or its packaging, including UDI, sterility indicators, and handling instructions.
• Quick Start Guide: A condensed version for experienced users, often required for devices with complex setup sequences.
• Software documentation: For Software as a Medical Device (SaMD), this includes in-app help, onboarding flows, and contextual error messages. IEC 62366-1 applies fully to SaMD.
• Training materials: Required when the device cannot be used safely without training, documented in the UI specification.
• Field Safety Notices (FSN): Issued when safety issues emerge post-market, communicating corrective actions to users.

Every document must trace back to the risk analysis per ISO 14971:2019 and the General Safety and Performance Requirements (GSPR) checklist. A warning on the label must point to a specific hazard in the risk management file. A contraindication in the IFU must match the clinical evaluation. If the traceability breaks, the audit fails.

Paper IFU vs. Electronic IFU: What the Comparison Actually Shows

The table reveals a pattern that teams often miss: eIFU is not a replacement for good information design. It is a distribution mechanism. If the underlying content is poorly structured, moving it to a website or app only makes the failure more visible and trackable.

The Documentation Development Process

Step 1: Anchor Everything in the Use Specification

Before writing a single sentence, document who will use the device, where, under what conditions, and with what prior knowledge. The Use Specification under IEC 62366-1 includes intended medical indication, patient population, user profile, use environment, and operating principle. Ambiguity here propagates downstream. If you define the user as "healthcare professional" without distinguishing between a radiologist and a radiology technician, your IFU will fail summative evaluation when one group cannot complete critical tasks.

Step 2: Map Hazards to Documentation, Not Around It

Teams often write the IFU first and then retrofit warnings into the risk analysis. This is backwards. The correct sequence is: identify hazards and hazardous situations from the use specification, derive hazard-related use scenarios, implement risk controls in this order: inherent safe design, protective measures, then information for safety. Only if the first two are infeasible does documentation become the control. When documentation is the control, you must validate that users actually read, understand, and act on it under realistic conditions.

Step 3: Write for the User, Not for the Auditor

This is where many teams stumble. The IFU must satisfy the auditor, but it is read by a stressed clinician at 2 AM or a patient with limited health literacy. Write in plain language. Use short sentences. Put warnings before the step they modify, not in a separate section nobody reads. Test readability with representative users, not with the regulatory team.

For software, this means contextual help beats comprehensive manuals. A tooltip that appears when the user hovers over a dosing field is more effective than a 40-page PDF that describes the same field on page 34. The FDA's human factors guidance and IEC 62366-1 both recognize that information timing and placement matter as much as content accuracy.

Step 4: Validate with Formative and Summative Evaluation

Formative evaluations are iterative tests during development: expert reviews, cognitive walkthroughs, and simulated-use testing. Their purpose is to surface issues while there is still time to change the design. Summative evaluation is the validation study with representative intended users on the final or near-final UI. The FDA expects at least 15 participants per distinct user group for summative validation. If a use error surfaces during summative testing that traces back to the UI, the summative evaluation becomes formative, the design changes, and you run the summative study again.

Step 5: Maintain Traceability and Version Control

Every warning, every symbol, every procedure must trace to a requirement, a hazard, and a verification result. Use a traceability matrix that spans users, hazards, controls, and evaluation results. When the risk analysis changes, the documentation must change. When the documentation changes, the translations must change. Version control is not a convenience. It is a regulatory requirement under both FDA QMSR and ISO 13485.

Hidden Complexities Nobody Warns You About

The Translation Trap

A 24-language IFU project for EU-wide distribution can cost between 50000 and 150000 dollars for initial translation, depending on complexity and specialist medical translator rates. But the real cost is not the first translation. It is the update cycle. Every risk analysis revision, every post-market surveillance finding, every software update can trigger a documentation change that must propagate through all language versions. Without translation memory and structured content management, you will translate the same paragraphs dozens of times. Teams that treat translation as a one-time project instead of a continuous process routinely underestimate lifetime translation costs by a factor of three.

Managing Translations: A Practical Workflow

1. Create a master terminology database (using a simple Excel sheet or a dedicated tool like SDL MultiTerm). For each key term (e.g., "alarm", "standby", "calibrate"), define the approved translation in every target language. Distribute this to all translators before they start.
2. Use translation memory (TM) – not per project, but as a central repository. Every time you revise a paragraph, update the TM. This ensures that recurring phrases are translated consistently and cheaper each time. Many TMSs (e.g., Memsource, Smartling) integrate with your CMS.
3. Segment updates by risk. Not every change requires a full re‑translation of all 24 languages. Classify changes as Critical (safety warnings), Major (new procedures), or Minor (typos). Critical and Major trigger full translation; Minor can be accumulated and released quarterly. Document this classification in your change control process.
4. Appoint a language lead for each market – a native speaker who reviews the translated IFU before publication. They also act as the point of contact for regulator queries in that country.
5. Automate version comparison. Use a diff tool (like DeltaXML or a simple script) to highlight changed sentences between two IFU versions. Send only the changed sentences to translators, along with the surrounding context (to preserve meaning). This reduces translation volume by 60–80% compared to full re‑translation.

The Searchability Gap

Users do not read IFUs linearly. They search. In a paper document, search means flipping pages. In an eIFU, it means typing keywords. If your user documentation uses "hypoglycemic event" in the IFU but the user searches for "low blood sugar," they will not find the answer. For software, if your error message says "Parameter out of range" without explaining which parameter or why, the user will call support. Good user manual requires controlled vocabulary, synonym mapping, and search analytics that show what users actually look for. Most medtech companies do not measure this.

How to close the searchability gap in practice

1. Build a synonym ring. For every critical concept in your IFU (e.g., "hypoglycemia"), list all terms a user might type ("low blood sugar", "low glucose", "sugar crash"). Embed these synonyms as metadata or hidden keywords in your eIFU platform. Most CMSs support synonym mapping via taxonomy plugins or search engine configuration.
2. Analyze search logs weekly. Export the "no results" queries from your eIFU search bar. If users search for "alarm reset" and your IFU calls it "silence alarm", you have a terminology mismatch. Update your content or synonym ring within 48 hours.
3. Implement faceted search. For complex devices, allow filtering by user role (clinician vs. patient), task (setup, troubleshooting, cleaning), and severity (safety warnings first). This reduces time‑to‑information from minutes to seconds.
4. Run quarterly findability tests. Recruit 5 representative users, give them 3 common tasks (e.g., "find what to do if the pump beeps"), and measure how long it takes. If average time exceeds 90 seconds, revise your information architecture.

Support Cost as a Documentation Metric

The true quality of your user documentation is measured in support tickets, not audit findings. A well-documented device should generate fewer "how do I" calls and more "my device is broken" calls. Track the ratio of documentation-related support tickets to total tickets. If more than 20% of your support volume is users asking how to perform tasks described in the IFU, your documentation has failed. The cost of a support call ranges from 15 to 50 dollars. For a device with 10000 users, a 10% reduction in documentation-related calls saves 15000 to 50000 dollars annually.

Post-Market Surveillance and Documentation Updates

Under MDR Article 83 and FDA 21 CFR Part 820.100, post-market surveillance data must feed back into the risk analysis and, by extension, into the documentation. If complaints reveal that users misinterpret a warning, you must update the IFU and assess whether the change requires a new summative evaluation. For eIFU, the update is fast. For paper IFU, you face a recall-or-field-correction decision. The FDA's recall database shows that labeling errors are a recurring cause of Class II and Class III recalls, and while Class III recalls are "discretionary," they still require resources, damage reputation, and trigger notified body scrutiny.

Total Cost of Ownership

The initial documentation budget covers writing, review, and first translation. The total cost of ownership includes: maintenance updates, regulatory submission support, summative usability testing, translation updates, eIFU platform hosting and validation, support ticket handling, field safety notice production, and audit defense. For a Class IIb device with a 10-year lifecycle, documentation TCO often exceeds 300000 dollars. Teams that budget only for the first draft discover the gap during the first post-market audit.

Scenarios: When This Works and When It Does Not

Scenario A: Class I Non-Sterile Device for Professional Use

A surgical instrument with no electronic components, intended for hospital operating rooms. The documentation requirement is minimal: a label with manufacturer data, sterility status if applicable, and basic handling instructions. An eIFU is permitted because the user is professional. A short IFU with clear cleaning and sterilization steps is sufficient. Heavy usability engineering is not required because the use errors are well-understood and the risk profile is low. This scenario works with a lean documentation process.

When it does not work: If the team skips the use specification because the device is "simple," they may miss that the instrument is also used in ambulatory surgery centers with different sterilization protocols. The IFU then contains incorrect reprocessing instructions, leading to nonconformities or patient infections.

Scenario B: Class III Active Implantable Device

A cardiac pacemaker with wireless connectivity, intended for implantation by electrophysiologists but monitored by cardiologists and patients via a mobile app. The documentation set includes: implantation instructions for the surgeon, programming guide for the cardiologist, patient manual for home monitoring, and in-app help for the mobile interface. Each user group requires a separate summative evaluation. The patient materials must be written at a 6th-grade reading level. The app help must work offline because patients may not have connectivity during emergencies.

When it does not work: If the company produces one generic IFU for all users, the surgeon finds irrelevant patient information, the patient receives technical implantation details they cannot understand, and the cardiologist cannot locate programming parameters quickly. The summative evaluation fails, the submission is delayed, and the company burns six months of runway.

Scenario C: Software as a Medical Device (SaMD)

A diagnostic algorithm that analyzes retinal scans to detect diabetic retinopathy, intended for use by primary care physicians. The documentation is entirely electronic: in-app onboarding, contextual help, and a PDF reference manual. Because the software is the device, every screen is part of the user interface and falls under IEC 62366-1. The documentation must explain not just how to use the software, but how to interpret results, when to refer to an ophthalmologist, and what the algorithm's sensitivity and specificity mean in practice.

When it does not work: If the team treats the software like a consumer app and relies on intuitive design without validated instructions, the primary care physician may miss a false negative because they do not understand the algorithm's limitations. The FDA flags this as a labeling deficiency because the IFU did not adequately describe the intended use and performance characteristics.

Scenario D: Home-Use Device with Lay Users

A continuous glucose monitor for diabetic patients, used at home without clinical supervision. The IFU must be in paper form per EU rules for lay users, written in plain language, with pictograms for key steps. The device must include audible alarms and on-screen prompts because users may not consult the IFU during a nocturnal hypoglycemic event. Usability engineering testing must include elderly users, users with visual impairments, and users with limited dexterity.

When it does not work: If the IFU is written at a college reading level, or if the alarms are documented only in the manual and not on the device itself, users will miss critical safety information. The FDA's MAUDE database and EU vigilance reports are full of adverse events where users did not understand or could not access the instructions.

Real Examples from the Industry

The FDA recall database provides concrete evidence of what happens when documentation fails. A NIST study analyzing medical device software recalls found that "missing information in user manual" was a distinct fault category, alongside logic errors and calculation faults. In one analyzed case, a required system function was missing from the final implementation because the documentation provided was insufficient to install or operate the product.

Between 2020 and 2023, Class I recalls included reasons ranging from incorrect insulin dosage displays to mechanical ventilation loss, many traceable to user interface and documentation failures. A 2023 analysis showed that 22% of Class I recalls were for heart pumps, 17% for general IV pumps, and 15% for ventilators. These are devices where user interaction is continuous and high-stakes, and where unclear documentation directly translates to patient harm.

In the EU, the most common audit finding related to documentation is not a missing symbol or an untranslated paragraph. It is a label that cannot be traced back to the risk analysis and the GSPR checklist. Whatever appears on the label must be verifiable backwards: a warning points to a measure from the risk management file, a symbol to the harmonized version of ISO 15223-1, a mandatory particular to the matching point in MDR Annex I Section 23.

A documented case from the recall management field illustrates the cascading cost of documentation failure. A global point-of-care diagnostics company initiated a voluntary recall of an in-home blood monitoring system after identifying potential malfunctions. The company advised users to discontinue use while developing a software fix. Over two years, the company invested heavily in R&D to correct accuracy issues, but the FDA ultimately determined the proposed software updates were insufficient. The recall required full product discontinuation, patient transition to alternative devices, and global reverse logistics. The root cause analysis revealed that early-stage usability engineering testing had not adequately simulated real-world home use conditions, and the IFU did not contain sufficient troubleshooting guidance for the errors users actually encountered.

Documentation Analytics: What to Measure

Most medtech companies track documentation metrics that matter to regulators: review completion dates, approval signatures, and translation status. Few track metrics that matter to users. The following KPIs close that gap:

• Task success rate from summative evaluation: The percentage of critical tasks users complete correctly without assistance. Target: 100% for safety-critical tasks (a reasonable internal target might be 100%, but this is not a regulatory requirement).
• Time-to-information: How long it takes a user to locate a specific piece of information in the IFU or eIFU. Measure this with eye-tracking or clickstream analysis.
• Documentation-related support ticket ratio: Percentage of support tickets caused by unclear or missing documentation. Target: below 10% (a reasonable internal target might be below 10%, but this is not a regulatory requirement).
• Translation update lag: Time between a source documentation change and the last language version update. Target: under 30 days for safety-critical changes (a reasonable internal target might be under 30 days, but this is not a regulatory requirement).
• eIFU access rate vs. paper request rate: For devices with eIFU, the ratio of digital accesses to paper requests. If paper requests exceed 20%, the eIFU platform is not meeting user needs.
• Post-market documentation change frequency: Number of IFU revisions per year driven by complaints or vigilance reports. A rising trend signals upstream design or risk management problems.

How to implement these KPIs without a data team

• Task success rate: During summative evaluation, record video of each participant. Count the number of critical tasks completed without assistance. If any task falls below 95% success, flag it for redesign. For post‑market tracking, embed a short survey in your eIFU or app asking "Did you find the information you needed?" – a simple Yes/No widget gives you a real‑time success score.
• Time‑to‑information: Use heatmaps and click‑tracking (e.g., Hotjar, Matomo) on your eIFU web pages. Identify which pages users spend more than 30 seconds on – those are candidates for re‑writing or better navigation.
• Support ticket ratio: Tag each incoming ticket with a category "Documentation‑related" (user says "I couldn't find it" or "the manual says something else"). Calculate the ratio monthly. If it exceeds 15%, schedule a documentation review within two weeks.
• Translation update lag: Set up a version comparison script that checks the last modified date of source files against each translated file. Alert the team when any language version is more than 14 days behind. Automate this using simple CI/CD pipelines or CMS workflow rules.
• eIFU vs. paper request rate: Count paper IFU requests per 1000 units sold. If this number grows quarter over quarter, investigate whether your eIFU platform is failing (broken links, poor mobile experience, or login barriers).
• Post‑market change frequency: Link your complaint database to your documentation change log. When a recurring complaint pattern emerges (e.g., same use error), automatically flag the corresponding IFU section for review. This closes the post‑market feedback loop.

These metrics require investment in analytics infrastructure, but they pay back by preventing the far more expensive downstream costs of recalls, audit findings, and support escalations.

Hybrid Approaches That Actually Work

The binary choice between paper and electronic documentation is false. The most effective systems are hybrid:

• Paper quick-start guide + eIFU reference manual: The user gets a 2-page laminated card with essential setup steps and a QR code linking to the full IFU. This satisfies MDR requirements for paper availability while leveraging eIFU for depth.
• In-app guidance + downloadable PDF: Software devices embed contextual help for routine tasks and provide a PDF for reference. The PDF is version-controlled and linked to the app's build number.
• Layered information architecture: Critical safety information appears on the device label and in the first page of the IFU. Detailed procedures follow. Troubleshooting and technical specifications are in the eIFU. This respects the risk control hierarchy: the most important information is closest to the user.

The key principle is that the user should not have to choose between formats. The format should match the context: paper for emergencies and offline use, electronic for search and updates, on-device for immediate warnings.

Conclusion

Writing user documentation for medical devices is not a technical writing exercise. It is a regulated safety activity that sits at the intersection of usability engineering, risk management, and global regulatory compliance. The FDA QMSR and EU MDR have both tightened expectations in 2026, and IEC 62366-1 provides the process framework that connects documentation to patient safety.

The most common failures are not grammatical errors or missing pages. They are traceability gaps between the risk analysis and the IFU, inadequate user testing with representative participants, and underestimation of the total cost of ownership for documentation maintenance and translation. Good user documentation is validated, not just reviewed. It is measured by support tickets and task success rates, not by page count. And it is treated as a user interface, not as an afterthought.

Teams that get this right build documentation systems that pass audits, reduce support costs, and prevent recalls. Teams that get it wrong discover the cost during the first deficiency letter, the first support escalation, or the first field safety notice. The difference is not the writer's skill. It is the organization's understanding that in medtech, documentation is part of the device.