Why Medical Device Localization Fails — and What Good Looks Like

EU MDR language requirements, IEC 62366 multilingual usability testing, and medical device GUI translation validation: what a complete localization programme actually requires

This article draws on Creative Navy's project work in medtech UX, spanning practice management software, surgical equipment, ventilators, blood pumps, infusion systems, and patient monitoring devices, including Class II and Class III regulated products. Our work in this sector covers clinical environments including the ICU and operating theatre, designing for surgeons, nurses, and biomedical engineers. Dennis Lenard, who leads this work at Creative Navy, is the author of User Interface Design For Medical Devices And Software, the practitioner reference on UX design for medical devices and software. Our approach integrates IEC 62366 usability engineering requirements and FDA Human Factors guidance as structural inputs to the design process, not post-hoc compliance activities.

The brief arrives looking like a translation job. You have a glucose monitor approved for the German, French, and Dutch markets. The translation agency has delivered reviewed, back-translated versions of every string. The compliance team has signed off on the IFU documentation. The project looks complete.

Then you open the German UI on the target device. Two button labels have been truncated because the hardware viewport did not account for German compound nouns. The French IFU reads at a Grade 11 level; most of your users are elderly patients with type 2 diabetes managing their condition at home. The Dutch version displays glucose readings in mg/dL. The Netherlands uses mmol/L. The conversion factor is 18.

Every translation is correct. The localization is broken. The situation becomes even more challenging when devices generate text dynamically rather than displaying fixed strings, a problem explored in AI-generated medical device interfaces and the EU AI Act localization problem.

This is not a rare situation. It is the standard outcome of treating medical device localization as a translation project with a linguistic quality step. Translation is one part of what localization requires and not the part most likely to produce patient harm.

Text expansion is the localization problem teams discover late, because it is invisible during the translation phase and highly visible the moment translated content is rendered on a real device.

Design implication: Localization-ready UI design requires budgeting for expansion before translation begins, not after. The standard practice is to design for the target language worst case, typically German for EU markets, and treat English as the compressed version.

Correct medical terminology in the target language. Consistent use of approved terminology across all device elements. Back-translation validation for safety-critical content. Layout accommodation for text expansion.

Validated by: Certified medical translator + domain SME review + linguistic quality audit + rendered layout review on target device hardware.

Measurement units matching local clinical convention (mmol/L vs mg/dL, Celsius vs Fahrenheit, European date formats). Reference ranges and normal-value thresholds expressed in locally understood terms. Risk framing that matches the clinical culture of the target market.

Validated by: In-country clinical review + regulatory check against local EU Member State guidance (EU MDR 2017/745, Article 10) + symbol comprehension testing.

Reading level appropriate for the actual user population. Numeracy burden reduced to the minimum required for safe operation. Action instructions specific enough to produce the correct response without clinical training.

Validated by: Readability assessment in target language + comprehension testing with lay users matching the intended use population + IEC 62366-1 summative evaluation with language-representative participants.

Hospital-deployed devices and home monitoring devices have fundamentally different localization requirements. The difference is not degree of difficulty, it is structure.

When a patient manages their glucose at home with a CGM, no clinical mediation chain exists. The patient reads the display, interprets the number, and decides whether to eat, inject, or call for help. A localization failure that a clinician would catch produces direct patient action.

A device can be accurately translated and still fail the people it was designed to protect. The translation is one layer. Understanding whether the translation communicates is a different question entirely.

The mmol/L versus mg/dL split is one of the most documented localization failure points in home medical devices. The conversion factor is 18. A reading of 5.5 mmol/L equals 99 mg/dL. Misreading units produces an 18-fold interpretation error.

The right resolution is recognising that numeric precision and clinical urgency are two different communication goals. A device that communicates "treat low glucose now" via a risk-zone indicator operates correctly regardless of which numeric unit system the user knows.

IEC 62366-1 requires summative usability evaluation with representative users. FDA recommends a minimum of 15 participants per distinct user group. Linguistic and cultural differences can constitute distinct user groups.

The pragmatic approach used in practice is risk stratification: full summative testing in the highest-risk language environments, with documented rationale for equivalence in lower-risk cases.

The validation methodology for Layer 3 (health literacy adaptation) remains genuinely unresolved. Readability tools like Flesch-Kincaid do not port cleanly to other languages. IEC 62366-1 requires summative evaluation but does not define comprehension success for multilingual devices.

EU MDR 2017/745 Article 10 requires device information in the official language(s) of each Member State where marketed. Only 16 of 27 Member States have published specific GUI guidance.

It requires summative usability evaluation with representative users and classifies localization failures as foreseeable use errors. It does not specify minimum participant counts per language version.

For short UI strings up to 10 characters, expansion reaches 100 to 200%. German compound nouns do not wrap, creating overflow risks.

Conversion factor is 18. Misreading produces an 18-fold error. Design should separate numeric reading from clinical action required.

No explicit requirement. Industry practice treats translated UIs as substantially equivalent, but this is a risk acceptance posture.

25 to 75% of EU adults have limited health literacy. For home-use devices, it is a primary design constraint.

Creative Navy designs medical device interfaces that perform correctly in the environments they are actually used in, including multilingual markets. See our work on medical device UX design, medical device information architecture benchmarking, and how UX design improves adoption of healthcare technology.