ADCenter Design System: co-building the foundations

The centre built internal products for itself and for clients, each with its own team, its own stack (Angular here, React there) and its own buttons. Developers rebuilt the same components for every project and accessibility was whatever each designer remembered to check. Valeria made the case for a system. I asked to build it with her, partly because the centre needed it and partly because I wanted to learn how systems are made from the inside.

Co-owned with Valeria. The foundations were defined together, in the same file, in the same weeks; the components below were the ones I took on and brought to her for review.

These are not screenshots. The swatches below are painted from the system's own values, as documented in the Figma file, and the number on each step is the contrast of the best text colour on it. Brand primary is Capgemini's blue.

Components never point at a scale step directly. They point at a semantic token, and the token resolves differently in each theme. One component, three looks, zero overrides.

Contrast is a property of a pair, not of a colour. So the check was always the same question: this text, on this background, in this theme, is it readable? The tag is the component where this mattered most, nine colours on nine tints inside dense rows, so here are its variables as the component binds them, with the text measured on each background on this page. Body text needs 4.5:1; large text and UI, 3:1. The component itself is further down.

Tags label, categorise and filter. To cover those jobs without one component doing everything badly, they come in four types: read-only for labelling, dismissible for active filters, operational for overflow ("+3"), and selectable for toggling filters in place. Nine colours, six states, two sizes. The close button is its own component, so its focus ring and hit area are the same everywhere.

After tags I defined the components that dense internal products are made of: tables with sortable headers, inline status and pagination; tabs in line and contained styles; and the calendar, from the day cell up to the twelve-month year view. Rendered below from the system's tokens. If they look familiar, it is because Center360 is built with them: the system and the product were designed in the same months, each pushing the other.

The system was a work in progress by design, and it was in use while it was being built: Center360 and several other internal applications of the centre were assembled from it, so every component shipped to a real product soon after it was defined. Then client work took over my weeks and I moved on to ASML.

One thing about this system is worth saying plainly: it was built before AI tooling could do any of it. Every scale, every variable name, every contrast pair in this page was defined and checked by hand, in Figma, by two people. Today I build systems with AI in the loop, much faster and with far more documentation, and that speed is only useful because I learned what the output has to look like without it.