Click image to zoom 1:1 · Esc to close
The official design system for the Government of Piauí's digital services, built at ETIPI — the first design system of a Brazilian state government. A shared foundation of design tokens, components, accessibility standards, writing guidelines and documentation that product teams could actually adopt and scale.
The challenge wasn't a missing component library. Different government products had evolved with their own interface decisions — colors, typography, components and interaction patterns varied from one experience to the next. Every new product recreated the same decisions from scratch, and accessibility depended on individual implementations instead of a shared foundation.
Instead of standardizing screens, we needed to standardize the logic behind them — so that a decision made once at the foundation level would propagate to every interface built on top of it.
I was one of the designers on ETIPI's design-system team. Together we shaped the architecture, the token model and naming conventions, the foundations, the component library and its documentation, and the governance that let other teams consume it. Coming from a front-end background, I pushed for every piece to be designed as something engineers would implement and maintain — not as Figma objects.
A design system is not a collection of components. It is infrastructure for making product decisions consistently, at scale — and the first one a Brazilian state government ever had.
The decisions that shaped Opala were made before any component was drawn. Four of them defined how the whole system would scale.
Every design decision — color, type, space, elevation, motion — is stored as a token. Components reference tokens, never raw values, so a change at the foundation flows everywhere.
We defined a formal grammar for names — system / category / property / modifiers — informed by EightShapes' token-taxonomy work, so designers and engineers read the same name the same way.
Light and dark are a token modifier, not a second palette. Semantic colors resolve per mode, which kept the system to one model instead of two.
A meta-template — header, variants, properties table, changelog — so every page of the system is written the same way and versioned the same way.
Reading a token should tell you where it is used and what it does. Every name follows the same seven-part grammar, so a designer and an engineer read it the same way — and a new team member can guess a token they've never seen.
What the token is: the category it belongs to, the property it changes and the concept it expresses.
How it varies: the variant, the interaction state, its position on a scale and the mode it resolves in.
Where it lives: the group, the component and the element inside that component it is bound to.
Six documented foundations — tokens, color, typography, layout & spacing, naming and writing — each versioned with its own history. Below, the three visual ones: dense by design, because a system has to answer every question a product team will ask.
Base palette → scheme colors (foreground, background) → pattern colors for surfaces and content, each resolved for light and dark mode. Contrast ratios are built into the tokens, not checked afterwards.
A size scale with semantic roles — headline, title, body, label — plus line-height, letter-spacing, weight and transformation rules, so hierarchy is a named decision rather than a per-screen choice.
Global dimensions on a 4px base, inset and gap tokens, semantic spacing shown on real government screens, responsive breakpoints from extra-small to extra-extra-large, and the grid.
Thirty-plus components — buttons, inputs, selects, checkboxes, radios, switches, chips, badges, tabs, steppers, breadcrumbs, pagination, tooltips, alerts, dialogs, drawers, accordions, cards, carousels, tables, dropdowns and more — each with its own documentation page written from the same template.
A reusable component has to account for more than its default appearance. For each one we defined the anatomy, the hierarchy of its elements, the variants that belong inside it and the interaction states it must carry — so accessibility and behavior live in the component itself rather than being added during implementation.
Every documentation page links to the component's spec, lays out its elements and slots, and points to its associated templates — the same three-part structure across the whole library.
The documentation template every component follows, and the five interaction states each one must carry — colored with Opala's own tokens.
An icon set is only useful if people can find the icon they need. Opala's library is organized into more than fifty semantic categories — from navigation and files to transport, health and public services — each documented and versioned like any other part of the system.
The catalogue is organized by what people are looking for, not by shape: one documented panel per category, each with its own history.
Public services speak to everyone. Opala includes a UX-writing guide — tone and voice, inclusive language, layout, content and a review checklist — so the words in an interface are as consistent and accessible as its components.
Labels on buttons and menus must be objective. Avoid generic words.
Lead with the objective and the result of the interaction.
Spell it out the first time. Up to three letters, all caps; four or more, only the first.
One institutional voice across every product: speak to one person, prefer the active voice, keep sentences short enough to be read on a phone in a hurry.
Gender-neutral constructions, respectful terms for disability, no jargon — grounded in the state's own inclusive-communication guidance.
Every guideline is paired with a recommended and a not-recommended example, so teams can apply it without interpreting it.
A system other teams depend on needs rules for how it changes. Opala ships with a status vocabulary, a changelog on every page, and a meta-template that makes the documentation itself consistent — a system for documenting the system.
Every page and component carries one of eight states, visible from the Figma page list.
The entry page: navigation to every part of the system, plus the global changelog.
Each foundation and component page keeps its own history — version, date, description — so a team can see what moved and when, without asking.
A page template, header, dividers, variant blocks and history tables are themselves components. Writing a new page means filling a structure, not inventing one.
Government software is not one product. Opala serves citizen-facing services — where clarity and digital literacy matter most — and dense internal systems full of tables, statuses and permissions. Accessibility was treated as a system constraint, aligned with WCAG 2.2 AA, so each requirement became a reusable decision instead of something every team reinterpreted.
Minimum ratios built into the color tokens from the start — in both modes.
A consistent, visible focus state defined inside each component.
Error and disabled states with clear cues that never rely on color alone.
Type and spacing scales that keep structure legible on any device.
Services people use once or rarely, on any device or connection — so patterns favor legibility, guidance and accessible defaults.
Operational tools heavy with data, states and permissions — so components hold up under real, unpredictable content.
Opala shifted recurring interface decisions away from individual screens and toward a shared product language — the foundation the Government of Piauí's digital ecosystem now builds on.
A shared base to design from, instead of solving the same interface problems again on every product.
A coherent, consistent experience across different government services — without forcing them into one solution.
Interaction and accessibility standards addressed once, at the system level, not per implementation.
The hardest part of a system isn't drawing it. It's deciding where consistency ends and flexibility begins — and writing that decision down.
Teams needed patterns they could trust, and room for products that solve very different problems. Settling when to extend a component versus add one was the most important design decision in the project.
The token taxonomy did more for adoption than any component did. A name that reads the same to a designer and an engineer removes a whole category of handoff conversations.
Status, changelogs and a documentation template aren't overhead — they're what turns a Figma file into infrastructure other people can rely on.
The strongest systems don't eliminate design decisions — they eliminate the need to keep making the same ones.