Olist Design System

Uma nova marca precisava de um sistema à altura

Reconstruí a fundação do Design System da Olist para transformar uma nova marca em decisões reutilizáveis de produto. Fui responsável pelo trabalho de design de ponta a ponta: interpretar a identidade, definir a arquitetura e resolver os detalhes da biblioteca de componentes.

A empresa havia acabado de passar por um rebrand. A marca ganhou mais cores, outra energia e um elemento de toggle que fazia parte da sua expressão visual. A mudança já existia no branding, mas precisava encontrar uma tradução para o trabalho cotidiano de quem desenhava e construía os produtos. Minha contratação como especialista estava diretamente ligada a essa passagem.

Tomei as decisões de design e construí a biblioteca individualmente. O time de 12 designers adotou o sistema no workflow. Cerca de 40 componentes estavam prontos no Figma; a integração aos produtos continuava em testes, incluindo apoio da IA ao código, à auditoria e à geração de telas. Adoção no design e implementação em produção eram etapas distintas desse trabalho.

O legado funcionava. A manutenção já cobrava seu preço

O Design System anterior havia sido construído em 2020 e continuava em uso. Ele sustentava telas e carregava decisões que faziam sentido no momento em que foram tomadas. O problema era que a estrutura não acompanhava mais a evolução do Figma, das práticas de componentização e das possibilidades de aproximação entre design e código.

Havia dependência de componentes de base, as estruturas de “.base”, além de componentes antigos com variações quebradas. As variáveis ainda não faziam parte da arquitetura, e a correspondência com código dependia de trabalho manual. Uma alteração que deveria ser sistêmica frequentemente exigia entender relações dispersas e repetir ajustes. Isso tornava a evolução mais delicada justamente quando a empresa precisava de mais escala.

Dos componentes à arquitetura que sustentava as decisões

Um token dá nome e valor a uma decisão de design; um alias o conecta a outro token. Minha questão de arquitetura era como compartilhar essas decisões sem obrigar todos os componentes a serem iguais. Organizei a resposta em três camadas: Base, Theme e Component.

Adotei uma arquitetura de três camadas, Base, Theme e Component, e a adaptei à realidade da Olist. Ela dialogava com práticas já presentes em outros Design Systems. Minha contribuição estava na organização dos contextos, nas regras de referência e na combinação entre autonomia local e consistência global.

A relação entre valores de referência, decisões de sistema e tokens de componente também aparece na arquitetura documentada pelo Material: Material Web · Material Theming.

Base tokens: o lugar dos valores absolutos

Base reunia o vocabulário concreto: cores exatas, tamanhos, espaçamentos e valores de tipografia. Antes de um azul virar o fundo de um botão, ou de 48 pixels virarem uma altura de interação, esses valores precisavam de um nome estável. Acompanhe os mesmos valores nos quatro exemplos abaixo.

Theme tokens: valores ganhavam intenção e contexto

Theme dava uma função aos valores. A mesma intenção podia referenciar tokens de Base diferentes nos modos light e dark, enquanto dimensões permaneciam consistentes. Essa camada também organizava tipografia, bordas, raios, sombras e estados de interação em decisões compartilhadas.

Uma função compartilhada torna a decisão reutilizável; não garante contraste por si só. Conteúdo e superfície ainda precisavam ser avaliados juntos no contexto final, usando a WCAG como referência.

As condições para identificar controles e estados são detalhadas em WCAG · contraste não textual.

Component tokens: cada decisão tinha um endereço

As tokens de componente davam um endereço a cada propriedade: altura, padding, raio, fundo, texto e ícone do botão, em suas hierarquias e estados. Algumas referenciavam Theme diretamente; outras usavam Globals dentro da coleção Component. O botão abaixo reúne esses dois caminhos.

Essa camada permitia ajustar a especificação de um componente sem redefinir todo o tema. Uma mudança local podia continuar local, enquanto decisões compartilhadas mantinham um caminho rastreável pela biblioteca.

