Eleven years, three companies, zero design system job titles. Here’s the short version.
Neuland, 2007 – 2012
This is where I did my apprenticeship as a media designer, and it will always have a place in my heart. A small company, very much like a family, and still I got to work on properly fancy projects early on: Smart TV prototypes, and complete content management systems and online shops that actually shipped. Designing something in the morning and building it in the afternoon was just normal.
Also: I met my wife there. Best project of the decade, by a distance.
a Smart TV prototype, remote control not included
Smart TV prototyping, back when “smart” was a bold claim for a TV.
.NFQ Digital Creatives, 2012 – 2014
Agency life. Campaigns, classic advertising, a lot of banners, a lot of HTML5, and web shops. Fast, loud, fun.
The only real trauma from that time: the company foosball table. Everyone loved it. I hated playing it, and I still do. I was also shit at it, which may be related.
a 300 × 250 banner, blinking with conviction
One of many, many banners. HTML5, because Flash was on its way out.
Dr. Grandel, 2014 – 2018
A change of scene: no more agency, in-house at the manufacturer. A more relaxed pace, and more time to do things properly.
The biggest project was the redesign of the online shop. I did the concept, the design and the technical implementation, with a technical agency supporting the backend. In 2018 it won the Shop Usability Award. Doing all three parts myself was hard work, and the best training I could have asked for.
the Shop Usability Award 2018, on a shelf, slightly dusty
Concept, design and frontend for the shop redesign, backend with a partner agency.
What stuck
Looking back, I always worked with a design system mindset. Only the name kept changing: first style guide, then living style guide, then design system. But the questions were the same as today: not just how to make something perfect once, but how to keep it consistent for years.
And from the agency years, one more: how do you hand it over to a client so cleanly that they keep it consistent after you’re gone? That’s basically contribution and documentation, ten years early.
Style guide, living style guide, design system. Same mindset, three names.
Anything I’d never do again? Play foosball. Everything else, no regrets. Great teams, great colleagues, and a lot of friendships that still hold today.
Three weeks of tokens, four years of design system
We built the token architecture in three weeks. Everything after that took four years and was mostly about people.
Client
Celonis
Role
Design Lead, later DesignOps & Design Systems Lead
Team
3 designers (+ up to 3 external), up to 6 engineers
Outcome
99% adoption. Mandatory, but still.
When I joined Celonis in April 2022, the design team was in the middle of moving from Sketch and Abstract to Figma. Which is a polite way of saying: there was nothing to move. No tokens, no reusable primitives. Just a freshly relaunched product and a lot of Sketch files.
Three weeks
Together with my colleague Marta Conde, I built the complete token architecture in about three weeks. We looked at the product designs from the relaunch, pulled out what was actually being used, and turned it into a structure: a primitive layer and a semantic layer on top.
We also talked about a component layer. And decided against it. For our context, the semantic layer was enough, and everything else would have been complexity for its own sake. Everything started in light mode only.
The ugliest part wasn’t technical. It was the time pressure. Three weeks for a foundation that an entire product would stand on is not a lot of time to be wrong in.
Then the actual work started
Tokens are the part people put on conference slides. The real work started after.
Components first. We built them on base components, which was the way to do it back then. Real native slots didn’t exist in Figma yet, so we had to come up with our own workarounds for the cases our product needed.
And then onboarding, a lot of it. A whole design team had to learn a new tool and a new way of thinking at the same time: why color-text-subtle and not grey-500, which token goes where, and why that matters. Trainings, office hours, reviews, again and again.
What we deliberately didn’t do
We didn’t add complexity just because we could. No component token layer from day one, even though it looked very professional in other people’s talks.
Instead, we put that time into onboarding. Especially for the custom components that product teams kept building during the transition. We couldn’t stop them from existing, but we could make sure they at least used the right tokens. That paid off more than any extra layer would have.
Innovation versus consistency
The resistance was the classic one. Product designers want room to innovate, a design system wants things to be consistent. Both are right, which is what makes it annoying.
What helped: leadership being very clear about the goal. If the product should become more consistent, the system has to be stricter, less loose. There was some pushback at the start. But we ran the design system team in the open, and product designers always had a way to push new ideas into the product, through custom and community components that could later graduate into the system.
About that 99%
Before you’re impressed by the 99%: it was mandatory. Leadership made it a clear requirement that things get built with the design system. If you didn’t, you had to argue why. That’s how you get to 99%. Not with a beautiful documentation site.
The faster-to-market number is the one I’m actually proud of. Because the components were stable in design and in code, teams stopped rebuilding the same things, and we could calculate how much faster features shipped. Up to 70%.
What went wrong
One: too much design system, not enough product design. You can build components in Figma that are perfectly scalable and beautifully slotted for the design system. But real product design has to be fast sometimes. When a release is due on Friday, nobody gives a shit about a perfectly slotted container. It gets detached, and the designer moves on. I underestimated that for too long.
Two: we decided things in design without looking at the code. Partly that was down to how our team was set up, but we made design decisions on our own and assumed the code would follow. In the medium term, it didn’t. At some point we had real breaking changes in our designs, because we had to adopt code structures that nobody was allowed to touch.
Code is key. Design is the flexible part.
With component contracts and AI, I wouldn’t approach it like that anymore. In our defence: this was almost four years ago.
The team
I led the design system team: three designers in-house, plus up to three external designers who joined for documentation and other scopes. On the engineering side, I shared the lead with our engineering lead, with up to six developers dedicated to the system. Design and engineering as one team, not two teams sending each other tickets.
What I’m taking to Unblu
Code first. AI takes a lot of work off our hands, and that makes a solid foundation more important, not less. And by foundation I don’t just mean tokens. I mean processes.
Building components with contracts isn’t the hard part of a design system anymore. The operations around it are. That deserves its own article, and it’s coming.
Case · 2023 – 2026
A contribution model people actually use
There is no secret recipe for contribution. There’s iteration, one hard rule, and a lot of 30-minute conversations.
Client
Celonis
Role
DesignOps & Design Systems Lead
Team
Design system team, 20+ feature teams
Outcome
Faster to market and fewer iteration rounds, measured against a comparable project
Every design systems talk has a slide with the perfect contribution model. Arrows, swim lanes, a little rocket at the end. I have bad news: there is no secret recipe. There’s iteration.
Steal the rituals, not the process
We tried a lot. Rhythms, models, scenarios, routines. We looked at the big, famous design systems, copied their rituals and processes, and checked how much of it actually worked for our scope.
Some of it did. Most of it needed bending. In the end, a contribution model has to be built for the company it lives in. What works for a public library used by thousands of strangers doesn’t automatically work for twenty feature teams who share a Slack.
Steal the rituals. Build the process yourself.
The one hard rule
What we did agree on, depending on complexity, was one non-negotiable: every component gets built with the same construction. Core component, community component or one-off snowflake, doesn’t matter. Token adoption, Storybook, the same standards for everyone.
That rule made everything else possible. A component could start its life inside a feature, owned by the team that needed it. And if it turned out to be useful, a design system review could promote it, quickly, into a community component or a proper core component.
Community components
Community components are owned by the feature team, not by the design system. They’re still released through the design system, so they show up in the same library, with the same quality bar. But when something breaks, the people who built it fix it.
We didn’t invent that. We got inspired by the design system at Nord Health, which works the same way. Credit where it’s due.
Try the path yourself:
“Can we have variant X?”
The classic conflict. A team wants variant X, the system says no. It happened a lot, and how it went depended entirely on the team.
Some teams simply built it themselves, without talking to us. That’s a shame, but it happens. Teams that were willing to collaborate got the opposite: we went deep into their feature request and argued it out properly.
Our strongest argument was always platform consistency, especially for navigation and for how actions open: dialog, panel, drawer. We had seen inconsistency there show up again and again as a negative in user tests. That’s hard to argue with.
Overall, we were very willing to compromise. And yes, some components still flew under the radar and made it into production anyway. Every design system has a few of those. Pretending otherwise is how you lose credibility.
Figma admin, a love story
I was also the Figma org admin. If you’ve ever seen the Figma admin panel, you know. It’s not the coolest place on the internet, and the payment models are clearly not made for big organisations.
The most annoying part was the seat hygiene. Who is still active? Who actually needs a full seat? People requested full seats because they joined one single workshop, which a 24-hour open session would have solved for free. Multiply that by a few hundred people and you understand why I have fucking opinions about seat billing.
The rituals that worked
Communication is the whole job. Office hours, where the design system openly shares what’s new and where product designers can push things into the system themselves. Changelogs right in the Figma files, where designers actually look.
The best format, though, was what we called Harmony Sessions. Once a month, 30 minutes 1:1 with each designer. Not a group session. Not just design system updates. A real check-in: where are you in your work, what’s bugging you, where could we enable you better, in the system and in the process around it.
Not everyone wants to speak up in the big round. That’s just human. Some people love it, some don’t, and the quiet ones often have the best feedback. Individual beats scalable, more often than design systems people like to admit.
What went wrong
The biggest problem wasn’t a process. It was a mindset: designers separating themselves from engineering. Not understanding how complex it is to change or bend an existing component, once it’s in code and used in fifty places.
That’s not a design system problem, it’s a product design problem. But the design system is where it hurts first.
Did it work?
We ran the classic surveys, of course. But the most convincing method was a comparison. We set up lighthouse projects that followed the DesignOps process as closely as possible, and put them next to another project of the same size that didn’t.
The result: the team that invested in the ops part worked more efficiently. Faster to market, fewer iteration rounds. No vanity metric, just two projects side by side.
At Unblu
Right now my focus is transparency. A clear roadmap, a clear issue structure, and making UX issues visible inside product design and the feature process. Not just the feature work, but the DesignOps and design system work too, so it becomes measurable.
So yes: contribution and operations again. Different company, same lesson. The components are the easy part.
Archive · 2007 – 2018
Before design systems had a name, 2007 – 2018
Shops, Smart TVs, a lot of banners and one award. The design system mindset was always there, it just kept changing its name.
Client
Neuland, .NFQ, Dr. Grandel
Role
Media designer, screen designer & frontend developer, senior UI/UX designer
Team
Small teams, one foosball table
Outcome
Shop Usability Award 2018
Eleven years, three companies, zero design system job titles. Here’s the short version.
Neuland, 2007 – 2012
This is where I did my apprenticeship as a media designer, and it will always have a place in my heart. A small company, very much like a family, and still I got to work on properly fancy projects early on: Smart TV prototypes, and complete content management systems and online shops that actually shipped. Designing something in the morning and building it in the afternoon was just normal.
Also: I met my wife there. Best project of the decade, by a distance.
a Smart TV prototype, remote control not included
Smart TV prototyping, back when “smart” was a bold claim for a TV.
.NFQ Digital Creatives, 2012 – 2014
Agency life. Campaigns, classic advertising, a lot of banners, a lot of HTML5, and web shops. Fast, loud, fun.
The only real trauma from that time: the company foosball table. Everyone loved it. I hated playing it, and I still do. I was also shit at it, which may be related.
a 300 × 250 banner, blinking with conviction
One of many, many banners. HTML5, because Flash was on its way out.
Dr. Grandel, 2014 – 2018
A change of scene: no more agency, in-house at the manufacturer. A more relaxed pace, and more time to do things properly.
The biggest project was the redesign of the online shop. I did the concept, the design and the technical implementation, with a technical agency supporting the backend. In 2018 it won the Shop Usability Award. Doing all three parts myself was hard work, and the best training I could have asked for.
the Shop Usability Award 2018, on a shelf, slightly dusty
Concept, design and frontend for the shop redesign, backend with a partner agency.
What stuck
Looking back, I always worked with a design system mindset. Only the name kept changing: first style guide, then living style guide, then design system. But the questions were the same as today: not just how to make something perfect once, but how to keep it consistent for years.
And from the agency years, one more: how do you hand it over to a client so cleanly that they keep it consistent after you’re gone? That’s basically contribution and documentation, ten years early.
Style guide, living style guide, design system. Same mindset, three names.
Anything I’d never do again? Play foosball. Everything else, no regrets. Great teams, great colleagues, and a lot of friendships that still hold today.
Unpopular opinions · Part 1 of 3
Why I don’t love designer portfolios (says the guy with a portfolio)
A portfolio shows how well you package work. A day with the team shows how you actually do it.
I have always had a slightly awkward relationship with design portfolios. Not because they are useless. Because of the maths.
If someone runs an immaculate portfolio, posts three carousels a week and has a fresh Medium article every month, I can’t help asking myself one quiet question: when exactly do they design?
The double standard
I know, that sounds bitter. It isn’t meant to. Some people are fast, some people love writing, and some have a lot of evenings. Fine.
But I have sat on the other side of the table often enough. And whenever a portfolio was suspiciously perfect, I stopped looking at the portfolio and started looking at the person. How do they talk about their work? Do they explain a messy decision, or do they recite the case study? Does the human in front of me match the PDF?
Sometimes yes. Sometimes it was more packaging than product. A portfolio shows how well you package work. It says surprisingly little about how you do it.
Text bombs and token tutorials
Part of the problem isn’t the designers. The best work most of us ever did sits behind an NDA. So we show what we’re allowed to show, which is rarely what we’re proud of.
The other part is newer. Generating text is free now, and it shows. Case studies have turned into text bombs: 4,000 words, five frameworks, nobody reading past the first heading. And somewhere out there, someone is publishing the ten-thousandth tutorial on how to set up design tokens. In 2026. When nobody writes them by hand anymore.
To be fair, it was boring before AI too. Corporate case studies always read a bit like a press release from the design team. The AI just made it faster.
Play along next time you review a portfolio:
Greenfield heroes
And then there’s the newest genre. “I built a complete design system with Figma and Storybook in three prompts.” Congratulations, honestly. It looks great. It also has very little to do with the job.
Real products are not a green field. They come with ten years of code nobody wants to touch, two and a half frontend frameworks, a Figma library older than half the team, and workflows that exist because someone in 2019 had a very good reason. Nobody remembers the reason. The workflow stays.
Nobody hires a design systems lead to start from zero. They hire you to swap the engines mid-flight.
Full disclosure: I build greenfield toys too. My wall planner took about an hour of prompting. The difference is that it’s for one wall in my living room, not for fifty product teams, and I would never put it on a slide and call it a design system.
What I actually look for
Design is opinionated, up to a point. Beyond that point, the question is a different one: how does this person fit into a team? Can they communicate? Can they take something complex and make it clear, to engineers, to a PM, to a VP with eight minutes between two other meetings?
You don’t need a great portfolio to show that. It shows in a real conversation, usually within the first half hour.
What does catch my eye: work that is honest about the mess, and side quests. Small things people built outside of corporate bullshit, because they wanted to. A weird tool, a home project, something over-engineered for an audience of one. That tells me more about curiosity and taste than any polished process slide.
Standards? I wish
Here’s the irony. I’m a design systems person. I’m a fanboy of standards. A standard portfolio format would make me very happy.
It isn’t going to happen. Hiring in design still runs on old structures: upload your CV here, attach your portfolio there, wait. Meanwhile the job of a product designer changes faster than the job ads describing it.
What I’d rather see: trial days. Spend a day with the team, in the office, on something real. Not a giant remote take-home challenge that eats a weekend and proves mostly that you have a free weekend. Just a day of working together, so both sides can see how it feels. That’s the only test that measures what actually matters.
So why does this site exist?
Fair question. A few reasons.
Self-branding is unavoidable, I get it. But it doesn’t have to be stiff and corporate, and that’s the approach here: real projects, honest texts, a ghost that says rude things on hover.
It’s also a side quest. I use this site to try the latest AI tools and see how far I can automate things cleanly, from the agent that answers questions about me to the plain-text versions for bots. Building a portfolio turned out to be a good excuse for that.
And yes, you’ll notice there are barely any pictures. Half of them are under NDA, the other half died with old laptops. The placeholders are honest about it. That’s more than most portfolios can say.
Dear hiring managers
Don’t take portfolios so seriously. And please, drop the “a strong portfolio is mandatory” bullshit from your job descriptions, at least as an automatic filter. You are not filtering for good designers. You are filtering for people with free evenings.
Dear designers
Don’t take yourselves too seriously either. Less Medium, more real. And when you apply, offer to just work on something with the team for a day. Most good teams will say yes. The ones who don’t probably told you something too.
Anyway. You’re on my portfolio now. Be gentle.
Lab · 2026
Wandplaner: planning a salon wall to the centimetre
Instagram made me want a salon wall. An hour of prompting made me a planner for it.
Moving flat does something to your Instagram feed. One week you’re looking at moving boxes, the next your entire feed is interior ideas. I’m in that bubble now. And the bubble has a favourite: the salon wall.
The bubble
You know the look. Frames in different sizes, mixed with things that aren’t frames at all: a plant hanging on the wall, a skateboard deck, a record. It looks random. It isn’t. Every good salon wall is planned to the centimetre, it just pretends not to be.
And then there are passepartouts. Nothing is sadder than a nice frame with a print just slapped in cold. A passepartout makes everything a bit more classy. It also makes planning the whole shit a lot more complicated, because suddenly every frame has an outer size, a visible size and an opinion.
Paper? Please.
I didn’t plan this on paper, or with masking tape on the wall. Digital native, remember. This is exactly the kind of thing Claude builds really fast, and it did: a few prompts, about an hour, and the first version worked.
Then came the part that always takes longer. The good old designer perfectionism. The sideboard had to be in there with its real dimensions, so I could plan around it. The TV had to sit at the right height. The Ambilight needed its breathing room, so no frame gets too close. None of that was necessary. All of it was necessary.
Here’s a tiny version of it. Same idea, fewer frames:
What the real one does
The part Claude came up with
Some of it I never asked for. Where exactly the nails go, how high above the top edge, how to hang a skateboard deck with two brackets: Claude interpreted a lot of that on its own. I’m clearly not the first person to build something like this, so it pulled from somewhere.
Does the drill plan actually work? Honest answer: I don’t know yet. Ask me again after the drill.
What went wrong
Nothing, so far. Which mostly means the drill hasn’t touched the wall yet.
And yes, I’m aware of the irony. In my portfolio rant I make fun of greenfield projects built in an hour. This is one. The difference: it’s for one wall and one user, it has zero governance meetings, and I would never call it a design system.
The best side projects solve a problem nobody else has. Mine is 52 frames and one wall.
What’s next
Big plants on the floor, so the wall and the stuff in front of it can be planned together. Maybe a fancy lava lamp. Why not.
the finished wall, coming as soon as the drill is charged
The real wall. Placeholder until it’s hung, as always.
Steal it
The planner is public. It’s in German, sorry. But German is just English with more consonants, you’ll manage.
Option one, for normal people: open it in the browser. Done. Your wall stays in your browser, nothing gets uploaded anywhere.
And if you plan your own wall with it, send me a picture. I’ll show you mine once it’s done.