Problem
In 2025, the company secured a banking license and, with it, introduced a new feature: “Konto & Karte”. Its scale brought into focus what had been building for some time, the existing platform simply wasn’t designed to carry this kind of weight.
Backend instability, a Design System inherited from a merger with no established standard, broken or inconsistent components, and a color palette originally built for print with no consideration for UI or Accessibility all pointed to the same conclusion. So, the decision was made to rebuild from the ground up.
Solution
The new platform had one clear constraint: it had to feel continuous with what already existed. Users needed to recognize it as part of the same product family. This wasn't a rebrand, it was a modernization: same identity, stronger foundation, and the first real opportunity to do things properly from the start.
As the designer responsible for the new setup, this meant establishing the foundation alongside the first product screens. When "Factoring" became the first project to fully adopt it, the system held. That is the best proof a Design System can offer.
Tokens & Color
The system was grounded in Tailwind CSS and shadcn conventions, a deliberate decision to align design and engineering from the outset rather than bridge the gap at handoff.
By anchoring the token structure to how Tailwind thinks about scale and naming, the shared language between design and development was established before a single component was built.
The result is a three-tier token architecture.
At the base, Color Primitives hold the raw values, every stop across every scale, e.g., from Blue/50 to Blue/950, mirroring Tailwind's conventions.
The Brand layer filters those primitives into semantic groups: Base, Muted, Primary, Info, Success, Warning, Error, each with a full scale plus alpha variants for overlay and background use.
At the top, the Mapped layer assigns meaning: tokens like information, information-hover, or success-on-action reference Brand values directly, so components consume intent rather than raw color.
A change at any tier cascades correctly through the system.
Accessibility was built into the palette documentation from the beginning. Contrast ratios were tested against WCAG 2.1 standards across each scale, with a minimum of AA compliance required throughout. AAA ratings were achieved across the majority of stops, particularly those intended for text and iconography.
Variables & Documentation
Figma variables were central to how the system held together. Rather than using styles alone, variables meant the system could support theming and mode-switching properly.
Documentation was written in parallel with the build. For a solo designer building something that would eventually be handed off to developers and other designers, documentation wasn't optional, it was what made the system real rather than just a Figma file.
Component Architecture
With tokens in place, I built the component library on top of them. Each one was structured around a base with swappable variants, covering the states, sizes, and configurations that would actually be used in the product, not an exhaustive list for its own sake.
The logic behind every component was the same: build the simplest version first, then extend it with intention. A Button is rarely just a Button, it's where foundational decisions about hierarchy, states, and scale get settled. Getting those right early meant they didn't have to be revisited with every new screen.
Outcome
This was the first time I had the scope to build something of this scale from scratch. Not adapting what existed, but replacing the logic entirely, tokens, components, variables, documentation, built as a coherent whole.
The platform didn't reach launch. Funding ran out at the end of 2025. But the system stood on its own, independent of that outcome. A complete foundation, built properly for the first time.