brand-color. main. primary. blue. sky.

Every team has a name, and every name carries a different meaning, a different role, a different place in the hierarchy. They are not interchangeable. And figuring out which one, and why, deserves a real conversation before a single line of code is written.

This has been my obsession for many years. Not the colours. Not the components. The agreement on the basics, before anything else is built on top of them.

When we built Panot at Fotocasa Group, we settled on main. A variable in Figma. In CSS, --colors-main. In Kotlin, a resource reference. In Swift, something else again. Every platform translated it differently. Every platform called it the same thing.

I did not know, when we made that decision, that there would be a fifth reader of that token within a year. An AI agent. But when it arrived, main was already there, waiting, legible. Not because we could read the future. Because we had agreed.

The agreement has always had more readers

I have been building Design Systems since 2017. At eDreams. At Schibsted, and then across Adevinta, which was the umbrella for Kleinanzeigen, Leboncoin, and many others. Across countries and companies that often had nothing in common except the problem they were trying to solve. The tools changed: Sketch became Figma, Sass became CSS Variables, JS became TypeScript, KSS became SUI Studio, SUI Studio became Storybook, then MDX. The problem never did.

The problem is always: how do you make a decision that survives the gap between the person who made it and the person who needs to execute it? That gap started between two humans in the same room. Then between designers and developers on different floors. Then between teams in different countries, working in different codebases. Each time it widened, the system had to become more legible, more structured, more explicit.

The agent is just the newest reader across that same gap. But the most unforgiving one. A developer can ask a question. An agent cannot. A developer can infer your intent from context, history, and the coffee conversation last Tuesday. An agent reads what is written. Nothing more.

If a pattern is broken and undocumented, the agent copies the broken pattern. If a decision was made in a Slack thread that nobody saved, the agent has no access to it. If your token naming is inconsistent, the agent interprets the inconsistency as intent.

This is not a new problem. It is the oldest Design Systems problem, running faster and at greater scale than ever before.

Rules still come first

I have moved my work from one tool to another a Million times. Corel to Flash, from Flash to Photoshop, from Photoshop to Fireworks, from Fireworks to Sketch, from Sketch to Figma. Each move felt significant at the time. Each tool changed how I worked, what I could do, how I communicated with developers.

None of them changed what came first.

Rules. Then processes. Then tools.

This remains true in the era of AI. I hear conversations every day about which AI tool is the right one: Cursor or Claude, Lovable or something else, GitHub Copilot or a custom agent. These are not the wrong conversations. But they are the third conversation. The first conversation is: what are the rules your system operates by? What are the agreements? What is the source of truth?

An AI agent given access to a poorly governed Design System will not fix it. It will accelerate it. The entropy compounds faster. The inconsistencies multiply with every generation. Governance has never mattered more than it does right now, precisely because the tools are so powerful.

Adoption of a Design System will be easier with AI. Any developer can now use a well-documented component without deep system knowledge: the agent can translate the intent into correct code. But diverging from the Design System will be easier too. Anyone can generate a bespoke component in seconds. The pull away from the system is faster than it has ever been.

Direction, governance, and vision are not administrative overhead. They are the product.

What it means to build for a reader who cannot ask questions

A Design System that can be read by agents needs the same thing as one that can be read by developers from a different country, speaking a different language, working in a different codebase: explicit decisions, structured naming, and documentation that does not assume shared context.

The token work is the foundation.

Semantic naming is not an aesthetic preference. It is the contract. The agent needs to know not just what colour to use, but why that colour exists, what surface it belongs to, what it signals to the user. Tokens without semantics are just variables. Semantics without documentation are just intentions.

The agent needs to know what to reuse and what to respect.

• For reuse: examples for every component, clear prop definitions and types, and test coverage that confirms the component behaves as specified. Without this, the agent defaults to whatever pattern it has seen most often in the wild. And the most common pattern on the web is not your brand. It is everyone else’s.

• For respect: automated tests that catch regressions, and human sign-off before components reach production, which is not a bottleneck but where the agreement gets enforced.

Documentation is easier to produce than it has ever been.

An AI can generate documentation for a component in seconds. The problem is maintenance. The problem is changelogs. Current AI workflows do not track history. They do not know that this component used to work differently, or why the decision was made to change it. Documentation that cannot be maintained is not documentation. It is debt that looks like progress.

The organisations that will build the best agentic Design Systems are the ones that treat documentation as infrastructure, not output. That means versioning, changelogs, decision records, and a culture of writing down not just what, but why.

AI earns its place. Just not at the top of the org chart.

There is a version of the AI-first workflow story that goes like this: AI generates the options, AI selects the best one, AI ships the result. Humans review, optionally, when there is time.

IMO, that’s the wrong version. Not because AI is unable to generate good options: it can, and watching it work is genuinely remarkable. But because taste is not a filter applied at the end of a process. Taste is the process. And taste is where brand lives.

If you let the machine decide which of its own outputs is best, you will get competent, legible, optimised experiences that look like everything else on the web. The homogenisation of digital products is not a distant risk. It is already visible. It is what happens when every team uses the same tools, the same models, and the same defaults, without a human in the room who has a point of view.

The human’s job in an AI-first workflow is not to approve or reject. It is to set direction, hold the brand, and make the calls that the machine cannot make: not because the machine is incapable of generating an answer, but because the answer requires conviction, not calculation.

Here is what only humans can do in this new model.

Adoption. Building a Design System that people actually use requires humans to trust that other humans are going in the right direction. You cannot automate that trust. I have seen it at every scale: Developers by a coffee machine at eDreams, ten brands across four verticals at Adevinta Spain, twenty builders and hundreds of consumers across four countries at Spark. The technology was never the hardest part. The belief was.

Agreements under conflict. When a team is divided on a direction: which pattern to adopt, which brand aesthetic to commit to, which tradeoff to accept, a machine will give you its most statistically likely answer. But organisations do not run on statistical likelihood. They run on intentions and agreement. And that requires a human to say: we are going this way, and I am accountable for that decision.

Visibility and advocacy. An agent can generate a dashboard, track adoption metrics, produce a report. What it cannot do is walk into a room full of sceptical designers, PMs, and engineers and make them believe the system is worth committing to. That is a human activity. It always has been.

The craft itself. There is something about how we design together: in a shared canvas, handing work between collaborators, watching someone else continue what you started, that is core to the profession. AI agents can do something that looks like this. But they are taking out the experience of designing. The friction of collaboration is not inefficiency. It is where the ideas improve.

The greatest moment for the craft

None of this makes me pessimistic about AI. It gives me clear confidence: This is the greatest moment in the history of our craft.

For as long as I have been designing, there has been a drawer. Every team has one, physical or metaphorical. It is where the good ideas go when development capacity runs out. The beautiful flow that was too expensive to build. The interaction that was technically correct but nobody had time to code. The experience that would have been spectacular and never shipped because the cost was prohibitive.

That drawer won’t be needed anymore. The distance between an idea and a working prototype has collapsed. Designing spectacular experiences is no longer expensive. It is fast. What was a constraint of resources is becoming a constraint of imagination only.

The constraints that shaped how we worked are falling away one by one. Designers will finally work with real data: actual content, actual users, actual edge cases, not representative samples and placeholder text. The blank page is disappearing, replaced by ten starting points in the time it used to take to open a new file. And the pitch deck is ending. Everything can now be a living prototype. A design leader in a strategy meeting can show, not tell.

In a world where everyone can ship, the rarest thing is not execution. It is vision. When any developer with an AI agent can build a functional interface in an afternoon, the question is no longer can we build it. It is should we, and does it feel like us, and does it serve our users better than what we had yesterday.

Designers will not lead with prototypes in this era. They will lead with direction. With opinion. With the kind of point of view that makes other people want to follow. Ideas matter more than ever. Not the ability to execute them: that gap has narrowed dramatically. The ones that will define products and brands are the good ones. The original ones. The ones that require a point of view about the world, not a statistical model of what has been done before.

It is still about people

There is something that I think will finally get fixed, and that has frustrated me for most of my career: the tension between design and development. Between platforms and languages. Between the Figma file and the pull request. That tension existed because the translation was expensive and error-prone. The handoff was where intent went to die. AI does not eliminate that gap, but it compresses it in ways that make real collaboration possible for the first time. We are not there yet. But I can see it from here.

I wrote years ago that a Design System is not a Figma file. It is an agreement.

That definition has not aged. If anything, it has become more load-bearing. The system is now not only the agreement between designers and developers, between platforms and languages, between the brand and the product. It is the agreement that tells the machine what to do. The rules the agent follows when no human is watching.

Building a Design System that can scale is as hard as it has ever been. Not because the technology is harder: the technology is extraordinary, and it is only going to get better. But because the technology is only as good as the agreements behind it. And agreements are made by humans, between humans, in rooms where someone has to say: this is the direction, and I am responsible for it.

