By Eugen Stoicov, Senior Product Designer, Vienna. Published 2026-05-20.
In regulated products a design system stops being a consistency project. It becomes the place where a safety decision only has to be made once.
The usual case for a design system is speed and consistency. Ship faster, look the same, stop arguing about button radii. Fine reasons, and in regulated software they are not the important one.
Here the component is where a decision about risk gets settled. Once. How a destructive action confirms, how an error states what actually failed, how a field that feeds a regulated record marks itself as one. Get that right in the pattern and every screen inherits it. Get it wrong in forty screens and you have forty problems wearing the same visual style.
In consumer software an inconsistent pattern costs a moment of confusion. In clinical or compliance work it costs a wrong action by someone who was reasonably confident they knew what the control did, because it did something else on the previous screen.
That reframes the boring parts of systems work. A naming convention is not tidiness. It is the difference between two things that behave identically being called the same thing, and a user learning a rule that turns out to be false one screen later.
This is the part that changes the arithmetic. In a validated product, a new pattern is not free at the moment you draw it. It carries documentation, review and a share of the testing burden, and it keeps carrying them for as long as it exists.
So the question in front of a new component is not whether it is nicer. It is whether it is worth validating. Most are not. A system in this context is judged on what it refuses, which is an awkward thing to present at a design review and the right answer anyway.
I built the Haelsi system so a new service could launch without a new set of patterns. Same instinct, lower stakes. The version of that discipline in regulated work has teeth, because the cost of a redundant pattern shows up in a test protocol rather than a code review.
Most system documentation describes the component. Anatomy, states, spacing, do and do not. Useful. It also fails the first time someone meets a case the pattern did not anticipate, which is every interesting case.
What they need is the reasoning. Why this confirmation exists, what it is protecting against, which decision it encodes. Given that, a competent designer can extend the pattern correctly into a situation nobody documented. Given only the anatomy, they will copy the shape and lose the point.
It is easy to let the library become the work. The library is legible, it demos well, and nobody is unhappy with you while you are building it.
The deliverable is the product a team can ship without reopening a settled question. If people are still deciding case by case how a risky action confirms, the system has not done its job, however complete the component set looks.
Topics: Design systems, Compliance, Healthcare.