Olist Design System

A new brand needed a system that could keep up

I rebuilt Olist’s Design System foundation to turn a new brand into reusable product decisions. I was responsible for the design work end to end: interpreting the identity, defining the architecture, and resolving the details of the component library.

The existing system dated back to 2020. It still supported real interfaces, but its structure had fallen behind the possibilities of Figma, the team’s technical needs, and the practices emerging across design and development. At the same time, Olist had completed a rebrand with a broader palette, a more expressive identity, and a toggle element within the brand itself.

I made the design decisions and built the library independently. The team of 12 designers adopted it in their workflow. Around 40 components were ready in Figma; integration into products was still being tested, including AI support for component code, audits, and screen generation. Design adoption and production implementation were different stages of the work.

The library worked. Its structure had stopped evolving

The difficulty was visible in everyday maintenance. Base components carried dependencies that were difficult to follow, older variants had broken relationships, and the library did not use variables. Connections between design decisions and their implementation in code depended on manual work. A change could therefore require several separate adjustments before its consequences became clear.

From component decisions to a connected architecture

A token gives a design decision a name and a value; an alias connects it to another token. My architectural question was how to share those decisions without forcing every component to be identical. I organized the answer into three layers: Base, Theme, and Component.

The layered approach draws on established Design System practices. My contribution was in the way I applied it to Olist’s needs, especially the relationship between detailed component control and shared global rules.

Base tokens: the values before the context

Base held the raw vocabulary: exact colors, sizes, spacing, and typography values. Before a blue could become a button background, or 48 pixels could become an interaction height, those values needed a stable name. Follow them through the four examples below.

Theme tokens: shared intentions across light and dark

Theme gave those values a purpose. The same role could reference different Base tokens in light and dark modes, while dimensions could remain consistent. This layer also organized typography, borders, radii, shadows, and interaction states into shared decisions.

A shared role makes a decision reusable; it does not guarantee contrast. Content and surface still needed evaluation together in their final context, using WCAG as a reference.

The conditions for identifying controls and states are explained in WCAG’s non-text contrast guidance.

Component tokens: precision without isolated values

Component tokens gave each property an address: a button’s height, padding, radius, background, label, and icon colors, across hierarchies and states. Some referenced Theme directly; others used Globals inside the Component collection. The button below brings both paths together.

This extra layer let me adjust a component’s specification without redefining the entire theme. A local change could remain local, while shared decisions still had a traceable path through the library.

Globals: shared decisions, control within each component

Globals prevented equivalent controls from drifting apart. Inside 03. component tokens, this group held 16 shared variables: three sizes, four radii, and nine typography references. It was part of Component, not a fourth architectural layer. Here is the shared reference behind the button’s height.

Sharing a height did not mean sharing every property. Both button and input referenced globals/size/interaction, while their radius tokens selected different Globals. The interactive example below makes that scope visible: changing the shared height reaches both controls; changing the interaction radius preserves the button’s pill shape.

If the interaction height needed to move from 48 to 56 pixels, the properties linked to that reference could follow the change. A revision to the interaction radius from 12 to 16 pixels would reach the connected fields while preserving the button’s pill shape. The demonstration simulates these adjustments to explain the mechanism. Compositions and affected uses would still need review. The value was knowing where a change began, which components followed it, and which properties followed other decisions.

Before building components, I studied the brand

I began with the complete brand manual. I studied how the logo occupied a composition, how the colors appeared together, which meanings were attached to them, and how the iconography expressed the identity. The manual became material for decisions that would eventually appear in a field, a button, or a dense product screen.

Brand materials and product interfaces have different demands. A color that creates impact in a campaign may need a quieter role in a table; a distinctive letterform may work better in a heading than in a long description. My work was to preserve the character of the identity while giving it repeatable rules for interaction, reading, hierarchy, and feedback.

This translation established the point of view for the project. The brand supplied the vocabulary; the Design System needed to explain how that vocabulary behaved when information became dense, actions competed for attention, or several components appeared together. Studying the source material first helped me make those decisions with a consistent intention, from the smallest control to the overall atmosphere of a screen.

Brand → interface

A recognizable gesture. A broader language.

Olist identity

The mark in detail

01

02

03

Simplified logo

A simpler dot preserves the identity when the logo is reproduced at a smaller size.

Seven color families, each with a responsibility

The first foundation was color. Rather than distribute every brand color equally throughout the interface, I assigned responsibilities. Blue became the main interaction color. Beige offered the starting point for warm neutrals. Green, yellow, and red had clear potential for success, warning, and error. Cyan and pink became supporting colors for informational contexts, detail, and other secondary expressions.

