If you’re like me, the word “traceability” probably sounds dry. As a programmer and user interface designer, I love immersing myself in design and implementation.
But at some point, you have to explain why the user interface is designed the way it is, whether to a critically questioning auditor, a stakeholder or a new team member.
And let’s be honest: that’s not always easy in retrospect. This is especially true when the design process takes a long time or involves several people. You end up racking your brains trying to remember why the button was placed there and wishing you had made a note of it somewhere.
This brings us to the topic at hand: traceability is one of the quieter secrets behind the design of safe and regulatory-compliant medical devices. But what exactly is traceability?
Traceability from a regulatory perspective
ISO 13485
Let’s start with ISO 13485:2016, the international standard for quality management systems for medical devices, which is harmonized in the EU – but also in Switzerland and Japan, for example.
Section 7.3.2 states:
“The organization shall plan and control the design and development of product. As appropriate, design and development planning documents shall be maintained and updated as the design and development progresses. During design and development planning, the organization shall document:
[…]
e) the methods to ensure traceability of design and development outputs to design and development inputs;
[…]”
In other words: For each design and development output (e.g., a drawing, specification, or user interface screens), the corresponding design and development input (e.g., a functional requirement, usability engineering requirement, or risk management result) must be clear.
In addition, Section 7.3.6 requires:
“Design and development verification shall be performed in accordance with planned and documented arrangements to ensure that the design and development outputs have met the design and development input requirements. […]“
Therefore, verification must be performed (and a record created) to prove that the design and development output meets the design and development inputs. In other words: that the device has been built correctly.
Section 7.3.7 continues:
“Design and development validation shall be performed in accordance with planned and documented arrangements to ensure that the resulting product is capable of meeting the requirements for the specified application or intended use. […]“
This requires validation that provides documented evidence that the device actually does what it is supposed to do (intended use) – in other words, that the correct device has been built.
In practice, this results in a kind of “circle”:
The intended use determines the design and development inputs. These inputs give rise to the design and development outputs. The outputs are then verified to show that they meet the inputs and validated to ensure that the product is fit for its intended use.
US FDA Quality System Regulation (QSR) – and what is changing with the new Quality Management System Regulation (QMSR)
Since the United States of America is an important market for many medical device manufacturers, I would also like to discuss the regulations that apply there. At the time of writing, the Quality System Regulation (QSR, 21 CFR Part 820) still applies in the US. In February 2026, after a two-year transition period, the Quality Management System Regulation (QMSR) will come into force.
The new QMSR was developed by the FDA with the aim of harmonizing the previous requirements for quality management systems for medical devices with ISO 13485:2016. It adopts the central principles of ISO 13485 and uses largely the same terminology.
Therefore, what we discussed in the previous section on ISO 13485 will also apply to the US in the future.
However, the QSR, which is currently still valid, is also closely related to these principles. It is based on the same basic idea of design controls, i.e., the traceable connection between design inputs, design outputs, verification, and validation – and thus follows the same traceability logic as ISO 13485, only in slightly different language.
We will refrain from taking a detailed look at the QSR, at this point. If you would like to read more about this, you will find the topics of design input/output as well as verification and validation in 21 CFR 820 Subpart C.
Why traceability is important – far beyond compliance
Now that we have an overview of the regulations, let’s return to the initial question:
Does traceability solve the problem of having to explain to auditors, stakeholders, or colleagues why, for example, a button is placed where it is?
The clear answer is no – or at least only partially.
Let me explain:
None of the relevant standards – neither the ISO 13485 (quality management) discussed above, nor IEC 62366-1 (usability), ISO 14971 (risk management) or the aforementioned US QSR/QMSR – require that every single design decision be documented.
What they do require, however, is traceability wherever a decision affects safety, performance, or usability.
This means:
- If a design decision is based on a functional, safety-related, or regulatory requirement, then its rationale must be documented.
- If a design change relates to a risk reduction, the connection between the risk, the measure, and the design output must be clearly traceable.
- If a UI element was part of a usability test or resulted from a research finding, this connection must also be documented.
Purely aesthetic or brand-specific design decisions do not have to be documented for regulatory purposes.
Why it can still be useful to document more
Nevertheless, it can be worthwhile to apply the principles of traceability beyond the minimum regulatory requirements.
This is because as soon as you briefly document even less safety-related design decisions – for example, “Why is this icon here?” or “Why was this workflow changed?” – a shared design memory is created.
This has several advantages:
- Clarity within the team: New team members understand more quickly why something is the way it is.
- Consistency: Designs remain consistent across versions, workflows, and even products, because decisions are justified and traceable.
- Time savings: Design discussions can be shortened.
- Quality: Decisions are made more consciously because they must be explainable.
There are two main disadvantages to this:
- Documentation takes time.
- A practical, lightweight system is needed to implement it.
Final thoughts
Whether a traceability system focused purely on regulatory requirements or documentation of design decisions that goes beyond this is the right choice for you and your product is up to you to decide.
From personal experience in over 400 successful projects, I can tell you that in practice, it has always proven worthwhile to document even minor design decisions in a simple manner. Too often, we have seen discussions about decisions that have already been made flare up again because the reasons for them have been lost – and in retrospect, this usually costs more time than the brief documentation at the moment of the decision.
The way I see it, especially in UI design, where creative freedom and regulatory strictness often collide, traceability is something like a common language between both worlds.
This brings us to the end of this article. If you would like to delve deeper into the subject, I cordially invite you to my webinar “Trace me if you can – How to keep track of medical device UI design decisions”.
In 30 minutes, you will gain advanced insights into:
- Traceability from a regulatory perspective
- Design decision pitfalls from real projects that teams repeatedly fall into
- Examples of the implementation of traceability and design rationale in practice
Thank you for reading – and if traceability initially also sounded like “dry” to you, I hope that you now think a little differently about it. 😉
