Design system for X-ray equipment

01How things were before

The company’s interfaces each lived their own life. There was no shared structure, the products looked different from one another, and no single brand came through. New flows had been piled on top of old ones for years, so the interfaces grew heavy — visually and functionally. Every new feature was written into the manual, which by then had grown past 100 printed pages that medical staff were expected to read before starting work.

1. 01Different visual approaches inside a single company
2. 02A printed manual for medical staff as the entry point into the interface
3. 03Every component hand-coded by developers from PNG mockups
4. 04Design debt growing, with no way to run a quick audit

02Design audit

I started with an inventory: went through the existing interfaces and marked what repeated and what was unique. The audit showed that consistency between the interfaces of one company was almost non-existent. Every device got its own look, barely related to its siblings. At the same time, the markup for any new component was written by hand from a PNG image, which took developers a lot of time for such a routine task. Design audits in this setup usually failed, and code review dragged on because different developers wrote components in different ways. Onboarding new colleagues was hard too — nothing was unified, neither in design nor in code.

03The UI kit and the move to a system

Together with the second designer we redesigned the first screens and got the direction approved by the stakeholder. Then I built a UI kit covering every component on those screens. While working on it I realised that larger changes were needed, so I decided to get a design system project approved. I ran a presentation for management about the need for a single design system — to speed up production and to scale the brand. After that I talked to the developers and explained how the system would affect their day-to-day work, and why production had to move away from legacy. Some supported the idea, others insisted on the familiar way of working. I decided to start on the design system, move a few screens fully onto components, offer a test drive to the part of the engineering team that was on board — and, if it went well, present the switch together with them to the sceptical half.

1. 01Redesign of the first screens, direction approved
2. 02A UI kit with full component coverage
3. 03Defending the move from a kit to a system in front of the stakeholder

Part of the set

The system on a real screen

BEFORE AFTER

• These are the very first screens the kit was assembled from
• The buttons, fields and selects on them come from the library, not drawn again
• A closer look at this redesign is in case 02

04Components through vibe coding

There were not enough developers to set up the library: they were busy with the product, and every component additionally went through a long code audit. I proposed building the components with AI and vibe coding — and defended the decision. That made it possible to keep growing the design system without pulling engineering away from their work. Vibe-coded components went through a quick code review to catch the model’s mistakes, and were then approved in Storybook.

1. 01The reason: not enough developers and a long code audit
2. 02The routine of producing components went to AI
3. 03Decisions and rules stayed with design