I do not have all the answers for what comes next. I do not think anyone does.

What I have is twenty-five years in design, nine of them building these systems, at every scale they come in. In companies that were growing and companies that were splitting. With two people and with twenty. Across four countries and four brands and too many Slack threads to count.

And what I know is this: when the system is working, it goes quiet. The friction disappears. The arguments stop. The developers build without worrying about the CSS. The designers focus on the next problem instead of re-solving the last one.

That silence is still what we are building towards. The same silence as before.

Just, now, with more readers in the room.

Turo López Sanabria has over 20 years of experience in Design, and nearly a decade building the infrastructure that makes digital products coherent at scale. Five Design Systems. Several companies. Today, he works at the frontier where the line between building for humans and building for machines has started to blur.

One day, Adevinta was a global company. The next, it was several smaller ones.

The investment fund that acquired it didn’t need a single platform serving Germany, France, Italy, and Spain simultaneously. It needed leaner, faster, independent businesses. So the split happened. Not as one clean break, but as several. The Spanish portfolio divided too. Coches.net, Infojobs, and Milanuncios went one way. Fotocasa and Habitaclia became their own company: Fotocasa Group. And with that came a question nobody had planned for just a year before: what do we do about the Design System?

The answer wasn’t obvious. We had two Design Systems to choose from.

SUI Components, which Fotocasa had been using for years, was ours in spirit. I had built it at Adevinta Spain. It had served ten brands across four verticals. But by then it was no longer evolving. We had stopped investing in it the moment we started building Spark, and that was the right call. You don’t maintain two systems in parallel. SUI was the past, and everyone knew it.

Spark was the future. We had spent over a year building it with nearly twenty people across four countries. TypeScript, semantic tokens, cross-platform theming, dark mode, Storybook, accessibility baked in from the start. It was the most ambitious, most intentional Design System I had ever been part of. The problem was that Spark now belonged to a company we no longer belonged to.

Three options. Fork SUI, which meant inheriting a system everyone had been quietly waiting to leave behind. Build from scratch, which was reckless given the speed the business needed to move. Or fork Spark, take everything we had just built at scale, and make it ours.

We took two weeks to decide. Then we forked Spark and named it Panot, after the iconic hexagonal tile that covers the pavements of Barcelona.

Two weeks, and then clarity

Two weeks sounds fast for a decision of that scale. But we had already done the hard thinking. Every architectural choice in Spark had been argued over, tested against four brands, stress-tested against edge cases across three platforms. That work didn’t disappear when the company split. It travelled with us.

What we spent those two weeks doing was deciding what to keep and what to change. Not everything in Spark was right for Fotocasa Group. Spark had been designed to serve Kleinanzeigen, leboncoin, and Milanuncios simultaneously, which meant compromises that made sense for four countries but not for a single product group focused on real estate in Spain.

We kept the colour system wholesale. It was solid, semantic, and structured in a way that worked perfectly for real estate surfaces, where contrast and legibility are critical. We kept the TypeScript architecture, the token structure, the Storybook setup. We kept the semantic naming, main, onMain, support, onSupport, and everything it enabled.

We tweaked the font scale. Fotocasa Group had its own typographic identity, and Spark’s defaults didn’t fit. We also improved the documentation layer, moving to MDX with live previews so that every component in the system could be seen and tested in context, not just described.

Every decision was intentional. We made conscious choices about what to keep and why, what to change and why, and wrote it down so the team knew.

The team that made it possible

I did not build Panot alone.

I set the direction. I made myself available. I was heavily involved in the decisions that mattered. But Andrés Alvarez, already a strong player in the house, took full proactive ownership of the technical execution. From the first day, he was setting up the architecture, configuring the infrastructure, planning the rollout, and moving faster than I ever could have if I’d been standing over his shoulder.

Joan, a designer on the team, partnered with Andrés on the design decisions and adoption strategy. Together, the two of them moved at a speed that surprised me.

I had learned from Spark that co-building between design and engineering is not optional. At eDreams, it was Javi Mota. At Adevinta Spain, it was the first Andrés. At Spark, it was the whole French engineering team. At Panot, it was Andrés Alvarez and Joan. The pattern holds every time.

What was different at Panot was my own role. I was now Head of Product Design at Fotocasa Group, which meant research, team management, product strategy. I was no longer a Design System practitioner day to day. That was hard to accept, because I love that work. But I also understood something I had not fully internalized before.

When the vision is clear, you can let go of the execution.

I knew where Panot needed to go. I knew the technology, the principles, the adoption model. So instead of staying close and slowing things down, I trusted Andrés and Joan to move fast, make bold decisions without waiting for me. Check in when it matters.

They did. And Panot was ready for teams to use in less than a month.

Adoption during a layoff

Full adoption across all applications took less than a year. That speed needs context.

We launched Panot while the company was going through a layoff. People were scared. The mood was difficult. It was not the moment anyone would have chosen for a major infrastructure change.

And yet the adoption was the smoothest I have ever seen. Zero pushback. Not one developer or designer asked why we were doing this or whether it was worth the effort. The Slack channel we created for Panot had more activity from the first week than SUI Components had in months.

I have thought about why, and I think there are a few reasons.

The teams were small and had worked together for years. Everyone knew each other. The conversations that would take days in a global company took an hour in Fotocasa Group. The system also gave people something to focus on that wasn’t the anxiety of the moment. Panot was visible, exciting, and moving forward when everything else felt uncertain. That mattered more than any communication strategy.

But there’s something else. The teams had been watching Spark happen. They knew what TypeScript and semantic tokens and Storybook looked like. They had been waiting for the moment they could use those tools themselves. Independence gave them permission. When Panot arrived, it wasn’t a surprise or an imposition. It was the thing they had been waiting for.

To track adoption, we built two things. A Datadog dashboard comparing SUI Components packages to Panot packages across all our applications. And a Chrome extension that highlighted Panot components live on our production websites, painting them pink so anyone could browse Fotocasa and see the system at work in real time. Making the invisible visible. Same principle as the adoption dashboard we built for SUI, scaled down and made tactile.

The system that talks to machines

One of the last things the team built for Panot was an MCP server.

MCP is the standard protocol that lets AI agents connect to external systems and query them directly. Tools like Cursor, Windsurf, or Claude can use it to reach into a codebase, a database, a documentation site, and pull back structured information in real time. The Panot MCP server gives any AI agent access to the full system: all 225 components, every design token, every icon across both brands. An agent can search for a component, read its props, generate ready-to-use TypeScript code, validate existing implementations, and recommend the right token for a given context.

It means Panot is no longer just a Design System that designers and developers use. It’s one that AI agents can use too.

This wasn’t on the roadmap from day one. But it’s a logical extension of everything the team had been building since Spark: a system with clear structure, consistent naming, and documented intent throughout. The same qualities that make Panot easy for a developer to navigate make it possible for a machine to understand. Semantic tokens named for intent, not appearance. Components with typed props and documented variants. Icons organised by brand and tagged for search. The rigour that made the system good for humans turns out to be exactly what machines need as well.

I find this significant in a way that goes beyond Panot. For years, the argument for Design Systems was that they help teams move faster and stay consistent. That argument was always true. But it was an argument about human efficiency. The MCP changes the frame.

A Design System that an AI agent can read is not just a productivity tool. It’s an interface between your design decisions and a new class of collaborators who don’t open Figma, don’t attend design reviews, and don’t read Confluence pages, but can generate, validate, and extend your product at a speed no human team can match. The question is whether those collaborators can understand what you built and why. If the system is well-structured and well-documented, the answer is yes. If it isn’t, the agent does what a bad contractor does: it improvises, ignores conventions, and ships something that looks like your product but isn’t.

The Design Systems that will matter in the next few years are the ones that were built carefully enough that a machine can use them without breaking what makes them coherent.

Panot, almost by accident, is one of them.

The lesson the series has been building toward

I built my first Design System in 2017 with no mandate, no budget, and a shared belief with one developer that fifty button variants was not a design problem but a system problem.

Since then, every system has taught me something different. ODF taught me to show instead of sell. Delta taught me that a feedback loop is not optional. SUI taught me that visibility is what turns adoption into culture. Spark taught me that co-building is the only way to get four countries to share anything.

Panot taught me that all of it compounds.

You don’t have to reinvent the wheel if you built a good wheel the first time. But you do have to be intentional about which parts of the wheel you carry forward, and which parts you leave behind. That intentionality is not a one-time decision. It is the habit you build across every system, every team, every fork.

Build thoughtfully now. You will be grateful for it later, in ways you cannot always predict. Because the system you build for your design team today might be the same system that your AI agents use tomorrow to build your product.