A palette needed more than seven beautiful colors

Each family received 12 levels, numbered from 0 to 950. That produced 84 foundational color values. The purpose was to provide enough range for different relationships: text over surfaces, borders beside backgrounds, subtle feedback, prominent actions, and the demands of light and dark themes.

I developed the scales by adjusting lightness and saturation along a curve around the source color. Lighter and darker values needed to remain part of the same family while serving different interface roles. This required looking at the progression as a whole, because equal numerical changes do not automatically create equally useful visual steps.

The scale itself was a set of possibilities. A very light value might support a subtle background, while a darker value from the same family could carry text or an icon within it. Their suitability depended on the actual pairing. The numbering helped organize that range, but the role assigned by the theme would determine how a value should enter the interface.

Curve-based color-scale generation is also explored in Lyft’s coloralgorithm.

Warm neutrals connected everyday screens to the brand

The neutral palette would occupy large areas, containers, borders, and the spaces between information. Starting from beige gave those surfaces a connection to Olist’s identity even where the main blue was absent. This was a visual-language choice: legibility still depended on the actual pairing of content and surface.

One typeface, different levels of expression

Olist’s brand had selected Plus Jakarta Sans. Its range allowed me to organize the interface around a single typographic family while preserving different degrees of expression. The Lingkar stylistic alternates carried the more distinctive voice into titles and prominent headings; the regular character forms supported paragraphs, descriptions, captions, and everyday product content.

I treated that distinction as a hierarchy. Headings needed to introduce and organize; body text needed to sustain reading; descriptions and captions needed to remain useful at supporting levels. Sizes, weights, and line heights therefore became part of the system’s specifications, allowing the expressive choices of the brand to coexist with the practical rhythm of software.

The typeface and its stylistic character come from Tokotype’s Plus Jakarta project.

The icon library also needed to become a product asset

Olist already had its own icon set. I brought those assets into Figma as SVGs, organized their outline and filled variations, and built the library so designers and developers could find and use the same visual vocabulary. Icon sizes were defined in relation to the components that needed them.

This completed an important part of the foundation. Color, typography, and icons could now work together through reusable decisions. An icon in a button, a field, or a feedback message would be part of the same system, with its dimensions and visual treatment connected to the surrounding component rather than decided again in every screen.

The button was the first test of the foundation

I started the component work with the button. It concentrated many of the decisions the rest of the library would need: hierarchy, state, typography, spacing, shape, iconography, and color. I preserved the need for three familiar levels of emphasis while rebuilding their specifications on the new foundation.

These hierarchies needed their own states without becoming unrelated components. The button became a concrete way to test whether the foundation could express differences in emphasis while maintaining a shared rhythm.

Enabled, hover, pressed, and disabled states extended each hierarchy into a small system of relationships. A change in background could also require an appropriate label, icon, or boundary color. Defining those parts together helped make the state a coherent response, while the component’s dimensions and internal spacing kept the button recognizable through the interaction.

The icon’s position carried meaning

The button family also distinguished the role of its icon. A leading icon, positioned on the left, introduced a subject or context. An action icon, positioned on the right, related more directly to what would happen, such as adding, confirming, or canceling. Buttons without icons remained available for contexts where the label was sufficient.

I also built the icon button: the same essential interaction expressed through an icon alone. It served situations where the surrounding interface already provided context and a full text label was unnecessary inside the control. The visual economy of this option made the meaning of the action, and the way it would be communicated in implementation, especially important.

A library built around recurring product needs

The button was a starting point for a much broader library. Around 40 components were ready in Figma by the close of the work, focused on the recurring needs of Olist’s systems. The scope included interaction controls, identification, forms, navigation, and structural containers, with feedback patterns also progressing through development.

Forms became a family of related experiences

The input family covered text, paragraph, email, search, token, password, select, and file upload. The most recent addition was the date input, connected to the calendar component. These controls shared a recognizable structure while accommodating the different content, actions, and interactions each task required.

Treating inputs as a family helped keep decisions related. A field’s dimensions, supporting typography, boundary, and states could inherit the same foundations, while its internal content and behavior responded to the task. The calendar extended that reasoning beyond the field itself: entering a date also needed a consistent way to navigate and choose it.

The breadth of that family also showed where reuse needed limits. A paragraph field had different spatial demands from a password field; a file upload had a different interaction from a select. The architecture gave these components a common visual basis while leaving room for the differences that made each useful. Consistency depended on sharing the appropriate decisions, with enough specificity to support the task.

