From a discredited library to strategic product infrastructure.

When I joined, the project was nearly dead. There was a Design System, but it was closed, had little room to scale and almost no connection to the business. In practice, it was a library, not a product.

It was 100% designed for the logged-in app: it served what already existed, not what could exist, so there was no room for other products or platforms. About four teams used the old components, and the clearest sign of the problem was the volume of detachments, around 900 a month. A detachment is when a designer breaks a component in Figma, detaching it from the library, to edit it on their own. Every break is a vote of no confidence in the system.

The project also faced internal skepticism. What sustained it was the design team's and the accessibility team's confidence in its potential.

I came to continue the work, but the potential was too big to leave it as it was. I chose to rebuild and change how we approached the project. Three decisions weighed the most:

1. Replace practically the entire development team. Without the right team, no strategy would leave the page.
2. Rebuild every component as a single source of truth. Figma is that source: it doesn't look at app or web separately, both live in the same place, the same way.
3. Treat the Design System as a product, with an owner, a roadmap, strategy and governance, instead of a project with an end date.

For the diagnosis, we combined research, benchmarks and interviews with the designers who used the library.

1. Figma, the source of truth
2. Web and app, at the same time

It took about nine months of design, almost 100% focused on the rebuild. We started from the visual language that already existed and took the chance to refine the aesthetics and bring in market best practices. The official launch was in January 2026, with the 25 most important components, cataloged from the legacy library and the screens of the time.

Today there are about 65 components and about 600 tokens, primitive and semantic, organized with Variables and Style Tokens in Figma. We use atomic design, from atoms to organisms.

One of the changes we feel most is white space: we used to rely on dividers to separate sections, and now we let the space breathe, which helps visually. Almost everything is flexible. I only kept rigid the components that stick on scroll, because they need tighter sizes and spacing to leave content area on small screens.

1. Atoms
2. Molecules
3. Organisms

Pitaya ships in React on web and Flutter on the app, with Storybook, Code Connect and Code Syntax. In practice, the dev copies the link of the Figma frame where the prototype was made, drops it into an AI-powered IDE and gets the screen almost ready in code. We also have a few MCPs that connect design and code, and the system itself serves as the knowledge base for a chatbot. We're shaping ourselves to what teams need, whether product, design or technology.

1. Tokens
2. Components
3. Documentation
4. Engineering

Accessibility went into the foundation, not the end. We work with WCAG 2.2 AA, ABNT standards and assistive technology testing. The team included Alvaro Zermiani, a blind colleague who tested with assistive technology from the design of components and templates through to code, and helped design teams choose the reading order of pages.

Before, testing only happened in code, which was laborious. We put accessibility into the UI kit, with a playground that made those tests much easier. That work took us to TDC, The Developers Conference, in September 2025, where Alvaro and I presented how the Design System and assistive technology should go hand in hand: if the foundation is well solved and people use it, project quality goes up.

Today I audit everything. The contribution model is specific, because the system already covers almost everything people need, so most contributions are evolution, not creation. Documentation lives in a dedicated portal, with releases, guides, news and information about the team and the product.

• ~900 → ~25detachments a month, even as the user base grew from about four to about twenty teams.
• ~40%less time in the front-end development pipeline.
• ~30%more items added to sprints. Both measures are estimates tracked by the company's agile specialists.
• ~18 of ~20products in the unit using the system, with about 70 designers, 500 developers, 800 people in the extended ecosystem and about six brands and platforms served.

More team confidence in deliveries, the product pipeline and screen quality, even as the team grows. The current VP of ECS thanked me directly: he saw the product's potential but didn't know how to steer it, and recognized how the team was led.

I would have thrown out the project's base tokens. Many people were already using them, without components tied to them, and I had neither the time nor the people to change that. It still gives me headaches: the semantics are poor, the color values are poor and the palette is weak, which makes changing anything hard. It's the debt I most want to pay off.