That is what Panot is. Everything that came before it, made intentional again. And the first step toward what comes next.

Turo López Sanabria has over 20 years of experience in Design, and nearly a decade building the infrastructure that makes digital products coherent at scale. Five Design Systems. Several companies. Today, he works at the frontier where the line between building for humans and building for machines has started to blur.

The Design Systems series

Here’s where Panot sits in the story:

2017

2018

2019

2023

2025

One Platform for All of Europe

When Adevinta decided to go global, it picked a single platform to power the whole company: Germany, France, Italy, Spain, all of them running on the same foundation. The French platform was selected as the base. It was well-adopted, technically solid, and already had a Design System on top of it called Brikke.

The problem was that Brikke had never been built for what it now needed to do: serve multiple brands, multiple markets, multiple platforms, simultaneously.

The company looked across its regions for teams that had already dealt with multi-brand theming at scale. That experience existed in Spain, where SUI Components had been built to serve ten brands across four verticals. The company asked for that expertise directly, and it became one of the starting points for what would become Spark.

Four Systems, Each With Something to Offer

When I became Global Head of Design Operations, the situation across the company was four countries with four Design Systems, each at a different stage and moving in a different direction.

Spain had SUI Components: multi-theming capabilities, solid governance, real adoption. But it was built with Sass and CSS, and the new global platform was going to run on TypeScript. The architecture was not compatible.

France had a well-adopted Design System with strict code standards and strong engineering discipline. The challenge was that Brikke had never been designed for multi-brand. Making it work that way was going to be very hard.

Germany and Italy were earlier in their journeys, not yet at a stage where their systems could contribute significantly to a global foundation.

No single system could serve as the base. The decision was made to build something new, drawing on the strengths of each.

Listen Before You Build

The first thing the team did was not design. Not code. Not decide.

It was a listening tour.

We went to each team across the company and asked two questions: what is working in your Design System, and where does it break? What are you proud of, and what frustrates you every day?

This was not a formality. At eDreams years earlier, a visual audit of fifty button variants was what made the problem visible enough to solve. At Adevinta Spain, listening tours were what built the trust that made SUI adoption possible. The pattern holds at every scale.

When you start by listening, you earn two things no document can give you. First, the real constraints, not the theoretical ones, but the ones already causing daily pain. Second, the right to make decisions, because the people affected know you understood their situation before you acted on it.

Three Months of Negotiation

Then came the hard part.

The team that formed to build Spark brought together people from across the company. The core of SUI Components: Diego, Eli, Chris, Andrés, Jordi, and myself. Key developers from the French and German teams, who brought their engineering rigour and code discipline. The French UI team, experienced and precise, who knew Brikke’s visual language inside out. Later, Jere, a Design Systems specialist from Germany who understood the German brand constraints intimately.

An engineering manager came on board to oversee all the developers across web, iOS, and Android. And for the first time in any Design System I had been part of, QA was embedded in the team from day one. Not brought in at the end to validate. Present from the beginning, as part of the core. Accessibility was a hard requirement from the start, not something added after, which meant QA had to think about keyboard navigation, ARIA labels, contrast ratios, and screen reader compatibility on every component before it shipped.

The team hit the ground running. Infrastructure decisions were being made and early code was being written from the very first weeks. But one problem surfaced almost immediately, before a single component was complete: colour.

The colour decisions alone required weeks of back and forth. Kleinanzeigen, the German brand, had colour conventions that were incompatible with how SUI worked and how Brikke was structured. Everyone had made decisions they believed in. Everyone had reasons. And everyone was being asked to let some of those decisions go.

Beyond colour, the team negotiated on naming conventions, on TypeScript or not, on versioning strategy, on whether to have one documentation site or multiple, on where the Design System ended and brand expression began.

None of it was simple. But by the end, the team had something more valuable than a component library. An agreement.

Semantic Tokens as Political Architecture

The breakthrough on colour was the breakthrough on the whole system.

Instead of arguing about which brand’s rules should win, the team agreed on a semantic structure that could hold all of them. What does “main” mean across every brand? What does “support” mean? How many steps does a colour ramp need to serve everyone?

The naming approach itself, main, onMain, support, onSupport, is not new. Semantic token naming has become close to an industry standard. But adopting a convention and making it truly yours are different things. The team spent weeks fine-tuning every layer of the structure, stress-testing it against each brand’s edge cases, until every market could see a fair representation of its identity within the same system. That level of precision is what made it work at this scale.

Once the structure was solid, each brand could fill in their own values. One token named main. Four brands, four different colours. All of them correct.

This became the model for everything. Not “here are the rules everyone must follow.” But “here is the structure everyone can fill.” That difference sounds subtle. In practice, it is the difference between a Design System four countries adopt and one four countries resist.

Every token name in Spark is a small, settled argument. Around 110 of them, bridging Figma and code across TypeScript, Kotlin, and Swift.

A New Architecture

The technical decisions that shaped Spark were among the most ambitious the team had taken on.

SUI had each component as its own package. You imported Button, you imported Checkbox, each with its own Sass variables. Spark moved to a single package and replaced Sass with native CSS custom properties.

Sass variables resolve at compile time. CSS custom properties resolve at runtime. That is not a small distinction. It means theme switching, brand switching, and dark mode can happen dynamically, without rebuilding anything. For a system serving four brands across three platforms, this is fundamental.

It was also the team’s first time building dark mode at scale across web, iOS, and Android simultaneously. It worked because the semantic token structure was already solid. Tokens named for appearance, like blueLight500, make dark mode a nightmare. Tokens named for intent, like main and onMain, make dark mode a token swap.

Headless components completed the picture: the logic and behaviour of a component, decoupled from its visual expression. Teams could use Spark’s components and apply their own brand’s look on top. Structure shared. Identity preserved.

One honest admission: when Tailwind was proposed as part of the architecture, I was the first one to push back. It seemed too opinionated for a system that needed to serve radically different brands. I was wrong. At this scale, Tailwind turned out to be a great decision. It brought consistency to how utility classes were used across the whole platform, without getting in the way of theming. Being wrong about this quickly mattered.

The Team That Made It Possible

What made Spark work differently from previous Design Systems was QA embedded from the start.

In most systems, quality assurance happens after components are built. At Spark, it was part of the building process. QA engineers were not there to catch problems at the end. They were there to prevent them from the beginning.

This changed adoption in a way no dashboard or documentation ever could. When a brand team picked up a Spark component, they could trust it. Not because they were asked to. Because it had been tested across platforms, across themes, across the edge cases that surface in production. Trust built faster than any announcement.

The engineering manager mattered for a different reason. Having someone whose job was running the engineering side freed the rest of the team to focus on what they were good at. Clear ownership. Clear lanes.

Ship Early, Ship in Public

The team did not wait for Spark to be finished before showing it.

From the first week, progress was shared openly, even when that progress was two components and a handful of tokens. The theming artifact was released before the first component shipped, so platform teams across the company could start migrating to Spark’s token structure immediately. The foundation spread before the building went up.

Spark was open source from day one. Not primarily as a strategy. As a culture signal. The work was something to be proud of, nothing to hide, and the people who were going to adopt it deserved to understand how it worked, not just what it did.

By the time of launch, there was no surprise. Teams had been watching it grow. They had seen the decisions being made. Spark did not feel imposed from above. It felt like something that had been happening in front of everyone, with everyone.

What I Almost Didn’t Say

One thing about leading a Design System that rarely gets said out loud: you cannot do it if you do not understand code.

Not write it every day. Not be an engineer. But understand it well enough to have real conversations about architecture decisions, to know when a technical constraint is genuine and when it is a negotiating position, to earn the trust of the developers building alongside you. At the scale of Spark, the technical decisions were political decisions. You cannot navigate that without knowing what you are talking about.

One More Thing the Industry Gets Wrong

There is a strong belief that a Design System needs a Single Source of Truth: one place where everything lives, and everyone reads it.

At Spark, the team built ZeroHeight for designers and product managers, Storybook for web developers, and Dokka for Android developers. Three documentation surfaces, not one. Because developers, designers, and PMs do not read documentation the same way. Forcing them into the same format does not create alignment. It creates people who stop reading.

A Single Source of Truth works well for tokens and components. As a documentation strategy for a multi-disciplinary team, it is more idealistic than practical.

The Lesson

You can’t skip the listening.

Three months spent aligning on a colour structure may sound excessive. And there is always something more appealing about opening Figma and crafting components, or spinning up a TypeScript repo and writing real code. That is the visible work, the part that feels like progress. But spending weeks in the HEX universe, negotiating naming conventions and ramp structures across four brands, is where the real work happens. It is also where adoption is won or lost, long before the first component ships.