Globals: decisões em comum, controle por componente

Globals evitava que controles com necessidades equivalentes começassem a divergir. Dentro de 03. component tokens, o grupo reunia 16 variáveis compartilhadas: três de tamanho, quatro de raio e nove de tipografia. Era parte de Component, não uma quarta camada. Veja a referência por trás da altura do botão.

Compartilhar a altura não significava compartilhar todas as propriedades. Botão e campo referenciavam globals/size/interaction, mas seus raios selecionavam Globals diferentes. O exemplo interativo abaixo torna esse alcance visível: alterar a altura compartilhada alcança os dois controles; alterar o raio de interação preserva o formato pill do botão.

Se a altura de interação precisasse evoluir de 48 para 56 pixels, as propriedades vinculadas àquela referência poderiam acompanhar a mudança. Já uma revisão do raio de interação de 12 para 16 pixels alcançaria os campos conectados a ele, preservando o pill do botão. O exemplo acima simula esses ajustes para demonstrar o mecanismo. A revisão das composições e dos usos afetados continuaria fazendo parte do trabalho. O ganho era saber onde uma alteração começava, quais componentes a acompanhavam e quais propriedades seguiam outras decisões.

Antes de desenhar componentes, precisei entender a marca

Meu primeiro material de trabalho foi o manual de marca. Estudei o posicionamento do logo nas peças, as relações de cor, a presença dos elementos gráficos e o desenho dos ícones. Queria entender quais características eram estruturais e quais dependiam do contexto de uma comunicação específica.

Uma peça de marca pode concentrar expressão em um único momento. Um produto precisa sustentar essa identidade enquanto a pessoa lê, preenche, compara, seleciona e resolve tarefas durante muito mais tempo. Por isso, cada escolha precisava ganhar uma responsabilidade. O azul precisava ajudar a reconhecer uma ação; as cores de feedback precisavam comunicar situações; a tipografia precisava organizar informação.

Marca → interface

Um gesto reconhecível. Uma linguagem mais ampla.

Identidade Olist

O símbolo em detalhe

01

02

03

Logo simplificado

Um pingo mais simples preserva a identidade quando o logo é reproduzido em tamanhos menores.

Sete famílias de cor, sete pontos de partida

Comecei pelas base tokens de cor. A marca oferecia sete cores, mas uma paleta de interface exigia mais do que reproduzir os valores do manual. Primeiro, defini o papel de cada família. Essa decisão dava direção ao desdobramento dos tons e evitava que uma mesma cor assumisse significados conflitantes de um componente para outro.

Uma cor de marca precisava se transformar em uma escala

Cada uma dessas sete famílias recebeu 12 níveis, organizados de 0 a 950. Ao todo, a fundação passou a ter 84 cores-base. Os números eram identificadores da escala: uma maneira de localizar os tons e referenciá-los nas demais camadas, sem confundir o nome de uma cor com a função que ela desempenharia na interface.

O processo partia da cor original e dos seus valores de saturação e luminosidade. A partir dela, trabalhei curvas de progressão para distribuir tons claros, intermediários e escuros. O objetivo era encontrar valores úteis para superfícies, texto, bordas e estados, preservando uma relação reconhecível entre as cores de uma mesma família.

Esse raciocínio pode ser descrito como geração de escalas cromáticas por curvas de luminosidade e saturação. A qualidade estava no ajuste da progressão e na utilidade dos tons em combinações reais. Um número de escala, sozinho, não garante contraste: a validação continua dependendo do par de cores e do conteúdo que será apresentado.

Uma referência técnica para entender esse princípio é o algoritmo público da Lyft, que alimenta o ColorBox e permite controlar curvas de matiz, saturação e luminosidade: Algoritmo de cores da Lyft.

O bege abriu espaço para neutros com identidade

