1 · The method is part of the design.
I follow no procedure dogmatically. Different tools serve different purposes, and each can be adapted. So for every task I decide anew which approach fits it, and fits the organisation that has to solve it.
First the process, then the product
As a designer I shape not only outcomes but the routes to them. Which approach a task needs is itself a design decision, and it is made afresh for every undertaking.
1 · The method is part of the design.
I follow no procedure dogmatically. Different tools serve different purposes, and each can be adapted. So for every task I decide anew which approach fits it, and fits the organisation that has to solve it.
2 · Map what exists first.
Before anything new is made, what is already there has to be visible: what exists, what contradicts itself, what is actually used. Without that map you design past reality.
3 · The neutral layer first, the brand after.
Start with the brand colour and you build a system for one brand. Start with the neutral foundation and you build one that carries many.
4 · Architecture is an artefact in its own right.
It does not sit implicitly inside components; it is written down so it can be argued about before it is built.
5 · Build tools when manual work stops scaling.
If a step repeats, it belongs in a tool. Once as a plugin, today as a running application. The tool is not a by-product of the work, it is part of it.
6 · Validate against samples.
A system proves itself on real cases, not on opinions in a review. Only once samples hold does it get rolled out.
7 · It has to be bought into.
A system nobody understands is not adopted. Explaining, presenting and convincing are not a by-product of the work, they are the condition for it to take effect.
What stays is not the procedure but the stance behind it. Methods change with the task; the principles do not.
Principles come cheap as long as nobody can trace them through actual work.
Dark mode across 16 brands. At Telefónica I built the dark mode architecture largely on my own: first a map of what existed and a translation from old to new, then a neutral palette as the foundation, and the brands on top of it. In the end every brand exists in light and dark on the same architecture.
Switching happens at a single point at the top level of the page. There is no second codebase, no special case per brand and no switch that would have to be maintained inside the product. Build the neutral architecture first and dark mode follows as a consequence, not as a project of its own. Each brand keeps its own neutral palette in the process: in dark mode o2 and blau do not end up on the same grey, but on one that suits the respective brand. Shared architecture, own tone.
The token explorer. The ONE Design System overrides values across seven layers, from the global base down to the individual component. Working out by hand which value finally applies, which one it overrode and what the original would have been is barely feasible. So I built a tool that shows a token's full resolution chain, searches backwards for the components using it, and compares two development states directly. It lives in the design system's Storybook and is therefore open to the whole team. Scale: close to 5,000 tokens per brand and mode, 3,828 of them at component level alone.
And my own practice. This website is the third piece of evidence in itself: a token-driven system that carries the same site across several design profiles, fully maintainable in the editorial system, with no hard-wired content. Alongside it, a configurator that generates a separate, protected version with a curated project selection for each application.
The implementation is AI-assisted; the decisions are not. What I claim are the architecture and the rules behind it. That includes ending things: I built my own logo animation application, compared it with the market and stopped, because an existing tool did it better. That is not a failure but the result of the same test I apply to every solution.