DANE TELECOM

I arrived expecting mature governance. What I found was a component library with significant gaps, no documentation, and no process for deciding what belonged in the system versus what stayed local to a feature.

The assumption cost a week. From that point I ran a full audit mapping every component, every token reference, every deviation before proposing anything. The audit was the most important output of the first three weeks.

Before fixing what exists, I needed to know what the product would require in the next quarter. A component that works for current features may not work for what is coming.

That conversation gave the project its direction. The gaps between current system state and near-future product needs became the prioritisation framework. Components that would be stressed by the roadmap got restructured first. Components that were stable got documented and left alone.

The inventory covered every component in the library: name, usage count across product files, token references, documentation status, and whether it appeared on the Q4 roadmap. 47 components total. 18 had no documentation. 11 had local overrides in more than three feature files, which meant they had effectively forked. 6 components on the roadmap were not in the library at all.

The overrides were the most useful finding. When a component gets overridden locally three times, it is not a usage problem. It is a gap in the system. The component does not cover the cases the product actually needs. Identifying those gaps before the roadmap accelerated meant the restructure could address them before they became inconsistencies in production.

Scale mattered here. The client shipped products used by millions of end users across multiple countries. A token change that breaks a text contrast ratio does not affect a prototype, it affects a production interface at that scale. The governance model existed precisely to catch that class of error before it reached production.

I split the work into four batches tied to roadmap milestones: foundation tokens, navigation and layout components, form components, data display. Each batch had an owner from the client team and a review gate before anything merged to master.

The review gate was simple: does this change break any existing handoff? We checked against the three most recent feature files before every promotion. It added half a day per batch. It caught four breaking changes that would have required engineering rework. The client team adopted the review process independently for subsequent work after the engagement ended. That is the measure of whether a governance model actually worked.

The restructure introduced three token tiers: primitive tokens (raw values: color, spacing, radius, type scale), semantic tokens (purpose-mapped aliases: surface, text, border, action), and component tokens (component-scoped overrides). This separation meant that a brand color change touched one primitive, propagated through semantic aliases, and updated every component automatically. Before the restructure, the same change required hunting through local overrides across dozens of components.

The governance model was equally important. I introduced a sandbox-to-master workflow: new components and token changes were built in isolation in a sandbox file, validated against active handoffs, reviewed by the UX lead, and only promoted to the master library once confirmed safe. Engineering was not involved in the promotion decision. Component governance stayed a design call. That boundary mattered. It kept the process fast.

I coordinated with other designers to split the work into batches, each assigned and tracked against the roadmap milestones. The on-site presence made that coordination possible. Remote collaboration on a restructure of this complexity, across a team that was also shipping features, would not have worked.

Accessibility was part of the token audit from the start. Every color token was checked against WCAG 2.1 AA at both the primitive and semantic layer. Four existing tokens failed the 4.5:1 contrast requirement for text. Replacing them at the primitive level fixed every downstream component automatically. That is the point of a token architecture, one fix propagates everywhere. Without it, you are hunting for contrast failures component by component in perpetuity.

The system was desktop-only. The client's products ran in browser on fixed workstations, no responsive breakpoints, no mobile variants. That constraint simplified the token architecture considerably. Spacing scales, grid systems, and touch targets were irrelevant. What mattered was density, readability at screen distance, and consistency across a component library used by multiple product teams simultaneously.

Map the system state and the roadmap on day one, before any other work.