A paleta neutra ocuparia grandes áreas, containers, bordas e intervalos entre informações. Partir do bege conectava essas superfícies à identidade da Olist, mesmo onde o azul principal não aparecia. Era uma decisão de linguagem visual: a legibilidade continuava dependendo das combinações concretas entre conteúdo e superfície.

Uma família tipográfica, duas maneiras de se expressar

A tipografia já tinha uma direção definida pela marca: Plus Jakarta Sans. Criada pela Tokotype e distribuída também pelo Google Fonts, a família oferecia a combinação de personalidade e versatilidade que o sistema precisava. Meu trabalho era organizar esse repertório em uma hierarquia que funcionasse nas interfaces.

Nos títulos, utilizei as alternativas estilísticas Lingkar, presentes na própria família. Seus desenhos traziam a expressão que aparecia no branding e funcionavam como uma voz de display. Para parágrafos, descrições, captions e textos de interface, a configuração convencional sustentava uma leitura mais contínua.

A distinção permitia construir hierarquia com coerência: títulos carregavam mais personalidade; textos de apoio preservavam clareza em situações com maior densidade de informação. Tamanhos, pesos e alturas de linha passaram a compor o sistema de estilos e tokens, dando uma referência comum para os componentes que viriam depois.

A criadora da família documenta seus conjuntos de alternativas estilísticas, incluindo Lingkar: Plus Jakarta Sans · Tokotype.

A iconografia também precisava virar biblioteca

A Olist já possuía um conjunto próprio de ícones. Levei esses ativos para o Figma em SVG e organizei suas versões outline e filled em uma biblioteca disponível para designers e desenvolvedores. Assim, o desenho da marca podia continuar presente nos detalhes funcionais do produto.

Os ícones também precisavam responder a diferentes tamanhos e contextos de componente. Um ícone em um botão, em uma badge ou em um campo não pode depender de um ajuste improvisado a cada uso. A organização da biblioteca e de suas dimensões preparava essa relação, enquanto as tokens passariam a controlar os valores aplicados em cada contexto.

O botão foi o primeiro teste da fundação

Com cor, tipografia e iconografia organizadas, comecei pelos componentes. O botão foi um ponto de partida útil porque reunia praticamente todas as decisões que precisariam se repetir na biblioteca: hierarquia, dimensões, espaçamento, estados, texto, ícone e contraste.

Mantive três hierarquias que já atendiam às necessidades do sistema anterior. A reconstrução permitia preservar uma lógica conhecida enquanto atualizava a estrutura que a sustentava. O objetivo era tornar clara a importância de cada ação e manter essa leitura nas diferentes situações de uso.

Os estados enabled, hover, pressed e disabled precisavam pertencer à mesma lógica. A partir do botão, passei a verificar como as decisões de interação seriam compartilhadas pelos componentes seguintes, evitando reconstruir a linguagem de estados a cada nova necessidade.

A posição do ícone também carregava uma regra

A presença de um ícone no botão era uma decisão de contexto. Quando o desenho ajudava a identificar o assunto, ele entrava à esquerda como lead icon. Quando reforçava uma ação, como adicionar, cancelar ou confirmar, aparecia à direita como action icon. Também havia a configuração sem ícone, para situações em que o texto resolvia a comunicação.

Essa convenção precisava ser entendida por quem montava as telas. Ao definir a relação entre significado e posição, o sistema oferecia um critério de escolha e tornava a composição menos dependente da preferência de cada pessoa.

O button icon compartilhava a essência do botão, mas exigia cuidado com a clareza do significado. A ausência de texto visível não elimina a necessidade de identificar a ação para quem utiliza a interface, inclusive por tecnologias assistivas.

A biblioteca cresceu a partir das necessidades dos produtos

Depois do botão, a construção avançou para as famílias que apareciam com maior frequência nas telas. A prioridade estava em consolidar uma base utilizável nas rotinas dos sistemas, cobrindo ações, preenchimento, seleção, identificação, navegação e organização de conteúdo.

