Come out and play

Years ago, I visited Dessau with my parents. Walking into one of the Masters’ Houses, I said: “This looks like Grandma and Grandpa’s place.” My grandfather was an architect, and their home was a mix of Bauhaus and Scandinavian design. What people jokingly call Gelsenkirchener Barock, that supposedly typical German grandparents’ aesthetic, was completely foreign to me. This was what home looked like.

I love Bauhaus, so when I needed a name for a new design system, Dessau Design System felt obvious. But Dessau DS is deliberately not a Bauhaus-themed design system. No mandatory primary-colour circles and triangles, no attempt to turn a hundred-year-old visual language into a UI kit. The connection is in the thinking: clarity over decoration, system over style. Six deliberate decisions, not forty accidental ones.

What I brought with me

The thinking behind Dessau DS didn’t begin in Dessau. Before it, I had built an internal design system at Die Haftpflichtkasse. That was my first agent-first, code-first design system, built for real products with coding agents as intended users rather than something added afterwards.

At HK, though, many of the boundaries were already there. The design system had to fit into our DORA-compliant enterprise setup, with the technical and organisational constraints that came with it. It also had an existing corporate design. Much of the visual direction was already decided; my job was to turn it into a coherent digital system.

Dessau DS let me explore the same kind of work without those particular constraints, but that freedom also removed some of the answers. There was no existing corporate design telling me what the system should look like. I had to decide what actually defines its visual character, and ended up with six foundations: colour, typography, radius, density, depth and motion.

Other things were already settled in my mind. Accessibility, dark mode and distinct display, body and mono typography are all things I still believe belong in a design system. So does UX Writing, which had already been part of the design style guide at HK. The language of an interface is part of its design. A design system should define how a product looks, behaves and speaks.

That continuity doesn’t make Dessau DS an extraction, rewrite or open-source version of the HK system. It is a fresh implementation. Some of the thinking inevitably carried over. The systems themselves stayed separated.

From one design system to another

Starting without an existing corporate design also opened up a question I hadn’t been able to explore in quite the same way at HK. What if the point of a design system wasn’t only to provide components for products, but to provide the foundation for other design systems?

That became the primary purpose of Dessau DS. You can build a product directly with it — its own website does — but it is mainly designed as a foundation for what I call Derived Systems.

A Derived System is a design system in its own right. It starts with Dessau DS, but makes its own foundational choices. It can use Dessau DS components where they fit, change or replace them where they don’t and add components that don’t exist in Dessau DS at all. The point isn’t to produce lots of things that look like Dessau DS. The point is to provide a useful foundation without deciding what the thing built on top has to become.

That claim needed testing. If every Derived System still looked like Dessau DS, I hadn’t built a foundation for independent design systems. I had built a design system with themes.

So I built a small Derived System with a deliberately cyberpunk-inspired visual language. It wasn’t a product, it wasn’t public and it never had a name. Its job was simply to answer a question: could something built from Dessau DS move far away from its visual language without losing the benefits of the foundation?

It could. That was enough. The experiment had answered its question, so I stopped.

Then it had to work

Visual independence was a useful result, but it was still a laboratory result. I didn’t yet know whether a Derived System could grow into a complete design system with its own requirements, its own components and actual products depending on it. That question led to Neon.

Neon is my private design system, created as a Derived System from Dessau DS. It has its own visual identity, its own foundational choices and its own component inventory. Dessau DS provided the foundation for creating it; Neon is the design system my products actually use.

Those products were part of the plan from the beginning. I built Neon for the onygo relaunch on WordPress and my new portfolio on ProcessWire. That gave it requirements an experiment didn’t have. Neon couldn’t merely demonstrate that the idea worked. It had to work itself.

That also meant allowing it to become genuinely independent. Neon can inherit a component from Dessau DS when that makes sense, but it doesn’t have to. It has a different footer, for example, for the wonderfully sophisticated reason that Neon needed a different footer. It isn’t a skin for Dessau DS. It is its own design system.