At the scale of four countries, you cannot build something new and ask people to adopt it. You have to involve the people who built the previous systems in building the new one. Not as reviewers at the end. As co-builders from the beginning.

When people see themselves in a system, they adopt it. When they do not, they tolerate it at best.

That is true of Design Systems. It is true of most things worth building.

Not long after, I moved back to Barcelona. Fotocasa, one of Adevinta Spain’s leading real estate platforms, needed a Design System of its own. The work inherited from Spark became the foundation for Panot. I did not know then that everything built across those four countries would make it possible to go even further. That is the next story.

Turo López Sanabria has over 20 years of experience in Design, and nearly a decade building the infrastructure that makes digital products coherent at scale. Five Design Systems. Several companies. Today, he works at the frontier where the line between building for humans and building for machines has started to blur.

The Design Systems series

Here’s where Spark sits in the story:

2017

2018

2019

2023

2025

When I joined Adevinta Spain, a Design System already existed. That was the good news. The bad news was that almost nobody was using it.

SUI Components had bare bones: a handful of React components built with Sass, a few UI kits scattered across Sketch files that nobody shared, and an adoption rate low enough that most of the company’s ten brands, across four verticals, were still building their own buttons, their own checkboxes, their own lists from scratch. Every team doing the same work, independently, slightly differently, every sprint.

Victor Sola, the UX director, had hired me because he believed something I also believe: that quality scales, if you know how to build the infrastructure for it. He had seen me do it before at eDreams. He trusted me to do it again, at a much bigger scale, across ten brands, in a company that was still learning what a Design System could be.

That trust turned out to be sixty or seventy percent of what made SUI work. The rest was the work itself.

The game changer was a person

SUI had not appeared from nowhere. A four-person platform team had built it, and they were proud of it. They had good reason to be. But they did not have the bandwidth to make it spread across the organisation. That was the gap I walked into: a solid foundation, a team that believed in it, and ten brands that were not yet using it.

One of the first things I did was convince the Head of Enablers and Platform to fund a full-time Design System developer. Not a developer borrowed from a product team. A dedicated hire, someone whose only job was to make SUI stronger.

That hire was Andrés.

When Andrés arrived, he looked at what we had and said, essentially: this is a very nice Design System for the future. But we are not ready for the future yet. There were no automated tests for the components. The system was designed to be adopted by everyone, but it was not actually built to handle everyone. It was aspirational in the best sense, and incomplete in the most practical sense.

From the moment Andrés joined, we started closing that gap. Tests. Infrastructure. Real component architecture that could survive real product teams using it at scale. The system started becoming something you could actually depend on, not just admire.

Javi Mota was my technical co-builder at eDreams. Andrés was that person at Adevinta. In both cases, the Design System only became real when design and engineering were genuinely building it together.

Making the invisible visible

One of the first things I built was an adoption dashboard. The company already had a script that crawled all the repositories and counted which SUI components each brand was using. I built the website on top of it, in React and Next.js, that made that data visible to everyone.

Every team could see exactly how many components they had adopted, and how that compared to every other brand in the company.

It was, quietly, a gamification engine.

Nobody told teams they had to improve their numbers. Nobody sent dashboards with targets and deadlines. But once teams could see their numbers, and see how those numbers compared to Infojobs or Fotocasa or Milanuncios, something shifted. Teams started wanting better numbers. Not because we asked them to, but because visibility creates its own kind of motivation.

We showed the dashboard in every Twitch session. We showed it at every company presentation we could get into. The number was always in the room.

Performing the work

The adoption dashboard was the internal visibility engine. The Twitch channel was the external one.

Every Thursday, live, we went on Twitch and talked about SUI Components. What we had built that week. What decisions we had made. What was coming next. Open source, open process, open conversation. Developers and designers from across the company could join, watch, comment in real time through Slack.

It sounds unusual. It was. But it worked in ways I did not anticipate.

Our own developers started watching the Thursday streams from their desks or from home. Seeing the system being built in the open, hearing the reasoning behind decisions, watching us fix things and explain why, made SUI feel real to them in a way that documentation never could. Documentation tells you what to use. Watching someone build it tells you why it matters.

And then there were the people who found us from outside the company. We were also giving talks at schools, presenting at conferences, writing articles about SUI on Medium. One of those articles was how Eli, one of the best designers I have worked with, discovered us. She read what we were publishing publicly, got excited by what we were building, and applied for a role on the team. The public work became a talent magnet.

By then, the team had grown into something real. On the design and component side: Diego, Chris, and Jordi. On processes, listening tours, and tools governance: Eli. Each of them covering ground that one person alone could never have reached.

Going public was not just a visibility strategy. It was a culture signal. It said: we are proud of this, we have nothing to hide, and we want other people to understand and use it.

One button, ten brands

SUI was the first multi-brand Design System I had built that included actual React components, not just Sass tokens. At eDreams, the theming layer was pure Sass: each brand overrode base variables and the components painted themselves correctly. At Adevinta, we kept the same principle but added the complexity of real component architecture.

Every brand installed SUI components as individual packages. Then they imported their own Sass variable overrides on top of the base theme. One button in code, ten brands rendered correctly. The Lego logic from ODF, rebuilt for React at scale.

But the most interesting design decisions were not technical, but strategic: the buttons we never replaced, all the times we said yes and no.

Just a simple example: SUI had a button component that was old. Not broken, but dated. Plenty of people requested a full redesign over the years. My answer, consistently, was no. Not because the button was good enough forever, but because it was already everywhere. Every brand was using it. Changing it in a major way would have disrupted all of them simultaneously.

So instead we released minor versions. Improvements, not replacements. We kept the adoption we had worked so hard to earn, and we made the button incrementally better, sprint by sprint.

Strategic patience. Know what you are optimising for. If the goal is adoption, protect adoption.

The Figma migration

At some point we knew we had to move from Sketch to Figma. Figma was clearly the future, and more importantly, it was better for a multi-brand Design System: shared libraries, real-time collaboration, a single file that all designers across all brands could work from simultaneously.

The migration took one month.

That speed was possible because by then we had a Design Ops infrastructure that knew how to move. We had learned how to migrate tools without losing the work. We had processes for versioning, for communicating changes, for getting teams onto new workflows without stopping their product delivery. The Design System was not just components and a documentation site. It was an operational system that could absorb change.

That is what Design Ops is for, in the end. Not to slow things down in the name of process. To make change faster by making it planned.

Be intentional

The lesson I carry most clearly from SUI into everything I built afterwards is this: in a Design System, intentionality is not optional.

Every decision needs a reason. Every tool you add needs a justification for why that tool and not another. Every deprecation needs to be explained. Every contribution model needs rules. Every place you store a decision needs to be findable by someone who wasn’t in the room when you made it.

This sounds obvious when you write it down. It is almost never practiced consistently. Design Systems accumulate decisions the same way products accumulate technical debt: quietly, at speed, until the weight of the past starts slowing down the future.

At SUI, I started being much more deliberate about this. Why are we using Sass and not another approach? Write it down. Why are we keeping the old button? Write it down. Why is this component in the system and not that one? Write it down.

Intentionality is what makes a Design System durable. Components change. Tools change. Teams change. The reasoning behind your decisions is what survives.

The relato

There is one more thing I want to say about SUI, and it is the hardest to explain.

In one of my 1st presentations of SUI to the public, I talked about the challenge of “mantener el relato del éxito,” keeping the success narrative alive. A friend and colleague, Isaac, had first named this struggle for me. You do three years of intense work, build something genuinely good, plant a flag. And then you turn around and the flag is gone. Someone new arrives and doesn’t know the history. Leadership changes. A new technology appears and suddenly what you built looks old. The narrative resets.

Managing a Design System is not just a technical and operational challenge. It is a communication challenge, permanently. You have to keep telling the story. Not because the work is not visible, but because organisations are large and distracted and full of people who were not there when you made the decisions that now hold everything together.

The dashboard helped. The Twitch streams helped. The articles helped. Every time we made SUI visible, we were also making the story of SUI visible. Why it existed. What it replaced. How much work it represented.

That is the thing I would tell anyone building a Design System in a large organisation: the system is not ready when the components are built. The system is ready when the organisation understands why it matters. And that second part never stops requiring effort.

The next system asked a different question entirely: what happens when four countries have to agree on a single button?

Turo López Sanabria has over 20 years of experience in Design, and nearly a decade building the infrastructure that makes digital products coherent at scale. Five Design Systems. Several companies. Today, he works at the frontier where the line between building for humans and building for machines has started to blur.

The Design Systems series

Here’s where SUI sits in the story:

2017

2018

2019

2023

2025

We Flew to Milan

