Pain is a smoke detector. It’s annoying on purpose, because whatever set it off is worse than the noise it makes. Team frustration is the same kind of message. When people grumble about a component, a hand-off, a process, the instinct is to treat it as noise — bad mood, low morale, something to smooth over. But frustration is rarely noise. It’s the system reporting a fault from the inside.
\nLast year my right knee started aching while I trained for a half marathon. I felt it, I named it, and I kept running — the race was close, and easing off felt like throwing away the work I’d put in. So the pain got louder, and I got better at ignoring it. The surgery, when it finally came, was probably always coming; years of running leave their mark. But the months I spent overriding the signal were the avoidable part.
\nTeams ache the same way. The people using our tokens ached loudest. Shipping a single value change from Figma to code was a seven-step export: open the token plugin, import the variables, export the JSON, set the options, copy it out, paste it over the file in GitHub, and open the pull request by hand — then a second plugin, and a version number copied back into Figma so the two lined up. Fiddly copy-paste across three tools, and even our own guide told you to bring someone experienced your first time. People lived in that friction, and they said so, often.
\nWe heard them; we just couldn’t fix it. The clean path needed Figma’s REST API to pull the variables out, and that sat behind an Enterprise plan we weren’t on. That’s the trap with friction you can’t resolve yet — left alone it compounds, people stop reporting it and quietly build workarounds, and a workaround is a limp. So we kept the complaint on the table until I found another way in: the door Figma gives every plugin. I built one that reads the variables from inside Figma, writes the changelog, and hands you a pre-filled pull request under your own GitHub account. Seven steps became a click.
\nThat’s the lesson the knee really taught me: treat the first complaint as data, not weather. Fix what you can while it’s still a rename, before it hardens into a rebuild. When you can’t fix it yet, keep feeling it, out loud, until you can.
", "url": "https://thilkolimbeck.com/writing/pain-and-frustration", "title": "On pain and frustration", "summary": "Frustration is a signal, not noise — the same way pain is.", "date_modified": "2026-06-14T00:00:00.000Z", "author": { "name": "Thilko Limbeck", "url": "https://thilkolimbeck.com" }, "tags": [ "Design Systems", "Loose thoughts" ] }, { "id": "https://thilkolimbeck.com/writing/teaching-and-learning", "content_html": "I’ve now taught close to ninety students across four semesters at a German university, alongside the day job — interface and screen design, and a new web-development course this term. I started because I wanted to give something back. I’ve kept going because of what it quietly gives me.
\nTeaching forces you to say what you actually believe. In daily design work you lean on instinct; you put the button where it feels right. In front of students, “it feels right” doesn’t survive — you have to name the principle, and now and then you find out you didn’t really have one. Writing the study booklet for the course was the sharpest version of that: turning years of practice into something a stranger can follow is a brutal, useful test of how well you understand it yourself.
\nThe thing students mention most isn’t the lectures. It’s the written feedback — detailed, specific, on every single submission. It takes ages, and it’s the part I refuse to cut, because feedback is where the learning actually happens. I’d rather teach thirty people properly than perform for three hundred.
\nAnd it loops back. The same instinct — explain the why, pair on the problem, leave people more capable than you found them — is exactly what a design system needs from whoever tends it. I thought I was going off to teach. Mostly, I went back to school.
", "url": "https://thilkolimbeck.com/writing/teaching-and-learning", "title": "On teaching and learning", "summary": "I started teaching to give something back. I kept going for what it gave me.", "date_modified": "2026-05-23T00:00:00.000Z", "author": { "name": "Thilko Limbeck", "url": "https://thilkolimbeck.com" }, "tags": [ "Teaching" ] }, { "id": "https://thilkolimbeck.com/writing/pairing-and-handoffs", "content_html": "For years our industry has treated the handoff as a craft: the perfectly annotated file, the redline spec, the tidy frame passed from design to development. I think the handoff is a symptom, not a skill. Every time you hand something off, intent leaks out in the gap between the people who had it and the people who now have to rebuild it.
\nThe best handoff is no handoff. We pair — designer and developer on the same problem, at the same time, often in the same file. Nearly five hundred of my commits are co-authored, and that number is the point: most of my best work was never mine alone to throw over a wall. The design and the code grow together, so there’s nothing left to translate at the end.
\nThe usual objection is about juniors: don’t people need clean handoffs to learn? I’d argue the opposite. A spec teaches you to follow instructions. Pairing teaches you how the decision was actually made — the dead ends, the trade-offs, the “let’s just try it and see.” That’s the part worth passing on.
\nPairing isn’t free. It’s two people on one task, it asks for real trust, and it falls apart the moment one person quietly drives the whole time. It also leans hard on the design system: shared components and tokens are what let two people move at once without colliding.
\nSo I’ve stopped trying to perfect the handoff. I’d rather delete it.
", "url": "https://thilkolimbeck.com/writing/pairing-and-handoffs", "title": "On pairing and handoffs", "summary": "The best handoff is no handoff.", "date_modified": "2026-02-20T00:00:00.000Z", "author": { "name": "Thilko Limbeck", "url": "https://thilkolimbeck.com" }, "tags": [ "Design Systems" ] }, { "id": "https://thilkolimbeck.com/writing/ai-and-design-systems", "content_html": "The next consumer of your design system might not be a person. It might be an agent — and most design systems are unreadable to one. The docs are written for humans, the examples are screenshots, half the rules live in someone’s head. An AI tool walks in, guesses, and ships something that’s almost right and entirely off-brand.
\nI’ve spent a while now making ours legible to machines. Some of it is unglamorous plumbing: slimming our agent rules by about eighty-five percent so the model spends its attention on the right things, writing docs an agent can actually parse, and drawing one hard line — exactly one third-party component is allowed, the data grid; everything else is ours.
\nThe part I find more interesting is judging the output. We built a small evaluation harness: real prompts from real product teams — build a section, justify a navigation choice, work inside a branch — scored against our own standards and run several times so the result isn’t a fluke. It turns an opinion (“the AI did okay”) into something closer to a measurement.
\nHere’s what surprised me. Almost everything that makes a system good for agents makes it better for people too. Clear names, honest examples, rules you can state out loud — humans were always quietly struggling with the same parts the machine can’t guess.
\nI don’t think AI replaces the design-systems team. I think it audits it. If an agent can’t use your system, that was probably never a model problem.
", "url": "https://thilkolimbeck.com/writing/ai-and-design-systems", "title": "On AI and design systems", "summary": "The next thing to read your design system might not be a person.", "date_modified": "2026-02-02T00:00:00.000Z", "author": { "name": "Thilko Limbeck", "url": "https://thilkolimbeck.com" }, "tags": [ "Design Systems", "AI" ] }, { "id": "https://thilkolimbeck.com/writing/pragmatism-and-idealism", "content_html": "I once took a course on Pragmatism at art school in Stockholm. It felt wildly abstract at the time — William James, John Dewey, truth as the thing that works. Years later it turned out to be the most practical thing I studied, because it describes almost exactly how you keep a design system alive.
\nA design system tempts you toward purity: one perfect token scale, one correct name, a component that handles every case. But purity is a trap. The team needs something useful today, not something flawless next quarter. So we made the unglamorous calls. We emoji-prefixed components mid-migration so two versions could live side by side without anyone losing track. We renamed our tokens from “subtle / soft / strong” to “soft / moderate / intense” because the first set didn’t actually tell anyone what they did. We let go of Tailwind for CSS Modules to lower the barrier for the next contributor.
\nNone of that looks elegant on a slide. Each one made the system easier to use the same week we shipped it.
\nThe idealism doesn’t disappear, though — it just moves. I’m still chasing the clean, coherent system; I’ve simply stopped pretending the path there is clean too. You inventory six hundred screens, you argue about whether a dialog button should be full-width, you sit in a workshop weighing one colour model against another. The ideal is the direction. Pragmatism is how you take the next real step toward it without stalling.
\nPandas, it turns out, are pragmatic idealists. So am I.
", "url": "https://thilkolimbeck.com/writing/pragmatism-and-idealism", "title": "On pragmatism and idealism", "summary": "A design system is applied pragmatism, not a pursuit of purity.", "date_modified": "2025-11-26T00:00:00.000Z", "author": { "name": "Thilko Limbeck", "url": "https://thilkolimbeck.com" }, "tags": [ "Design Systems" ] }, { "id": "https://thilkolimbeck.com/writing/tokens-and-the-impossible", "content_html": "Two things at sipgate were, for years, officially impossible. One was using our brand font, PX Grotesk, in the web app — too costly, too fiddly. The other was dark mode. Both got the same verdict from people I respected: nice idea, won’t happen.
\nBoth shipped. Not because we finally tried hard enough, but because we changed what kind of problem they were.
\nWhat changed was design tokens. Once colour, type and spacing lived as named, semantic decisions in one place — and fed every platform from a single source — dark mode stopped being a feature and became a side effect. We weren’t restyling the app; we were swapping one set of token values for another. When Neo Design and Dark Mode went live for every customer, the striking thing was how unremarkable it felt. A theme, flipped.
\nThis is what I most want people to take from the work: the impressive deliverable is rarely the hard part. Dark mode is the demo. The architecture that turns “redesign everything” into “change these values” is the actual achievement, and it’s invisible in the screenshot.
\nSo when something gets called impossible, I’ve learned to distrust the word. Usually it isn’t impossible — it’s just expensive in the current structure. Change the structure, and the impossible quietly turns into a Tuesday.
", "url": "https://thilkolimbeck.com/writing/tokens-and-the-impossible", "title": "On tokens and the impossible", "summary": "Dark mode wasn’t the hard part. The architecture that made it easy was.", "date_modified": "2025-05-21T00:00:00.000Z", "author": { "name": "Thilko Limbeck", "url": "https://thilkolimbeck.com" }, "tags": [ "Design Systems" ] }, { "id": "https://thilkolimbeck.com/writing/faking-it", "content_html": "Yesterday we had an inspiring in-house workshop with Elia Faber and Julia Reinemann from HelloDesign on user journeys and friction mapping. Both are staples in the design community, but they deserve a fresh look when your company’s strategy changes, as ours did recently.
\nWhy do so many user journeys and personas fall flat? I had a little epiphany during the day. The problem is usually the temptation to inflate thin research into something that looks solid. It should be the opposite: compress a pile of real research and fresh interview notes down into something you can actually act on.
\nSo: build your personas on evidence, not assumptions. The stock photos may look pretty and the names may be catchy, but they don’t represent real users or how they behave. The result? Design decisions built on fiction. Instead of fiction, look for friction — map out every friction point and lean on the Fogg Behavior Model to weigh motivation against ability (still the clearest model I know for this).
\nI get it — tight timelines and no easy access to research make shortcuts tempting. But faking it until you find time for the real thing rarely pays off. Case in point: in a single hour, my team and I spotted three parts of the purchase flow we could easily improve, plus one much bigger opportunity — but that’s a post for another day.
", "url": "https://thilkolimbeck.com/writing/faking-it", "title": "On fake personas and friction", "summary": "In your user journeys, instead of fiction, look for friction.", "date_modified": "2025-04-10T00:00:00.000Z", "author": { "name": "Thilko Limbeck", "url": "https://thilkolimbeck.com" }, "tags": [ "Design" ] }, { "id": "https://thilkolimbeck.com/writing/headwind", "content_html": "Up north on the coast where I’m from, we say “Gegenwind formt Charakter” — headwind shapes character. And after five years of Tailwind, the CSS framework, it’s time for an honest assessment. What started as a fresh breeze for rapid development has slowly turned into unpredictable gusts for my team.
\nWe use Tailwind in our design system’s components, with a mix of CSS modules when needed. Given that our web app uses a mix of CSS and SCSS / modules, this results in a constant back-and-forth between syntaxes. This isn’t just mentally draining; it’s also turned our files into a tangled mess and slows down our pair programming sessions.
\nMaybe it’s my design background, but I love that Tailwind says leading instead of the usual CSS line-height. For a lot of front-end folks, though, it’s just confusing — yet another language on top of the many they already speak. A dialect, some might argue. One that was meant to ease communication but, spoken rarely, becomes its own little language barrier — a bit like the Plattdeutsch I’ve bracketed this text with.
So where do I land? Use Tailwind for fast prototyping and solo projects — but on bigger, enterprise-scale work, I’d think twice. As we say up north, “De Wind kummt immer van vörn” — the wind always comes from the front.
", "url": "https://thilkolimbeck.com/writing/headwind", "title": "On Tailwind and character", "summary": "After five years of using Tailwind, it’s time for an assessment.", "date_modified": "2025-04-08T00:00:00.000Z", "author": { "name": "Thilko Limbeck", "url": "https://thilkolimbeck.com" }, "tags": [ "Tech" ] }, { "id": "https://thilkolimbeck.com/writing/i-am-your-father", "content_html": "I’ve always had a quiet fear of turning into my father. Doesn’t every man? To dread becoming someone you deeply admire—a person who’s cared tremendously and at their best, loved unconditionally. Yet there it was: the sting when my partner snapped, “You’re just like your dad!” A sentence that should’ve felt neutral, even complimentary, but instead felt like a verdict.
\nFor years I’ve joked to friends with kids, “Why bother raising them? They’ll turn out like you anyway.” It was meant lightly, but lately it feels more like a confession. And here’s what’s slowly settling in: learning to love myself means first learning to accept my father fully — his humanity, in all its complexity. Because it isn’t just inevitable that I’ll one day be almost like my dad. It’s a good thing.
", "url": "https://thilkolimbeck.com/writing/i-am-your-father", "title": "On becoming like your father", "summary": "I’ve always had a quiet fear of turning into my father. Doesn’t every man? ", "date_modified": "2025-04-06T00:00:00.000Z", "author": { "name": "Thilko Limbeck", "url": "https://thilkolimbeck.com" }, "tags": [ "Loose thoughts" ] }, { "id": "https://thilkolimbeck.com/writing/into-design-systems-meetup", "content_html": "For the first round of the Into Design Systems Meetup in Düsseldorf, we welcomed a diverse crowd of designers, developers, and product people to sipgate. The evening featured two talks: Accessibility in Design: Strategies and Practical Approaches for Design Systems by Coralie Deutscher and Andrea Prade from denkwerk and From Woyton Coffee to Design Systems: A Career Journey You Didn’t See Coming by Laura Fehre from Figma.
\nAfter the talks, Ana Luiza Cavalcanti and Dorsa Javaherian ran a lively Q&A. Then came my favourite part: a Community Pitch session, where anyone could flag a job search, share an opening, or just ask for advice — the kind of thing that actually turns a room full of strangers into a community. And I finally got to meet Sil, who runs the Into Design Systems Conference, in person, after years of only seeing each other through a screen.
\nTrue to the conference’s spirit, Sil kept the whole evening introvert-friendly and inclusive. On that front, sipgate pitched in too: we have gender-neutral bathrooms — something I pushed for — with custom icons my dear colleague Tim Koppers and I designed together. And I really believe it: the best things, like this meetup, only happen in spaces where everyone can take part without shame or discomfort.
", "url": "https://thilkolimbeck.com/writing/into-design-systems-meetup", "title": "On meetups and inclusivity", "summary": "The best things happen in rooms where everyone can take part.", "date_modified": "2025-04-02T00:00:00.000Z", "author": { "name": "Thilko Limbeck", "url": "https://thilkolimbeck.com" }, "tags": [ "Design Systems", "Meetups" ] }, { "id": "https://thilkolimbeck.com/writing/social-animals", "content_html": "Solo days and side projects, social days and the people I love — I’ve never quite settled the balance between them.
\nLike any poison, being alone is all about the dose — the initial rush curdles into deadly loneliness if you take too much. Tolerance is wildly individual, a “matter of practice”… and probably not a great goal in itself?!
\nIn the end, we remain social animals.
", "url": "https://thilkolimbeck.com/writing/social-animals", "title": "On solitude and side projects", "summary": "Like any poison, being alone is all about the dose.", "date_modified": "2025-04-01T00:00:00.000Z", "author": { "name": "Thilko Limbeck", "url": "https://thilkolimbeck.com" }, "tags": [ "Loose thoughts" ] } ] }