Once Neon was being used for real products, it started finding things that an isolated foundation couldn’t. Some design decisions looked perfectly reasonable until I saw them rendered. Then they didn’t. Coding agents can make the distance between an idea and a working implementation remarkably short, but somebody still has to look at the thing.

Neon also exposed things Dessau DS was missing. I wanted those observations to flow back into the foundation, so I told the Claude Code agent working on Neon to write down anything it noticed. My plan was simple: I would take its notes and pass them on to the Claude Code agent working on Dessau DS.

That was the plan, anyway. Instead, the two agents started talking to each other directly. I hadn’t told them to do that. I hadn’t even considered that they would.

I was genuinely surprised. I sat there watching the agent building Neon discuss what it had found with the agent building Dessau DS. I had assumed I would be the human handover point between the Derived System and its foundation. Apparently, I was the unnecessary middleman.

That moment made the idea of agent-first much more tangible to me. It isn’t simply about generating code faster. Agents need enough context to understand the system they’re working in, the decisions that have already been made and the decisions that still need to be made. A plausible-looking default can be more dangerous than a missing answer because it quietly becomes a design decision nobody remembers making.

The point isn’t to remove human judgement. If anything, faster implementation makes judgement more important because decisions become visible sooner. I want agents to expose the places where a decision is needed, not quietly make every decision for me.

The rest of the technical foundation follows from much the same thinking. Dessau DS stays close to the web platform with vanilla HTML, CSS and JavaScript rather than making an application framework part of the foundation. Modern Web Guidance proved extremely useful for keeping the agents’ frontend work current, and I wouldn’t start another AI-assisted HTML project without it.

Accessibility belongs in the foundation from the beginning too. WCAG 2.2, semantic HTML and accessible behaviour aren’t another visual option alongside colour, typography, radius, density, depth and motion. Accessibility isn’t an optional seventh choice. It still has to be tested: Playwright can automate a lot and catch regressions, but a green test suite doesn’t replace using a keyboard, watching focus behaviour and looking at the actual result.

A point at which I could stop

Looking back, the cyberpunk-inspired experiment and Neon did something else for me as well. They gave the work boundaries. I can happily play around with something and discover interesting things for hours, but without a concrete question I can also stop when something else catches my attention. And the next interesting thing always appears. Oh, a bird.

If I actually want to learn something, I need a problem space. The first experiment had a question to answer. Neon had two products that needed to work. Both gave the playing resistance and feedback, but they also gave me something equally important: a point at which I could say the job was done.

That point doesn’t require every possible question to have an answer. Dessau DS still has deltas. That’s one bit of consultant language I actually use, because a delta can be closed without implying that every delta has to be closed.

I haven’t tested Dessau DS underneath a mature existing corporate design, for example. Neon is greenfield, so it doesn’t tell me what happens when a Derived System has to accommodate an identity with its own typography, colours, components, history and inconsistencies. React and Web Components are deltas too. I’m not planning separate versions for them; if someone needs that integration, I see it as part of their project rather than another Dessau DS implementation for me to maintain.

Those deltas don’t stop Dessau DS doing the job I built it to do. I know it can be used directly because its own site uses it. I know it can produce a visually independent Derived System because I tested that. And I know a Derived System can grow into its own design system and carry real products because Neon now does exactly that for onygo and my portfolio.

For me, that’s what finished means here. Not that nothing will ever change, and not that every possible delta has disappeared. The remaining deltas don’t prevent the product from doing its job well. Keeping it to myself wouldn’t make it more finished.

Come out and play

Which brings me to the reason I’m writing about Dessau DS now. It’s available under the MIT licence. There is no business plan attached to it, and I’m not setting myself up as its support desk. But I would genuinely love to see people use it: build a product directly with it, fork it, change it, derive another design system from it, or put it into a problem space I haven’t thought of.

I’ve answered the questions I needed to answer before letting it out. Someone else might use it underneath an established corporate design, integrate it into a stack I haven’t tested or build a Derived System that goes somewhere I never would. They might find entirely different deltas, which is rather the point.

I know where my experiments took Dessau DS. I don’t know where somebody else’s will take it. Come out and play.