Four of us flew from Barcelona to Milan to meet a team of designers and developers we believed were going to adopt Delta, the Design System Factory we had been building for months. An ambitious, state-of-the-art framework. At that point, we had documentation, Sketch libraries, onboarding videos, Frontify pages. No code or components delivered to any product team, but a lot of infrastructure for a system that hadn’t found its users.

We landed, took a cab to the office, walked in.

I still believe today that they didn’t even know we were coming.

Someone found us a meeting room. We spent the day there, the four of us, working as if the trip had a purpose. Late in the afternoon, one person joined us for about an hour to listen to our pitch. Then we flew back to Barcelona.

On the way home, I had a thought I couldn’t shake: nobody is waiting for us. Nobody is expecting us to deliver anything. Why are we doing this?

I had been asking some version of that question for months. I never got a good answer.

Eight Months of Planning

Delta was born from a genuinely exciting idea. Schibsted, a global marketplace company with dozens of brands and product teams scattered across countries and platforms, needed a way to scale design and development consistently. The vision was bold: a single Design System Factory, a shared infrastructure of components, tokens, and guidelines that any marketplace team could use to build their own Design System faster, with less effort.

A small team of four was assembled to build it. I joined as UX-PM for Design Systems, reporting to the Design Systems lead, excited by the scope of the problem and the ambition of the solution.

We used the right tools. We followed the right process, at least on paper. We documented everything. We made videos. We built onboarding materials in Frontify. We created Sketch libraries managed through Abstract with care and precision. We brainstormed. We planned. We planned some more.

Eight months in, we had not a single end user actively adopting the system.

My manager spent much of that time selling the idea to stakeholders across the company. I spent much of it questioning, quietly, whether anyone had actually asked for it. I would arrive at the office at nine, leave at five, and on a good week have two or three real interactions with designers outside our team. No one was asking us questions. No one was sending us their problems. No one was complaining about something we built, because no one was using what we built.

There is a particular kind of frustration that comes not from failure, but from irrelevance. We were not failing. We were just not connected to anything real.

Fifty Buttons

A few years earlier, at eDreams ODIGEO, I had done something much smaller with much more impact. We counted fifty-something variations of the same button across four brands and three platforms. A visual audit made the problem visible enough to solve. We built ODF, the eDreams Design Framework, and a couple of months in, a developer pulled me aside near the coffee machine: “Today is the first day in my life I wrote a full component without touching a single line of CSS. Thank you.” That moment was not planned. But it was enabled. ODF is the first article in this series, the full story is there.

At Delta, I waited months for a moment like that. It never came.

The Difference Is the Feedback Loop

I have thought a lot about what separated ODF from Delta. The scope was different. The companies were different. The people were different. So I am not trying to compare them directly.

But there is one thing I keep coming back to, and it is simple: one had a feedback loop and the other did not.

At eDreams, feedback was constant. A team’s colour tokens didn’t work for their use case, and they told us. We ran listening tours and people showed up. We presented to the whole company and the room was full of questions. Contributors added components we hadn’t thought of because they were using the system and saw what was missing.

Every complaint, every question, every request was a signal. The system was alive because people were using it, and they were using it because it was solving something they actually felt every day.

At Schibsted, I was waiting for that same signal and it never came. I wasn’t waiting passively. I was asking. Who is going to request components from us? Who is watching these tutorials? Which teams are expecting us to deliver something? The answers were vague or nonexistent, because the truth was that no one had been asked. No team had raised their hand. The system was being built not because someone needed it, but because someone thought it was a good idea.

There is a very big difference between those two things.

How to Tell If You’re Building Something That Matters

Design Systems are not special in this way. The same test applies to any product, any initiative, any internal tool.

Here is the question I now ask first: are people coming to you, or are you chasing them?

If your listening tour is packed, that is a signal. If it is empty, that is also a signal. If teams are reaching out with specific problems, specific constraints, specific use cases, that is a signal. If they don’t know you exist after months of work, that is a signal too.

If someone complains about something you built, celebrate quietly. A complaint means someone used it. Silence is far worse than a bug report.

The coffee machine moment cannot be manufactured. But it can be made possible. You make it possible by starting with a real problem, something visible and felt and annoying enough that the people living with it would actually welcome a solution. Not a trend. Not a best practice imported from a conference talk. A problem that exists today, in your product, that you can point to and say: look. Here is where it hurts.

Then you build something small that addresses it. Not the full system. Not the perfect infrastructure. Something real, that someone can use, that produces a result they can feel.

Then you wait for the feedback. That feedback is your north star.

Why Delta Was Still Worth It

I left Schibsted after eight months. It was the right call. But I want to be clear: I do not think the people I worked with were wrong to try. The vision was real. The problem they were trying to solve was real. Global companies with dozens of product teams and no shared infrastructure genuinely need what Delta was attempting to build.

What was missing was not ambition or skill. What was missing was a starting point grounded in a real, specific problem that real, specific teams were already feeling. And a willingness to start small, ship something, and let the feedback tell you whether you were heading in the right direction.

A Design System is not a Figma library. It is not a Frontify page or a Storybook or a Sketch file. A Design System is a feedback loop between the people who design and build products and the shared decisions that make that work faster and better. Without the loop, you have documentation. You might have beautiful documentation. But you do not have a system.

Delta taught me that more clearly than any success ever could.

If you are building a Design System today, or any shared product infrastructure, ask yourself: who is coming to me with their problems? Whose work is my system making easier right now? If you cannot answer those questions, you are not building yet. You are still looking for the problem.

Find the problem first. Everything else follows.

The next system would be the one where I finally got the feedback loop right, at a scale that still surprises me.

Turo López Sanabria has over 20 years of experience in Design, and nearly a decade building the infrastructure that makes digital products coherent at scale. Five Design Systems. Several companies. Today, he works at the frontier where the line between building for humans and building for machines has started to blur.

The Design Systems series

Here’s where Delta sits in the story:

2017

2018

2019

2023

2025

It Was 2017. Figma Didn’t Exist Yet.

The year is 2017. Figma is not yet on anyone’s radar. React is still finding its footing. Most design teams are working in Sketch, and the brave ones are managing design decisions through Sass variables. And somewhere inside eDreams ODIGEO, one of Europe’s largest online travel platforms, I’m staring at a product that has fifty or sixty different variations of the same button.

Fifty. Buttons.

And that’s just buttons. Same story for colours, spacing, typography, each drifting independently across four different brands (eDreams, Opodo, GoVacances, TravelLink) and three platforms (web, iOS, Android). We had merged these brands under one front-end, with the intention of painting the same building blocks in different brand colours. The architecture was right. The execution wasn’t.

The same components were being designed and coded from scratch, over and over, every single sprint. For every brand. On every platform. Back then we called it modular design (later renamed atomic design), and very few teams were actually doing it.

This wasn’t an eDreams problem. This was a design industry problem. We just decided to do something about it.

The Birth of ODF

ODF stands for eDreams Design Framework. It was the Design System I created and led at eDreams from scratch, and it became one of the most impactful initiatives I’ve been part of, recognised at an internal company innovation competition after a full year of building it across the organisation.

But it didn’t start with a pitch to the CEO. No slide deck, no roadmap, no budget request.

It started at the code level. And on the design side too, both in parallel. It started with a conversation with a developer, Javi Mota, who co-built the system with me, and a shared belief that we could fix something broken.

The first step wasn’t a meeting. It was a visual audit. We looked at the product honestly and catalogued every inconsistency we could find. Fifty button variants. Multiple shades of the same colour. Spacing and typography that had drifted so far from any original intention that there was no original intention left.

Once you’ve seen the problem that clearly, you can show it to others. And that’s when the real work started.

Show, Don’t Sell

One of the most important decisions we made with ODF was this: we would never try to sell the idea. We would show it working.

Instead of going to leadership with a concept, Javi and I worked in parallel on two fronts at the same time: the Sketch designs and the code. We built the foundational Sass variables, design decisions encoded in code, aligned with the design work from day one. Then we went further: we created a living documentation website, built with a tool called KSS, that auto-generated documentation directly from code comments. Any designer or developer in the company could open it, navigate the sidebar, and see every component, interactive, in all four brand colours, across desktop and mobile, right there in the browser.

This wasn’t a Figma file. This was the actual production code, running live.

That documentation site was a turning point. Adoption doesn’t follow conviction. It follows clarity. When people can see what a Design System enables, they start using it.

And then one afternoon, standing by the coffee machine, a developer pulled me aside:

“Today is the first day in my life that I wrote a full component without touching a single line of CSS — and everything I built is aligned with what the designer asked for. Thank you.”

That moment was worth more than any internal presentation.

Lego Blocks for Four Brands at Once

The technical model behind ODF was modular by design, closer to Lego than to templates.

If you needed a button, you started with ODF button. Want it to be primary? Add ODF button primary. Need it large? Add ODF button large. Each class was a Lego brick. You composed the result by combining bricks, and the same combination produced the correct output for all four brands simultaneously, styled through brand-specific Sass variables.