Small distinctions made the library more useful

Some components required distinctions that went beyond their basic shape. Badges, for example, served two purposes. The tag variation used more visible color to categorize information. The status variation had a quieter treatment so the icon and label could carry the message. They belonged to the same family, but communicated different kinds of information.

Avatars accommodated images or initials for people and companies. Segmented buttons supported switching between selections; toggles handled binary choices; chips made compact labels selectable. Breadcrumbs, tabs, and pagination organized movement, while cards, drawers, accordions, and modals supported different ways to structure content. Alert bars, toasts, progress bars, and loading indicators formed a feedback workstream that was still in development at the end.

Responsive modes were the next architectural step

The component layer also created a path toward responsive behavior. Its modes could eventually map mobile, system, and desktop contexts to different theme references. A component’s density, spacing, or dimensions could then change through a defined set of relationships instead of requiring disconnected copies.

That capability remained on the roadmap when my work at Olist ended. The delivered architecture provided a place for those decisions, but the responsive modes themselves were not implemented. This distinction matters: preparing a system to evolve is a meaningful outcome, while completing each future behavior remains a separate piece of work.

The roadmap separated essential coverage from expansion

Alongside the Figma library, I had identified 15 roadmap items: new components, improvements to existing ones, more inputs and containers, and card variations. These were opportunities for further development rather than 15 additional finished components. Specialized inputs included quantity, weight, measurements, currency, and language.

The architecture and the roadmap worked together: one established how decisions should connect, while the other made the remaining opportunities visible. My contribution closed with both a usable foundation and a defined direction for further development.

An AI experiment made the need for explicit rules tangible

Alongside the library, I explored an assistant for component creation, review, iteration, and code generation. I taught it the methodology, token relationships, and component rules. The experiment then expanded to screen generation using Olist’s layouts and the existing component vocabulary, as part of the tests for product implementation.

Some generated screens invented components instead of reusing the library. Those deviations showed where instructions needed to be more explicit. AI became another consumer of the system’s reasoning: a visual reference alone was insufficient when the assistant also needed to understand how a component was constructed.

This remained an experiment. I observed a more agile starting point for exploring hypotheses, but did not establish a consolidated productivity measurement. Generated proposals still required human review. The team’s adoption in design did not mean that the AI workflow or the Design System had completed implementation in production.

The same system in light and dark

I brought a selection of the main components together to show the library as a whole. Switching between light and dark preserves each component’s references to the Theme layer, which supplies the colors for the selected mode. Dimensions, structure, and hierarchy remain consistent as surfaces, content, and interactions take on each theme’s visual expression.

Olist / Component library

One library, two themes

The same components. A different set of theme values.

Theme

LightDark

Click to explore both themes in action.

01Navigation

AllActiveArchive

All · 24

02Identity & context

MC

Marina Costa

Store administrator

ConnectedCasa Aurora

03Actions

Add productSave changesLearn more

Primary · Secondary · Tertiary

04Data entry

Product name

CategorySelect a categoryDecorationOrganization

Search products

Password

Text · Select · Search · Password48 px

05Selection

PublishedDraft

FeaturedHome & living

Delivery method

StandardExpress

Email

06Containers

Room for new possibilities

A consistent foundation for every part of the product.

Explore products

07Disclosure

Product information

Description

Organize information in a clear hierarchy and reveal the details when they are needed.

Shipping & delivery

The same visual rules support different contexts throughout the experience.

2 themesOne shared foundation

The result was a foundation with its reasoning intact

By October 2026, the work connected the new brand to a detailed technical foundation. The palette, type hierarchy, icon library, token architecture, and components formed a coherent body of decisions. The AI experiments opened another way to use that foundation, while making the value of explicit rules even more visible.

In a recommendation about my work in Design Systems, Pedro Valentim, Design Lead at Olist, highlighted craft, technical depth, and visual governance. His words offer a perspective on the professional practice behind this case.

I had the opportunity to see his strong Design System knowledge up close. Bigs is a detail-oriented designer, with a focus on craft, interface standardization, and the creation of well-structured components and organisms with a high technical and quality standard. He has extensive expertise in visual governance and adds considerable value to work that requires visual consistency, especially in the multi-product context in which we worked.

Pedro Valentim

Design Lead at Olist

The work connected responsibilities that often become separate workstreams: interpreting the brand, designing the architecture, resolving component details, and investigating implementation. I made the decisions and built the design foundation, which the team of 12 designers incorporated into its workflow. The scope of that contribution is visible in both the library and the relationships that allow it to evolve.