Medical imaging · Ongoing
Role
Freelance design systems lead
Period
2026, ongoing
Scope
Hardening, component support, system audit
The client ships medical hardware with on-device interfaces, inside a regulated environment. Their designer works fast and uses AI to produce screens. The design system wasn’t keeping up, so screens filled with one-off components and pieces borrowed from other internal systems.
They also want to be AI-ready, and nothing in the current system supported that.
Hardening. I check new screens against the existing design system and replace one-offs with shared components, so the same element doesn’t live as a copy on every screen.
Local components first. Repeated elements built once, so a change happens in one place. Quick relief for the designer, and a base that holds up whatever comes next.
Audit. Icons need a full rework, the token and variable structure needs an overhaul for theming and automation, and several text components are redundant. Spacing and color were left alone. They work within what a regulated product needs.
Code parity. I rebuilt the button against the Vue component library engineering actually ships. The click state is called “pressed” instead of “active”, and focus is a separate boolean, because a button can be focused and hovered at the same time.
Accessibility notes. Icon-only buttons need an accessible name supplied by hand, and the library’s ripple effect still needs checking against reduced-motion settings.
Button
interaction-state
default
hover
pressed
loading
disabled
is-focused
true
false
Rule: is-focused is never valid with disabled or loading. Those buttons leave the tab order, so a focus ring there means something is wired wrong.
The button’s Figma properties, modeled on how the browser and the component library behave.
A moving target. The designs changed fast, so components had to be built underneath work that wasn’t settled yet. Lock things down too early and they’re wrong next week. Wait too long and the one-offs pile up.
Patches versus a rebuild. The work was set up as support hours, but the system needed more than patches. Saying that out loud meant pushing a bigger conversation upward without knowing how it would land.
Unclear hours. The available hours weren’t clear early on, which made it hard to plan anything at the system level.
Vendor defaults. The component library makes choices of its own. Its ripple effect and its missing accessible-name prop for icon-only buttons both needed a decision.
Relief first. Local components gave the designer one place to update repeated elements right away, without waiting on any bigger decision.
Raise scope early. I flagged the patch-versus-rebuild question directly instead of letting the work drift into a slow rebuild nobody agreed to.
Model the platform. The button’s states follow how the browser and the component library actually behave. One documented rule keeps it honest: focus is never valid on a disabled or loading button, because those leave the tab order.
Precise findings. Instead of calling the ripple inaccessible, I narrowed it down: it’s decorative and doesn’t affect screen reader or keyboard users, and reduced-motion support is the one open question.
Repeated elements now live in one place instead of as copies on every screen. The button set a state pattern the rest of the library can follow, and it maps cleanly to what engineering ships. And the audit gave a clear picture of what to fix, what to rebuild and what to leave alone.
Have a design system that needs this kind of work?