One button in the code. Four brands rendered correctly. Zero duplication.

The same logic extended to icons. In the old world, adding a new icon meant opening a font editor, generating new font files in multiple formats, and pushing to production through a full release cycle, for each of the eight font variants across brands and platforms. With ODF, a designer saved an SVG into the icons folder, and the system auto-generated the font, made it available across all brands and devices, and sized it correctly relative to surrounding text.

One file drop. Done.

The goal wasn’t just efficiency. It was eliminating uncertainty. As I said in the internal presentation where we launched ODF to the company: “We are killing uncertainty with this.”

Building Adoption, One Ambassador at a Time

We didn’t broadcast the system and hope for the best. We started small and strategic.

I identified ambassadors: designers and developers who shared the same attention to detail, the same impatience with unnecessary rework, the same belief that the quality of what we shipped actually mattered. I brought them in first. Let them experience the system. Let them become advocates.

From there, adoption spread organically. Not because we mandated it, but because the system was genuinely useful.

One of my favourite examples: a team member named Manu noticed we were missing a small alert component: a green dot with a bouncing animation to indicate something was new. He built it himself: designed it, coded it, wrote the documentation, and submitted it. It went into the framework. From that point on, anyone who needed that pattern had it ready to use.

That’s the contributor model we built: not a centralised team owning everything, but every team empowered to extend the system responsibly.

That said, resistance came too, especially from designers who worried the system would constrain their creativity. I addressed this directly: a Design System doesn’t ask you to stop designing. It asks you to stop redesigning things that are already solved. Spend more time thinking about the right solution. Less time drawing the same button for the fourth time.

A few months in, the evidence spoke for itself.

What ODF Delivered

The impact aligned with what we now know Design Systems produce, but back in 2017/2018, we were discovering this in real time:

A shared source of truth. ODF became the shared reference for resolving disagreements between disciplines. Debates about button styles and spacing stopped living in Chat and started being answered by the system, an accessible reference point for agreed decisions.

Faster delivery. By eliminating the need to re-solve already-solved problems, teams redirected energy to actual product work. We weren’t just saving time, we were moving it to where it mattered. Design, development, and QA all got faster. If something was built with the framework, it should look exactly like the design. If it didn’t, the problem was clear: someone wasn’t using the framework.

Better quality. Fewer back-and-forths between design and development. Fewer gaps between spec and implementation. The system also produced dramatically smaller CSS files. Less duplication meant better performance at the code level.

A shared language. A “large spacing” meant 16px, always. No ambiguity. No translation layer. When a designer linked to a specific component in a Confluence page, or pasted the link into a chat, the developer clicked it, landed on the exact element, copied the code, and got the right result across all four brands. Communication collapsed from paragraphs to a URL.

Stored decision-making. Every design choice, every colour, spacing value, typography rule, was encoded somewhere. It stopped living in someone’s head and started living in the system. This protected our decisions from the inevitable turnover and direction changes any company experiences.

All of this was happening while eDreams was going through an agile transformation. It turned out that a Design System and agile were natural allies. Both push toward efficiency, speed, and removing waste. The timing couldn’t have been better.

The Hard Parts

It wasn’t smooth sailing, and I’d be doing you a disservice to pretend it was.

Technically, I had to get my hands dirty in ways I hadn’t before: learning Sass properly, working in the terminal, understanding how design decisions actually translate to production code. My curiosity about how things worked helped, but the learning curve was real.

Organisationally, ODF was a side project. No official mandate. No dedicated time from leadership. Everyone was already busy shipping features. We had to make it happen alongside everything else, quietly, consistently, without waiting for permission.

Cross-platform turned out to be the hardest challenge. iOS, Android, and web had different codebases, different visual conventions, and different cultures. Native developers and designers rightly wanted to stay close to native platform patterns, not just inherit from web. In the end, ODF became a full Design System for web, and a design foundation for the other platforms: what we would call design tokens today, though that term didn’t exist yet when we built it.

What Still Holds True

Looking back from 2026, I think ODF got the fundamentals right. Not every technical call, but the philosophy underneath it.

Here’s what I’d tell someone building a Design System today:

You can have all the parts and still not have a system. A Figma library with every component isn’t a Design System. A Design System is a living agreement between designers, developers, and the product, about how decisions get made, documented, and shared.

Build it as a communication tool from day one. ODF’s primary purpose was never efficiency. It was communication. When I asked whether a designer no longer needed to design because everything was in the system, my answer was: no. I need you to think. Which button should this be? What does the user need? The system handles the how. You still own the why. If your design files aren’t connected to your code, you have two parallel worlds that will inevitably drift apart.

Documentation is not optional. It’s the product. The living site we built was arguably as important as the components themselves. Easy access to clear documentation is what turns a collection of assets into a system people actually use. A link you can paste into a chat, that opens the exact element with the exact code. That’s the system working.

Show, don’t sell. Nobody believes in a Design System that doesn’t exist yet. Build something small, make it work, and let people experience it. The coffee machine moment can’t be planned, but it can be enabled.

A Design System is a living being. It evolves. It corrects wrong decisions after they’ve been implemented. It absorbs new technology: AI, new tools, new patterns. The Design Systems of today are integrating with tools like Figma, Lovable, and Cursor in ways we couldn’t have imagined in 2017. The principles remain constant. The implementation keeps moving.

Why This Story Still Matters

Design Systems didn’t exist when the internet was young. And then, gradually, they became the natural and necessary evolution of how we design and build digital products at scale.

What we built with ODF in 2017, without Figma, without design tokens as a named concept, without modern component frameworks, was proof of something fundamental: the challenge of scaling design and development decisions is a system problem, not a tool problem.

The tools have changed dramatically. The problem hasn’t.

If you’re building a Design System today, the most important thing isn’t which tool you use or how many components you have on day one. It’s whether the system helps your team make better decisions, share them clearly, and know what to do even when they need to break the rules.

That’s what ODF did in 2017. And that’s what the best Design Systems still do today.

The next system would test something I didn’t know I needed to test: whether anyone wanted it at all.

Turo López Sanabria has over 20 years of experience in Design, and nearly a decade building the infrastructure that makes digital products coherent at scale. Five Design Systems. Several companies. Today, he works at the frontier where the line between building for humans and building for machines has started to blur.

The Design Systems series

Here’s where ODF sits in the story:

2017

2018

2019

2023

2025

Not in this universe.

The Tools Were Great. The Future Had Other Plans.

I finished my degree in Graphic Design in 2001. The course was full of rules: composition, typography, colour theory, print production. Then I stepped into the web, and it felt like the opposite of all that. A new world, almost without constraints. No production costs. No print runs. No physical limits.

The tool that captured that spirit best was Macromedia Flash. You could make things move, respond, surprise. We believed — genuinely believed — that the web would evolve towards something closer to animation and advertising than to editorial design. Full-screen experiences distributed on auto-executable CDs. Microsites. Banners that took over the page.

Clients weren’t asking for anything different. Brands saw the internet as a place for identity, not for products.

This wasn’t a minority position. Design schools were teaching websites as a form of creative expression, free of the constraints that governed everything else. And there was a reasonable argument for it: unlike a newspaper or a car, digital could be corrected after delivery. You could fix things. Ship, then iterate.

That flexibility, it turned out, had a cost. We just couldn’t see it yet.

The Web Grew Up Faster Than We Did

Screens started multiplying. Speeds increased. Interactions became richer. And then smartphones arrived, and everything we thought we understood about designing for a screen had to be rethought.

Suddenly one product needed to work on a 320px phone, a 768px tablet, a 1440px desktop, and a TV. Each at different resolutions, in different orientations, for different contexts. A user on the subway needed something different from a user at a desk. “Multi-device” wasn’t a feature request. It was the new baseline.

We reacted by going granular. Design every state. Every breakpoint. Every micro-interaction. Control everything. The pixel-perfect mentality, which made sense when a single screen was the canvas, became an obsession that didn’t scale. You cannot hand-craft every combination of every component across every device for every team working in parallel. The maths don’t work.

And the tools were still catching up. Many of us had moved from Flash to Fireworks, then to Photoshop for UI work, tools built for retouching and illustration, not for designing systems of reusable parts. Sketch arrived and felt like a revelation. Then Figma. But by the time the tools were right, the products had already grown far beyond what any individual designer could hold in their head.

The Code Side Got Complicated Too

On the development side, something significant was shifting.

In the early days, a web page was mostly a static template that the back-end would fill with content. Your computer received a finished page from a server. Each interaction triggered a round trip: request sent, page returned, page rendered. The front-end was largely decorative. It coloured and animated what the server sent back.

