Design System
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.
The inherited Design System had no established standard. Components were broken and inconsistent. The color palette had been built for print with no consideration for UI or accessibility. Combined with backend instability, it all pointed to the same conclusion: 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 before a single screen was designed. 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 components were being built.
The result is a three-tier token architecture.
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.
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, all 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.