Open Library: A system with no favorites
The challenge goes beyond just building a library — it's making it adapt to the visual identity of hundreds of different clients.
This case is still in implementation — it doesn't close with a measured result. It shows how I approached the architecture under a real constraint, before any component even existed.
Timeline
Mar/2026 - Present
Role
Product Designer
Company
OpenCON/OpenMEI
Interface
Mobile/Desktop
Cenário
The platform grew without a visual system behind it. Each new screen inherited a bit of the logic from the one before it, but no formal rule guaranteed consistency between them. The result showed up in three places at once: in the monthly volume of usability bugs opened, in the speed of whoever was designing and building new screens, and in the first impression of whoever used the product for the first time.
There was also a layer that made everything harder: the platform and app are white-label. Each client launches with their own color, their own logo. A design system here couldn't just be a style guide — it needed to be a rule that worked across any brand combination, without relying on manual, case-by-case curation.
Responsibilities
The proposal to build the design system was mine, first presented back in 2025. The PM bought into the idea immediately, but the decision was taken to the CEO, who chose to postpone it. The project only got the green light in early 2026 — almost a year after the original proposal.
I was responsible for the complete visual construction of the design system: defining tokens, guidelines, and designing every component and page used across both the platform and the app. The brand guideline already existed before the project; my role was to update it in partnership with the marketing team, driving decisions on color, typography, and other elements, making sure the new system stayed coherent with the already-established brand instead of starting over from scratch. Today I remain responsible for documentation in Figma and for governing the system — two fronts that, given the nature of the project, are still being built alongside the design system itself.
Constraints
The timeline was short for the size of the task: rethinking the entire visual language of a platform already in production, without pausing development of new features along the way. And there was the structural white-label constraint — any decision about color, spacing, or hierarchy needed to survive hundreds of different brand combinations, not just one.
Team
One product manager, one designer (me — who also acted as the PM's business partner throughout the process), one senior frontend dev, one junior frontend dev, one senior backend dev, and two mid-level backend devs.
Problem
Three different symptoms, one root cause
It wasn't one problem, it was three, and they all came from the same place.
Usability bugs: About 80 monthly tickets related to visual and behavioral inconsistency between screens.
Build speed: Every new screen was designed and built almost from scratch, with no reusable components — meaning constant rework for both design and development.
Perceived unprofessionalism: Different buttons for the same action, different hierarchies for the same type of content. It wasn't just an aesthetic issue — the lack of standard unintentionally signaled that the product wasn't mature.
Process
The rule changes, the client's brand doesn't
The question that guided the entire project wasn't "how do we make a pretty design system," it was: how do we create a system that doesn't break, no matter which client is using the platform at any given moment.
Diagnosis
The first working hypothesis was to limit how much each client could customize — "banning" certain colors or logos that strayed too far from the system's standard. When this direction was presented to the implementation, sales, and leadership teams, the response was unanimous: that restriction wasn't negotiable from a business standpoint. The end client needs to see their own brand, no compromises.
The solution
Instead of restricting the client's brand, the solution was to change where the rule lives. I built a 9-color palette in OKLCH color space and defined every token in the system from it — lightness, contrast, and hierarchy calculated mathematically, not chosen visually client by client. This solved the most common real-world problem: when a client's brand color was too light or too dark to maintain readability, the palette's own balance absorbed the correction, with no need for a manual exception for that specific client.
Tokens
The most important decisions in the project came right at the start, and they weren't the flashiest: typographic hierarchy and spacing scale. A system built on a poorly made foundation is doomed from the start — any inconsistency there multiplies across every component built on top of it later. I ran several scale iterations before landing on a ratio that held up both on dense financial-data screens and on the app's simpler ones.
Visual
The second craft decision was defining the overall visual tone of the platform — and here, the target audience mattered more than market trends. Accountants and micro-entrepreneurs under the simplified tax regime don't, on average, have high digital literacy — something we already suspected and later confirmed through user testing. That meant choosing a more conservative visual approach in places like the menu, instead of risking a more modern navigation pattern that would be less familiar to this audience.
That choice created friction with some stakeholders, who saw simplifications like reducing menu items or removing features as a loss rather than a gain — these are well-established product practices, but not necessarily obvious to people outside the field. Most of these decisions ended up approved, but not without debate.
Componentization
Every component needed to solve for all of this at once: light and dark mode based on the tokens, adaptation to any client palette, and reuse across mobile and desktop without losing coherence. This led to several reworks along the way — no component survived its first attempt unscathed. The clearest example was tabs: carrying multiple subpages within the same section, the challenge was making sure navigation between them was obvious without creating confusion about where the user was. Even with some stakeholders questioning the time spent on testing, I ran A/B tests with real clients to compare solution variations. In some cases the performance difference was small; in others, it was large enough to fully discard the losing variation.
Parallel cleanup
With the design system as justification to revisit the entire platform, we took the chance to fix usability issues that didn't directly depend on the visual system but had been piling up for a while:
Menu reduced from more than 30 visible features to fewer than 10.
8 features removed after Mixpanel analysis showed each had less than 1% usage across the entire user base.
General fixes to logic that was generating help-desk tickets.
Fixes to poorly implemented business rules, such as fields that should have been required but weren't.
This was just the first pass. A deeper feature replanning effort is still ongoing, outside the immediate scope of the design system.
Challenge
Selling time to people who wanted speed
The project's biggest friction wasn't technical, it was about priorities. Some stakeholders saw component A/B testing as time taken from the schedule, not as part of the work. Holding that ground — insisting on testing before finalizing a component that would repeat hundreds of times across the platform — meant repeatedly defending the point that a wrong call on a base token or component would cost far more once replicated than it would now, still at the design stage.
The white-label constraint was resolved at the architecture level (the OKLCH palette), but internal adoption of the system is a second battle, still ongoing. With no formal measurement data yet, the role I've taken on is that of "design system advocate" within the team: reinforcing, in day-to-day practice, why using the system — even when designing something one-off feels faster in the short term — is what keeps maintenance viable in the medium term.
Results
What's already fact, and what's still projection
Already happened
Menu reduced from more than 30 features to fewer than 10.
8 features removed with less than 1% usage, identified via Mixpanel.
Fixes to business rules, bugs, and visual improvements.
Projection
Internal estimate is to reduce the roughly 80 monthly usability bugs to a range of 10–15 — a reduction of about 5x.
50% reduction in time to build new screens, thanks to componentization.
Learnings
Still Learning and Improving
Unlike BPO Financeiro and EmitaZap, this case doesn't close with a measured result — it closes with a resolved architecture and adoption still under construction. The most defensible decision in the project wasn't visual, it was structural: instead of restricting the client's brand to protect the system, the system was built to absorb any brand without breaking.
The next two steps are clear and still open: deciding where and how the full documentation will live (Figma alone doesn't scale to the size the system has already reached), and designing a formal governance model — which, in white-label practice, means managing just two system modes (light and dark) instead of hundreds of client-by-client exceptions, but which still has no written rule for who approves what.
Other projects to check out
Tax Service · WhatsApp · 2026
EmitaZap: No screen is the best screen
Anticipating every scenario has never mattered more — after all, the entire experience depends on how each word is written.
Design System · Mobile/Desktop · 2026
Open Library: A system with no favorites
The challenge goes beyond just building a library — it's making it adapt to the visual identity of hundreds of different clients.