That changed. The front-end started carrying real logic. Frameworks like React and Vue made it possible to build genuinely complex behaviour in the browser without a constant back-end round trip. Filters, dynamic content, real-time updates, personalisation: all of it running in the client. The front-end became a product in its own right, not a skin over a server response.

This meant components were no longer just visual elements. They had state. They had behaviour. They had data flowing through them. The same button could appear in ten different contexts, each with slightly different requirements. The same form could be used across six products with different validation rules.

And the environment kept adding complexity. Third-party services, payment gateways, chat widgets, analytics scripts: each one integrated into the product but built by a different team with different rules. Cloud infrastructure introduced real costs around traffic and data. SEO requirements meant the code had to be semantically correct, not just functional. Accessibility went from an afterthought to a legal consideration in many markets.

Each new requirement was reasonable on its own. Together, they produced something almost unmanageable.

The Debt Nobody Talked About

All of that complexity left a residue.

Technical debt accumulated quietly. The same solution programmed five different ways by five different developers, each one technically correct, none of them consistent with the others. Style rules written inline because there wasn’t time to do it properly. A design decision made in a rush that got locked in because too many things depended on it.

Design debt piled up alongside it. Colours that drifted slightly between products. Spacing that was eyeballed rather than defined. Typography choices made by a designer who left two years ago, now replicated by everyone who came after because it was already there and changing it seemed risky.

The worst part wasn’t the inconsistency. It was where the decisions lived. In someone’s head. In a Slack message from 2019. In a Confluence page that nobody had updated since the team restructure. When the person who made the original call left the company, the reasoning left with them. What remained was the output, stripped of its context.

Adjusting something “2px to the left because it looks better” was a normal design review comment for years. Not because designers were being precious. But because there was no shared reference point. No system to appeal to. Every decision had to be argued from scratch.

The Complexity Was the Signal

Looking back, it would be easy to frame all of this as a series of mistakes. We used the wrong tools. We moved too fast. We didn’t plan for scale.

But that’s not quite right either.

The web genuinely was a new medium, and we were figuring it out as it grew. The Flash era produced real creativity. The pixel-perfect obsession came from caring about quality. The technical debt was often the cost of shipping quickly in a competitive market, which is sometimes the right call.

What changed wasn’t that the industry got careless. What changed was that the medium matured, and the old ways of working stopped being adequate for what the products had become.

A single designer can hold a single product in their head. Two designers can negotiate. Ten designers across five teams building for eight platforms under three brands cannot operate on negotiation and goodwill alone. The coordination cost becomes the product cost. The inconsistency becomes the user experience.

Design Systems didn’t emerge because someone had a clever idea about atoms and molecules. They emerged because the alternative, continuing to design and build digital products as if they were independent artefacts, stopped being viable. The mess was the signal. The system was the response.

The question was never whether to build one. It was whether to build it deliberately, or let it build itself out of accumulated habit, technical debt, and design debt.

Turo López Sanabria has over 20 years of experience in Design, and nearly a decade building the infrastructure that makes digital products coherent at scale. Five Design Systems. Several companies. Today, he works at the frontier where the line between building for humans and building for machines has started to blur.

Read the companion pieces:

The friction is everywhere. And it’s quiet. Nobody is shouting. Nobody is being difficult. They’re just spending enormous amounts of energy on problems that should have been solved already.

That’s when the value of a Design System becomes undeniable. Not in a conference talk. Not in a pitch deck. In that room.

Why the question gets asked

The question “what’s the value of a Design System?” is usually asked by someone who needs to justify an investment. A manager being asked to allocate headcount. A design lead being asked to explain why a component library takes time. A practitioner being challenged to prove ROI.

That’s a reasonable thing to need. But the framing is slightly off.

The more useful question is not “what do you gain from having one?” It’s “what breaks without one?”

Because the value of a Design System is often invisible when it’s working. When a developer can build a new feature using components that are already tested, accessible, and consistent with every other part of the product, that’s not remarkable. It’s just Tuesday. The absence of the Design System only becomes visible as accumulated friction: duplicated work, repeated conversations, inconsistent outputs, a codebase where the same problem has been solved five different ways by five different teams.

When I sit down with a team that doesn’t have a working system, the list of what’s broken is almost always the same: Decisions are made but not recorded, so they get made again. Work is done in isolation, so the same component gets built three times across three products. Quality is inconsistent, because every new piece starts from scratch rather than building on something already validated. And the communication between design and development is slow, because there’s no shared language to fall back on.

Agreement. Efficiency. Quality. Communication. These aren’t abstract benefits. They’re the things that are quietly falling apart in every team that hasn’t solved this problem.

The value depends on where you’re standing

There’s no single answer to the value question. And anyone who gives you one clean number, or one universal benefit, is simplifying something that’s genuinely layered.

A developer sees a Design System and thinks: fewer decisions to make, more time to work on actual problems, less time maintaining bespoke code that only one person understands. A designer sees it and thinks: consistency without constant policing, freedom to focus on new problems instead of re-solving old ones, a way to move faster without sacrificing quality. A product manager sees it and thinks: faster time to market, fewer QA cycles, lower risk of shipping something that’s off-brand or inaccessible.

All of them are right. The Design System is producing different value for each of them, simultaneously.

And then there’s the less visible benefit: maturity. A team that builds and uses a Design System is a team that is being forced to make real decisions and write them down. To agree on things that were previously left ambiguous. To develop a common vocabulary. The system makes all of that harder to avoid. And in doing so, it accelerates how quickly a team develops shared understanding.

That’s not a component library benefit. That’s an organisational one.

The question disappears

Something interesting happens to teams that have built a working Design System and lived with it long enough for it to become infrastructure.

They stop talking about it.

Not because it stopped mattering. Because it stopped being the thing that needs defending or explaining or justifying. It became part of how the team works, like version control or code review. Nobody is asking “what’s the value of pull requests?” They just open one.

The conversation I keep walking into in teams without a system, the one about what was agreed, and who said what, and why this component looks different from that component, is the exact conversation that doesn’t happen in teams where the system is working. The friction I can feel in the room is the negative space where the Design System should be.

That’s the honest answer to the value question. It’s not a list of features or a set of metrics. It’s a specific kind of silence. The absence of a problem you stopped having.

Turo López Sanabria has over 20 years of experience in Design, and nearly a decade building the infrastructure that makes digital products coherent at scale. Five Design Systems. Several companies. Today, he works at the frontier where the line between building for humans and building for machines has started to blur.

Read the companion pieces:

That Figma file wasn’t a Design System. It was a start. There’s a significant difference.

The definition I keep coming back to: a Design System is the official way in which a company designs and develops its digital products. A set of rules, processes and tools that help make intelligent and coherent decisions.

The most important word in that sentence is not “design.”

Why This Level of Complexity Even Exists

To understand what a Design System actually solves, you need to understand the scale of the problem.

Take a company like Fotocasa, a real estate marketplace I worked with. On the surface: one product. In practice, it’s a constellation. Applications for professionals, for individual sellers, for home hunters. Each of those products lives across a website, a native iOS app, an Android app, and various touchpoints in advertising and social media. And behind all of it, multiple independent teams. One handles search and filtering. Another owns account creation. Another manages everything that happens once you’re logged in.

These teams work autonomously. That’s intentional, it’s how you move quickly. But they’re building parts of the same experience. A user might browse on their phone, create an account on their laptop, and complete a transaction on their tablet. Every hand-off needs to feel like the same product.

Visual consistency in that environment isn’t a nice-to-have. It’s structural. And reusable symbols in a design tool, or shared components in a code library, get you part of the way there. But only part of it.

What Doesn’t Make a Design System

Style Guides and Brand Manuals have existed for decades. Car manufacturers, packaging designers, newspaper editorial teams: all of them have been solving consistency problems at scale long before anyone built a website.

The Lego analogy. The recipe analogy. The atoms-and-molecules analogy. All of them capture something real about how a Design System works. But none of them explain why a Design System is different from what came before.

Here’s the distinction: a Style Guide tells you what things look like. A Design System tells you how decisions get made.

You can have every token exported, every component documented, every pattern catalogued, and still not have a system. I’ve seen it many times. The parts exist. The agreement doesn’t.

Equally, I’ve seen teams with no shared Figma library, no component framework, barely any documentation, who are genuinely operating as a system. They talk to each other. They share a language. When someone says “L spacing”, everyone knows what that means. The system is in the culture, not just the tools.

The Word That Actually Matters

The reason we need Design Systems now, and didn’t always, is that digital product development has become genuinely complex in a way it wasn’t before.

Twenty years ago, I was designing for the web using tools built for posters and advertising. Each page was painted independently. Consistency was a goal, not a requirement. There was no “multi-device reality”. Smartphones didn’t exist. Accessibility wasn’t in the conversation. A designer could change something without a deployment pipeline, without worrying about traffic costs, without understanding how a component would behave across six breakpoints.

