Design System: ein Fundament für sieben Produkte

A foundation for multiple products.

Role Product designer, lead for the design system · Scope From the agency handover to the external accessibility audit · Period 2021 to 2026 · Extent Around 60 components, seven products and numerous services, a design team of four

Confidentiality: I cannot show the internal documentation and the real library. All visuals are newly created, abstracted representations. The product side of this work has its own case study: 3 products, 1 process.

When I started there was no design problem, but a translation problem. For the redesign of the main product, an agency had delivered beautiful concept screens and a handful of base components: two buttons, a card, a sidebar and a header. You can present with that, but you cannot build anything. The developers asked more and more questions the screens gave no answer to. What happens on click? What does the error case look like? What if the text is longer?

That is exactly what I was hired for, as the company's first UI/UX designer.

Over five and a half years this grew into a system for seven products and numerous services: around 60 components, a complete set of fundamentals and about a dozen documented patterns. At times I worked on two to three products simultaneously, which meant constant context switching and was at the same time the reason I was the only one who could see where the same question was answered differently across products.

I initiated the switch from Adobe XD to Figma internally and advocated for it over a long period, then led the rebuild of the library. The system survived this tool change and grew from one designer to a team of three UI/UX designers and one UI/UX manager.

The difference between the levels is the difference between "what does it look like" and "when do you use it". The second question costs more time in everyday work, which is why it received the larger share of the documentation.

The library itself is built on Atomic Design, from the smallest building blocks through composed elements to finished blocks. From this arise two roles we deliberately separated: base building blocks from which new things can be assembled, and finished building blocks that are ready to use directly. For development, exactly this separation was important, because it answers the question of whether you should combine a case yourself or whether an approved solution already exists.

Fundamentals: Accessibility, colour system, layout, elevation with shadows, hover and theming, shapes, typography, iconography, motion, writing.

Patterns: Buttons, cards, dialogs, disabled states, empty states, icon states, layout, notifications, tables, tooltips, upload, text fields, forms, high-contrast mode.

The following three examples show how decisions were made in the system. Every decision comes with what it cost.

Decision. All elements are square; only floating elements are rounded.

Rationale. Our interfaces are tools, and visual density takes priority. Many rounded shapes would have made the products softer and visually more restless across the surface.

The price. Less visual warmth, and a commitment that can only be changed later with great effort.

Documented with an expiry date. The documentation states explicitly that the decision applies to the current product landscape and is to be re-evaluated should the products ever converge into a single application. A recorded decision is only helpful if what it depends on is recorded too.

Decision. Four upload modes and result displays, chosen by use case rather than by taste.

Rationale. In one product the person wants to keep working after uploading; in another, to see that it worked and immediately swap something. Without a rule this was solved differently in every product.

The price. A pattern you have to read before using the component.

Decision. Recurring questions get a decision tree in the documentation instead of a rule in running text.

Rationale. A rule you have to know; a tree you can walk through. Discussions that used to take half an hour were often settled in two minutes this way.

The price. Trees age faster than principles and have to be maintained.

The hardest decision of the system sits in a conflict of goals: our products are multi-tenant, the client organisations want to set their own colours, and precisely that can destroy contrasts without anyone noticing.

The solution consistently separates variable, non-variable and automatic. The client organisation chooses primary and secondary colour, background and surfaces. Type style and iconography stay fixed. The text colour is calculated from the chosen colour and set to black or white, so that text remains legible regardless of the client's choice.

The hardest part was not the idea but conveying it. A system in which one colour derives from another is unfamiliar to everyone involved. The solution only became viable through documentation and examples, and it emerged exactly where design and engineering did the maths together.

Externally audited. The main product was built to BITV 2.0 and WCAG 2.1 and audited by Project Alliance. What was tested: keyboard operation via tab navigation, screen reader support, contrasts, and behaviour under zoom and different screen sizes.

For the system this meant a permanent way of working rather than a one-off audit: visibly distinguishable states, focus states as part of the definition and not of the implementation, and a dedicated pattern for a high-contrast mode. The connection to the colour logic is direct. Without the calculated text colour, every client organisation could have unintentionally undermined the contrast values.

The system hung on a chain that ran from design all the way to audit. Every station had its own purpose and its own audience.

For implementation there was a technical component overview in which the building blocks were represented and always up to date. This is where development looks things up day to day.

For understanding there was Confluence, built as its own area with fundamentals, style guide, design patterns, components and guides. There sat the fundamentals in detail, the principles, the patterns, the decision trees and above all the why. This level was aimed at stakeholders, product management and the design team, but was also read by development.

One format runs through almost all patterns: Do and Don't side by side, with a real example and a rationale. Not "this is what right looks like", but "this is what wrong looks like, and here is what then happens". That caught more questions up front than any description.

The system serves two very different worlds: the dense tool of the consultants and the reduced view of the clients. The way of working was always the same. First design the consultant side, because that is where the functionality arises, then ask what the client side really needs of it, and leave out the rest.

The most revealing result of this: the client view needed no components of its own. New requirements came without exception from the consultant perspective. The client side is a strict selection from the same toolkit. That was not planned; it turned out to be a pattern and considerably simplified the maintenance of the system.

We built our own iconography, and the difficulty did not lie in the drawing. Icons that indicate a state have to mean the same thing throughout the whole system. Whether a crossed-out eye means "the content is hidden" or "click here to hide" is not a matter of taste but has to be decided once and kept identical everywhere. For visibility, locking, favouriting and similar cases we defined which symbol shows which state and which action a click triggers.

As long as I worked alone, the system was a tool. With the team it became a matter of conveying. I presented and justified new rules, because a rule whose reason no one knows is bypassed at the first sign of time pressure.

Both newly joined designers brought in their own principles and patterns, which we sharpened and finalised together. I reviewed their work on the system and did the fine-tuning, because I was the only designer with a view across all products and across the old component system. This responsibility was explicitly intended: my manager entrusted me with the domain leadership of the system.

The system was never finished, and I consider that the more interesting insight. The documentation lived on two platforms, linked but not merged. The plan to turn it into a single design system site failed against day-to-day business.

Two things I would do differently today. First, document earlier, even badly. In the early phase many principles existed only in my head, and every later person had to ask for them anew. Second, develop the colour concept together with engineering from the start, instead of designing it and then having it translated. The viable solution emerged exactly where both sides did the maths together.

Building a design system that one person maintains alone is one thing. Building one that grows over five and a half years, survives a tool change, carries seven products, serves two opposing user groups, allows third-party branding and, in doing so, passes an external accessibility audit is another.

A design system is infrastructure. When it is good, no one notices it, and yet how fast and how reliably everyone else can work depends on it. The most valuable design work is often the work that enables others.