← Back to work Whitelabel design system

Retto

Seven fragmented design systems turned into a single source of truth.

On the design side adoption was total: the three of us worked across all six products, and all of us worked on the system, from spec through to supporting development. Beyond the active products, independent projects picked it up too, such as the CMS for internally generated web pages.

The problem

Seven design systems, and none of them by accident.

Conectera ended up maintaining seven separate design systems. We assumed each product deserved its own, so every time we started a new one we built it one more. The model broke on its own, and it was the evidence that changed our minds.

I had worked on five of those seven, on some more than others. Put another way: a good part of what had to be dismantled I had built myself. Several never reached development, either because the product stopped or because there was no time to keep them up to date. And since the company was constantly creating products, every new project started by solving from scratch the same questions already answered four times over. Visual inconsistencies were argued case by case, in every module, every time.

There was a second problem, less obvious. The first systems were born as adaptations of Material Design. They worked, but the company's entire portfolio ended up looking like Google instead of looking like itself.

The conclusion: we needed a single source of truth, whitelabel, feeding every product by swapping brand and typography instead of rebuilding the system, and with a language of its own.

My role

• · I directed the design phase and split the components across the team, coordinating 2 designers.
• · I designed and documented components directly, not just coordinated.
• · I defined the visual direction of several components and proposed the creation, editing and traceability templates that live in Figma.
• · I proposed the token architecture: the whitelabel approach and the two-layer scheme.
• · I compiled and adjusted the governance from what the team formulated.

What was not mine: the component code was written by the developers from our specifications. From design we reviewed how each one behaved visually and handed over the template for how it should be presented. The project was not a commission either: we started with a product and, while designing it, it became clear we had knowledge scattered across seven dead systems worth pulling into a living one.

Process

Audit before building.

We audited the seven previous systems to see what we had proposed and what survived. In parallel we went through the products the system was meant to serve, to know which components we would actually need and what each one had to cover.

Atomic design was something I brought into the company: it was not in use, I proposed it with the argument for why it fitted here, and that is why we adopted it. We started from the base pieces (the button, the inputs, the tooltip) because those are what later compose molecules and organisms. That order was not aesthetic: without the foundations settled, every composed component would have reopened decisions already made.

Adoption, usually the hard part, was not so hard here. The concept of a design system was already established in the company, so development and the PM understood the time-saving promise from the start. And since the initiative came from design, inside the team it was mandatory: every screen designed in Figma had to be grounded in the system. What convinced everyone else was the evidence: as the developers implemented it, building screens became trivial and they could concentrate on the backend and the logic.

Decision · Tokens

Two token layers, on purpose.

I proposed the whitelabel approach and structured tokens in two layers (primitive and semantic) instead of a more granular scheme. What I ruled out: a fuller architecture with an extra layer at component level.

I had been studying tokenization on my own and the rest of the team was not into the subject. Two layers was the most that could be understood and implemented well from day one, so I preferred an architecture the team would use correctly over a technically superior one applied halfway. The third layer was not ruled out in a discussion: nobody raised it, and that is where what I would add today sits.

What I anticipated: that we would need to apply the system to more products than existed at the time. That is why whitelabel was not a requirement handed to us but a proposal. If the goal was one system for everything, the brand had to be a variable, not a rewrite.

Decision · Accessibility

Accessibility as a baseline, not as a review.

I scoped it rather than announcing "accessibility" in the abstract. The people using these products are administrative profiles who spend the whole working day inside the tool, so the effort went where it pays off for them: the visual guidelines —WCAG 2.1 and 2.2 contrast, hierarchy and density— and keyboard navigation in every component, documented key by key. It was not a requirement imposed by anyone: it came from the design team.

The logic is simple: if accessibility goes inside the component, a team using Retto inherits it without knowing about accessibility. If it stays on a checklist afterwards, it depends on someone remembering, and sooner or later nobody does. It is probably the system's biggest multiplier: one decision, made once, applied across every product that consumes it.

Anatomy of one component

The button, documented down to the last pixel.

Every component is documented with its anatomy, its states, its variants and the usage rules for each hierarchy. The button is the densest example because it is the base piece: eight anatomies, seven states and three hierarchies with criteria for when to use each.

Governance

Governance needs protected time, not just a document.

We studied how other companies solved governance for their systems and proposed our own model: principles, policies, a team model with roles, review flows, standards and adoption metrics, alongside the practices for handing over specifications from design. I compiled and adjusted what the team formulated.

The governance was written down and never got operated.

We had negotiated a weekly slot dedicated to the system, and day-to-day operations ate into it. The departure of one of the developers leading it also left a gap we had not planned for. The principles, the review flows and the standards went on existing in the document, but stopped being followed.

Underneath there was a contradiction I was slow to see. The system was conceived as a living product, updated while in use, and at the same time it was expected to be "finished" before it could be rolled out. Those two ideas do not fit together: as long as a design system is understood as something that gets completed, the weekly slot will always look expendable.

The consequence was concrete: friction appeared in the team over components some considered unoptimized, with no standard in force to appeal to. That was not a people problem. It is what happens when a system has written rules and nobody is assigned to enforce them. Governance is a routine with an owner and protected time.

Behavior

Documenting behavior, not just the end state.

A component is not defined by how it looks at the ideal width, but by what it does when it stops fitting. Every component carries its overflow, reordering and collapse rules documented, with the mobile case explicitly resolved.

Documentation and access

41 components with living documentation.

Each with usage guides, accessibility considerations and responsive behavior documented.

The real documentation sits on a dedicated internal site, with specs, code examples and the component library. Figma serves a different purpose: it is where the design happens, and where the creation, editing and traceability templates that speed up writing specs are kept. It is not a copy of that site, it is the design team's working tool.

Lessons

The most transferable lesson: I learned to negotiate with development using data. "Let us do this because it helps us improve" is not enough; you have to explain the how and, whenever possible, bring the number. Developers' technical limitations are design constraints, and treating them as obstacles instead of inputs is the fastest way to lose an argument you had already won.

Retto is an internal system, so I share documentation and foundations, but not the products where it is implemented. I can walk through the full system and its application in a conversation.