INDUSTRY:
TELECOM
COMPANY:
TIM Brasil
ROLE:
Product Design Specialist/ Manager
YEAR:
2021-2026
TIM DS
highlights.
context.
For years, TIM's interfaces were built by consultancies and agencies, and every project had its own visual language depending on the partner who delivered it. The only reference was the brand guide, which said nothing about digital products.
The result was visible to customers: the app and the website had different buttons and different colors. They didn't look like the same company. Style guides existed, but as Sketch files handed over at the end of each contract, documentation that belonged to the project, not the company. Over 50 color styles and over 30 different CTA styles coexisted across products. Engineers got a link to Figma and nothing else: no tokens, no specs, no shared vocabulary.
This was the surface customers actually touched: a website with 10M+ monthly unique users and an app on its way to 19.6M.
In 2021, I led the strategy to build a Design System ecosystem serving the Meu TIM app and tim.com.br, split between two stacks: a Flutter library for logged-in areas and a Web Components library for the public site and its CMS modules.
The real problem wasn't visual consistency. It was throughput: critical journeys had to be redesigned and shipped while the component library was built from scratch, and design couldn't become engineering's bottleneck. The system existed only in Figma, so it had to be coded and released inside a delivery pipeline that already existed.
Five years later, 90% of screens on both channels ran on the system. Here is how we got there, and where it drifted.
process & decisions.
Two stacks, shared foundations
Having two libraries was a matter of sequencing, not a legacy accident. The portal came first: the public site runs on Acquia CMS, so the library had to be built there with the simplest technology possible, Web Components. A year later we built the app's system in Flutter, chosen because it would also serve a web version of Meu TIM.
The cost is permanent: two libraries mean at least two developers and twice the surface for drift. What binds them isn't a shared codebase. It's tokens, Figma as technical documentation and one documentation site covering both. Where platform constraints allow, they can differ.
The drift we didn't measure until we looked
Component counts tell the story better than any audit. The app's Figma library has 127 components and 86 in Flutter, a healthy gap, since most are design-only patterns and variants.
The web library holds 1,846 against 114.
Years of parallel delivery on the portal had produced two libraries (TIM's and the external development partner's), a duplication nobody had measured. The CMS implementation itself was correct, and the problem went unnoticed for so long because it was structural: delivery speed outpaced governance.
I opened Merge DS to bring both libraries together and get the Figma source back in line with what ships. It was underway in 2026. The number I care about isn't how many components we have. It's how far design and code can drift apart before someone notices.
An external partner, without losing ownership
TIM doesn't hire developers in-house: its IT organization runs on technical leads managing external development factories, a CAPEX vs OPEX decision no design manager can opt out of. The trigger was capacity. The factory building the app couldn't ship 50+ features and a component library at the same time, so I hired a dedicated partner for the Design System and ran both tracks in parallel.
The risk was real: this was the exact pattern design had been created to escape. What made it different was ownership. Documentation lives in Figma, owned by TIM's Design Ops unit, and the DS repository sits inside TIM's environment. When the contract ends, the system stays. The partner provides execution capacity, not the knowledge.
Contribution with a gate
Any designer could propose a component, but nothing went into the system without Design Ops review. The journey designer defended the component in critique. Once approved, Design Ops documented it and opened a user story for the DS developer of that stack, and the journey designer reviewed it again before it shipped in the next release.
From request to production-ready code: one week. Fast enough that squads weren't blocked waiting for the system, and governed enough that the system never grew by accident.
result.
The system
86 components in Flutter (logged-in app) and 114 in Web Components (portal and e-commerce)
107 design tokens: 31 color, 30 typography, 27 iconography, 13 spacing, 6 shape and geometry
Replacing a legacy of 50+ loose colors and more than 30 different CTA styles across products
Accessibility built into the foundations through semantic code: contrast, touch targets and screen reader support are part of each component, not left to each squad.
Adoption
10M+ monthly unique users on tim.com.br run on the Web Components library, including the entry point of the e-commerce funnel
The Flutter library powers Meu TIM, the app that reached a record 19.6M monthly unique users
8 squads building on the system, across the app, the website and e-commerce
18 designers and engineers consuming the libraries
90% of screens built with DS components
Efficiency
30% less development time for new screens, the number that made the dual-track investment defensible
One week from component request to production-ready code
Enabled the new TIM app to ship 50+ features in a single release cycle
Consistency
72 legacy and duplicated components retired from circulation
Design QA runs on every release, averaging 4 inconsistencies caught before launch
Detaching is not treated as a convenience: if a squad needs behavior the system doesn't cover, it goes to design critique or Design Ops instead of breaking the component. We started tracking detach rates monthly, the first step in measuring how often the system actually fails its users.