Ao final do meu ciclo, o Design System contava com uma base de cerca de 40 componentes prontos no Figma. Em paralelo, a frente de feedback continuava em desenvolvimento. Para explicar a amplitude sem transformar o case em um catálogo, vale olhar para as decisões que conectavam essas famílias.

Formulários precisavam de uma linguagem comum

Os inputs formavam uma parte importante dessa base. Texto, parágrafo, e-mail, pesquisa, token e senha compartilhavam uma lógica, mas atendiam a situações diferentes. O desafio era preservar consistência enquanto cada campo oferecia o contexto necessário para a tarefa.

Também desenvolvi o input select para escolhas, o input de arquivo para upload e, mais recentemente, o input de data. Esse último se conectava ao Calendar, outro componente construído no sistema. Essa relação mostrava como a biblioteca começava a sustentar composições entre componentes, com funções complementares.

O valor de tratar formulários como uma família estava na continuidade. A pessoa podia alternar entre tipos de informação sem precisar reaprender a linguagem visual a cada campo. Para quem desenhava as telas, a mesma base de dimensões, tipografia e decisões de interação oferecia um ponto de partida mais previsível.

Pequenos componentes, diferenças importantes de significado

Algumas decisões exigiam separar funções que poderiam parecer visualmente próximas. A badge é um bom exemplo: dentro dela, construí uma variação de tag para categorização e outra de status. As tags eram mais coloridas; os status utilizavam cores mais sutis, com maior protagonismo para o ícone e o texto.

Essa diferença ajudava a distinguir o que classificava uma informação daquilo que comunicava uma condição. O chip, por sua vez, funcionava como uma badge selecionável. Segmented buttons ofereciam seleções dinâmicas, enquanto o toggle resolvia escolhas binárias. Cada componente precisava responder a uma intenção reconhecível, além de compartilhar a fundação visual.

O avatar também atendia a diferentes situações de identificação: imagem ou iniciais, associadas a clientes e empresas dentro dos sistemas. Ao lado dos componentes de navegação e dos containers, essas peças ampliavam a cobertura da biblioteca sem exigir que cada tela inventasse sua própria resposta para necessidades recorrentes.

A responsividade estava prevista na próxima evolução

A camada de Component tokens também preparava um caminho para trabalhar responsividade por modos. A proposta era criar contextos como mobile, sistema e desktop, permitindo que uma mesma propriedade de componente apontasse para referências adequadas a cada situação.

Essa evolução permaneceu no roadmap durante o meu período na Olist. A arquitetura oferecia um ponto de partida para organizar essas decisões, mas os modos responsivos ainda precisariam ser desenvolvidos, testados e mapeados para a implementação. Diferenciar essa intenção do que já estava concluído ajuda a entender o alcance real do trabalho.

O próximo conjunto de necessidades já estava mapeado

Além da biblioteca no Figma, eu havia identificado 15 itens de roadmap: novos componentes, melhorias nos existentes, mais inputs e containers e variações de cards. Eram oportunidades de evolução, e não 15 componentes adicionais concluídos. Entre as especializações estavam inputs de quantidade, peso, medidas, moeda e linguagem.

Esse recorte representa o estágio em que encerrei minha participação, em outubro de 2026. Ele reúne uma fundação construída e um caminho de continuidade. O roadmap ajudava a manter visíveis as próximas necessidades sem diluir a prioridade dos componentes que o produto já demandava.

A experimentação com IA tornou o valor das regras explícito

Em paralelo à biblioteca, explorei um assistente para criar, revisar e iterar componentes e gerar código. Ensinei a metodologia, as relações entre tokens e as regras de construção. A experimentação avançou para a geração de telas com modelos dos sistemas da Olist e o repertório da biblioteca, como parte dos testes para implementar o sistema nos produtos.