That world is gone.

Today, the front-end carries an enormous amount of logic. Components aren’t just visual elements, they’re behaviour, state, data. The same piece of design and code gets reused, modified in real time, adapted to context. A single button might appear on web, iOS, Android, in a third-party payment gateway, in a marketing email. It needs to be consistent, accessible, performant, and easy to maintain.

This isn’t about tools getting better. It’s about the problem getting bigger. Design Systems are not a trend. They are the natural and necessary evolution of how you manage that complexity at scale.

What the System Actually Does

A good Design System is not a collection of assets. It’s a living agreement.

It gives teams the ability to make decisions and know what to do at any given moment. Not just when following the consensus, but also when they need to break from it. That’s why documentation matters more than most people think. Not a gallery of components. A reference you can link to, quote in a conversation, open in a meeting to resolve a disagreement.

“Large spacing means 16px. Here’s the link.” That’s a system working.

It’s also, genuinely, a living thing. Not just in the sense that it evolves over time, updating with trends and absorbing new technology. But in the sense that it corrects wrong decisions after they’ve been made. It’s designed to change. That’s a feature, not a flaw.

You can have a system that works perfectly well without a unified technology platform. You can still ship consistently even while migrating half your code to a new framework. You can operate well with imperfect tooling.

What you can’t do without is the agreement underneath it all.

A Set of Rules, Processes and Tools

The reason I keep returning to that original definition is the order of the words.

Rules first. Processes second. Tools third.

Most teams start from the other direction. They build the tools, assume the processes will follow, and discover later that the rules were never really agreed. The Figma library gets built. The component library gets built. The documentation gets built. And then someone on a new team asks a reasonable question about an edge case, and there’s no answer anywhere, because nobody agreed on the rule behind the component.

A Design System asks you to work backwards from the decision. What do we want to be true about this product? How do we want to make decisions when new problems arise? Only then: what tools will help us do that?

The teams I’ve seen build the best systems weren’t the ones with the most components. They were the ones with the clearest sense of what they were trying to agree on.

Turo López Sanabria has over 20 years of experience in Design, and nearly a decade building the infrastructure that makes digital products coherent at scale. Five Design Systems. Several companies. Today, he works at the frontier where the line between building for humans and building for machines has started to blur.

Read the companion pieces:

The Single Source of Truth is the most seductive lie in Design Systems. I know, because I’ve spent years building documentation that nobody uses.

While Developers and Designers would work with their own stack, their own world, I kept obsessing over the idea that if we could just get everyone work from one single, definitive source of truth. I kept building. Centralising. Documenting. With the hope that everything would eventually click into place.

It took one conversation to make me realise I was in love with an idea that makes no sense. The signs had been there all along, hiding in plain sight, in every frustrated developer, every ignored doc, every meeting about the same thing for the hundredth time. I was the last person in the room to see it.

The Box

Let me paint you a picture.

Somewhere out there, a person with diabetes relies on a Personal Assistant App that monitors their blood sugar and sends them a notification every time their levels reach a critical threshold. For them, it’s simple. An alert appears. They act. It could save their life.

Now zoom out. Behind that App there’s a team: designers, web developers, iOS developers, Android developers, all working together to make sure that notification reaches that person, flawlessly, every time, on every device.

To build it consistently, that team needs components. And imagine those components live in a box. Centralised. Tested. Reusable. You reach in, grab what you need, and the product is consistently good.

This box represents something powerful: trust. You don’t need to know how it was built or who wrote the logic. You just grab the right part and ship.

This box is what the Design Systems industry has been chasing for years. The single source of truth.

And on the surface, it sounds perfect.

The Problem with the Box

Here’s where things get complicated.

A notification on iOS is not the same as a notification on Android. And neither of them is the same as a browser push notification on Web. They look similar to the user: a little alert, some text, maybe an icon. But underneath they are entirely different animals. Different permission models. Different delivery systems. Different UI constraints. Different native patterns that users on each platform have been trained to expect.

So your one box suddenly needs to hold three completely different versions of the “same” component. And that’s before design even enters the picture, because the Figma component a designer uses to prototype a notification isn’t something any developer can ship directly. It’s a representation. A sketch of the real thing.

So now you have four boxes. One for design, one for Web, one for iOS, one for Android. Each one legitimate. Each one necessary.

The industry’s response? Build one giant warehouse. One enormous catalogue where every discipline finds their version of every component. A multi-platform Design System. Problem solved.

Except in real life Web, Android, iOS devs and Designers don’t shop at the same store. Each discipline lives in a completely different tool, a completely different mental environment. The warehouse exists. Nobody really uses it the same way. And the team maintaining it, usually us, the Design Systems people, ends up spending most of our time being librarians and police officers instead of creating actual value.

Beckett

About a year before I gave a talk on this topic, I was on a video call with Beckett (not his real name). He was the Android lead on a product we were building together. First-rate engineer, sharp, collaborative. We’d had several polite conversations about the same topic: getting the dev team to align with our centralised documentation in ZeroHeight.

Then one day, he looked straight into the camera, the kind of look that tells you someone is done being polite, and said:

“Every minute I spend consulting a catalogue outside my development environment is a minute I’m not creating value for this product. There is no valid use case where your documentation is better than my API docs in Dokka, my own code, and its comments.”

My first reaction was resistance. Beckett just doesn’t want to adapt. Classic change resistance.

So I asked the iOS team. And the web devs. And QA. And one by one, they all said essentially the same thing:

The only source of truth that matters to me is the one that exists inside my working context.

That week I had to sit with something uncomfortable: I hadn’t been building bridges. I’d been building a monument to an idea.

Context Is Everything

What Beckett understood, and what I had to learn the hard way, is that context isn’t just where information lives. It’s how information relates to the natural flow of how someone thinks and works.

A designer thinks visually. They need to see spatial relationships, interaction states, component hierarchies, in Figma.

An Android developer thinks in terms of Kotlin architecture, component trees, platform-specific constraints, in their IDE.

Forcing both of them to consult the same external catalogue doesn’t unify them. It interrupts them. It pulls them out of their flow and asks them to translate between two different mental models before they can get back to work.

The documentation tools are powerful. I’ve used and advocated for special pages in Sketch libraries, guidelines in Figma, Frontify, ZeroHeight, InVision. All of them. And they have their place: a reasonably up-to-date snapshot of what exists across your universe. A map.

But a map is not the territory. No designer can design from a catalogue entry. No developer can write code from a documentation page. These tools tell you what’s in each box. They are not the box.

The Real Source of Truth

Here’s what I believe now:

A single source of truth cannot exist. Truth depends on context. And context is almost always different for each discipline.

What we actually need isn’t one box. We need multiple boxes, each one living exactly where each discipline works, connected not by a shared tool, but by a shared language.

When we built Spark, the most ambitious Design System I have ever been part of, twenty people across four countries and three platforms, we made a deliberate choice about documentation. Instead of one unified catalogue, we built three separate surfaces: ZeroHeight for designers and product managers, Storybook for web developers, and Dokka for Android developers. Three surfaces, each living exactly where each discipline works. Forcing everyone into the same format doesn’t create alignment. It creates people who stop reading.

If we all agree that buttons come in small, medium, and large, that colours are Main, Accent, and Support, that shared vocabulary is more than enough to build excellent products together. The main token in Panot is the clearest example I can give you. One name agreed across the whole team. In Figma, a variable. In CSS, --colors-main. In Kotlin, a resource reference. In Swift, something else again. Four different implementations. One shared vocabulary. That is the system working.

The specific hex values matter less than the agreement. The alignment matters more than the artefact.

A note in a pull request is worth more than a comment in ZeroHeight. A weekly sync, a pair-design session, a shared prototype review: these create shared understanding in a way that no catalogue ever will.

When you’re talking to an iOS team, speak iOS. When you’re presenting to designers, speak design. Professional empathy, meeting people in their context, is more valuable than enforced standardisation.

The Paradox

I’ve spent a lot of my career trying to get everyone to speak exactly the same language. And what I’ve discovered is that the harder you push for that, the less real communication happens.

The documentation we’re so proud of? It’s often killing the authentic dialogue that drives real innovation and alignment.

Rules first. Processes second. Tools third. Most teams start from the other direction, and wonder why the system never feels like it truly belongs to everyone.

We don’t need a single source of truth. We need multiple truths that talk to each other.

The box was never the answer. The conversation was.

Turo López Sanabria has over 20 years of experience in Design, and nearly a decade building the infrastructure that makes digital products coherent at scale. Five Design Systems. Several companies. Today, he works at the frontier where the line between building for humans and building for machines has started to blur.