Algumas telas geradas inventavam componentes em vez de reutilizar a biblioteca. Esses desvios mostravam onde as instruções precisavam ser mais explícitas. A IA se tornava outra consumidora do raciocínio do sistema: uma referência visual era insuficiente quando o assistente também precisava compreender como o componente deveria ser construído.

Essa frente permaneceu experimental. Observei mais agilidade para iniciar a exploração de hipóteses, mas não estabeleci uma medição consolidada de produtividade. As propostas geradas continuavam dependendo de revisão humana. A adoção no design não significava que o workflow com IA ou o Design System haviam concluído a implementação em produção.

O mesmo sistema em light e dark

Reuni alguns dos principais componentes nesta composição para mostrar a biblioteca em conjunto. Ao alternar entre light e dark, os componentes mantêm suas referências à camada Theme, que entrega as cores do modo escolhido. As dimensões, a estrutura e a hierarquia permanecem, enquanto superfícies, conteúdo e interações assumem a expressão visual de cada tema.

Olist / Biblioteca de componentes

Uma biblioteca, dois temas

Os mesmos componentes. Um novo conjunto de valores de tema.

Tema

LightDark

Clique para explorar os dois temas em ação.

01Navegação

TodosAtivosArquivo

Todos · 24

02Identidade e contexto

MC

Marina Costa

Administradora da loja

ConectadoCasa Aurora

03Ações

Adicionar produtoSalvar alteraçõesSaiba mais

Primary · Secondary · Tertiary

04Entrada de dados

Nome do produto

CategoriaSelecione uma categoriaDecoraçãoOrganização

Buscar produtos

Senha

Text · Select · Search · Password48 px

05Seleção

PublicadoRascunho

DestaqueCasa e decoração

Tipo de entrega

PadrãoExpressa

E-mail

06Containers

Espaço para novas possibilidades

Uma base consistente para cada parte do produto.

Explorar produtos

07Informação progressiva

Informações do produto

Descrição

Organize as informações em uma hierarquia clara e revele os detalhes quando forem necessários.

Envio e entrega

As mesmas regras visuais apoiam diferentes contextos ao longo da experiência.

2 temasUma base compartilhada

Um olhar sobre o trabalho

Em uma recomendação sobre minha atuação em Design Systems, Pedro Valentim, Design Lead na Olist, destacou craft, profundidade técnica e governança visual. Suas palavras oferecem uma perspectiva sobre a prática profissional por trás deste case.

Tive a oportunidade de acompanhar de perto seu forte conhecimento em Design System. Bigs é um designer detalhista, com foco no craft, na padronização de interfaces e criação de componentes e organismos bem estruturados e com alto padrão técnico e de qualidade. Possui um grande gabarito na governança visual e agrega muito valor em frentes que necessitam de consistência visual, ainda mais no contexto multi-product em que trabalhamos.

Pedro Valentim

Design Lead at Olist

O legado: uma estrutura para continuar evoluindo

Meu trabalho na Olist reuniu interpretação de marca, construção de componentes, arquitetura de tokens e investigação de novas formas de produzir design. A nova identidade ganhou responsabilidades dentro da interface; as decisões passaram a ter uma estrutura de referências; e a biblioteca chegou a cerca de 40 componentes prontos no Figma, com novas necessidades já mapeadas.

A principal contribuição foi dar forma às relações entre essas entregas. Uma paleta influenciava o tema, o tema orientava o componente e as referências globais preservavam decisões comuns. A mesma clareza que ajudava a manter a biblioteca também se tornava matéria-prima para ensinar o sistema à IA.

Esse trabalho conectou responsabilidades que muitas vezes ficam em frentes separadas: interpretar a marca, desenhar a arquitetura, resolver detalhes de componentes e investigar a implementação. Tomei as decisões e construí a fundação de design que o time de 12 designers incorporou ao workflow. O alcance dessa contribuição aparece na biblioteca e nas relações que permitem que ela continue evoluindo.