Jéssica Bortolan
30 de julho de 2026
Publicado em 30 de julho de 2026
Tínhamos um Design System. Só que não: Como eu reestruturei um sistema sem design system.
Tínhamos um Design System. Só que não: Como eu reestruturei um sistema sem design system.
Toda empresa que cresce rápido chega, cedo ou tarde, nesse ponto: alguém compra ou monta um Design System, todo mundo comemora, e alguns meses depois ele já não reflete mais o que o produto realmente precisa. Foi exatamente isso que encontrei quando comecei no meu primeiro emprego.
O sistema que existia só no papel
A empresa já tinha um Design System, comprado pronto, com boa intenção por trás. O problema é que ele nunca tinha sido adaptado à realidade dos produtos. Vivia inteiro em um único arquivo, cheio de regras que praticamente ninguém seguia e templates que não faziam sentido pro negócio.
E o efeito colateral disso é sutil, mas caro: mesmo com um Design System "existindo", nada era de fato padronizado. A empresa tinha três produtos mas cada um seguia seu próprio caminho. Não existia uma base de componentes definitiva. Sempre que alguém precisava de algo diferente do que já estava pronto, desconectava o elemento do componente original (o que no Figma chamamos de "detach") e criava algo novo do zero, sem muito entendimento do porquê aquilo deveria, ou não, seguir um padrão.
Na prática, isso significava recomeçar sempre. Cada fluxo novo era desenhado tela por tela, do zero. E o time de desenvolvimento sentia isso ainda mais: cada nova tela ou ideia de fluxo tinha algo fora do padrão, então eles também precisavam codar tudo novamente, sem conseguir reaproveitar nada do que já tinha sido construído antes.
Essa falta de regramento não afetava só o design. Sem regras claras, o time de dev também acabava definindo muita coisa por conta própria, na tentativa de dar conta do que estava fora do padrão. E isso criava lacunas que o time de design, muitas vezes, só descobria bem mais tarde: decisões que já estavam implementadas no código, sem que o design tivesse participado, ou sequer soubesse que existiam.
A empresa já tinha um Design System, comprado pronto, com boa intenção por trás. O problema é que ele nunca tinha sido adaptado à realidade dos produtos. Vivia inteiro em um único arquivo, cheio de regras que praticamente ninguém seguia e templates que não faziam sentido pro negócio.
E o efeito colateral disso é sutil, mas caro: mesmo com um Design System "existindo", nada era de fato padronizado. A empresa tinha três produtos mas cada um seguia seu próprio caminho. Não existia uma base de componentes definitiva. Sempre que alguém precisava de algo diferente do que já estava pronto, desconectava o elemento do componente original (o que no Figma chamamos de "detach") e criava algo novo do zero, sem muito entendimento do porquê aquilo deveria, ou não, seguir um padrão.
Na prática, isso significava recomeçar sempre. Cada fluxo novo era desenhado tela por tela, do zero. E o time de desenvolvimento sentia isso ainda mais: cada nova tela ou ideia de fluxo tinha algo fora do padrão, então eles também precisavam codar tudo novamente, sem conseguir reaproveitar nada do que já tinha sido construído antes.
Essa falta de regramento não afetava só o design. Sem regras claras, o time de dev também acabava definindo muita coisa por conta própria, na tentativa de dar conta do que estava fora do padrão. E isso criava lacunas que o time de design, muitas vezes, só descobria bem mais tarde: decisões que já estavam implementadas no código, sem que o design tivesse participado, ou sequer soubesse que existiam.
Por onde comecei: a base antes da superfície
Design System bom não começa pelos componentes bonitos, começa pela camada que ninguém vê. Por isso, o primeiro passo foi reorganizar a arquitetura do sistema em camadas, separando tudo em arquivos diferentes:
Tokens primitivos: todos os valores brutos que o sistema usaria: cores, espaçamentos, tipografia, tudo isolado, sem nenhum significado atribuído ainda.
Tokens semânticos: A camada que dá sentido aos valores primitivos, definindo a que função ou área cada um pertence (por exemplo, qual azul é "cor de ação primária" e qual é só "azul de fundo").
Essa separação parece um detalhe técnico, mas é o que permite que um Design System escale sem quebrar: quando você muda um valor primitivo, todo o significado semântico que depende dele se atualiza junto, sem precisar caçar e trocar cor por cor, tela por tela.
Com essa base pronta, redesenhei os componentes essenciais e comuns aos três produtos, como alertas, inputs, modais, e outros elementos que só valem a pena existir como sistema se forem, de fato, padronizados. Depois, para cada produto, criei um sistema de componentes próprio para os elementos mais complexos e específicos daquele contexto, porque nem tudo deveria ser genérico, e forçar isso teria criado o mesmo problema de novo, só que disfarçado.
Design System bom não começa pelos componentes bonitos, começa pela camada que ninguém vê. Por isso, o primeiro passo foi reorganizar a arquitetura do sistema em camadas, separando tudo em arquivos diferentes:
Tokens primitivos: todos os valores brutos que o sistema usaria: cores, espaçamentos, tipografia, tudo isolado, sem nenhum significado atribuído ainda.
Tokens semânticos: A camada que dá sentido aos valores primitivos, definindo a que função ou área cada um pertence (por exemplo, qual azul é "cor de ação primária" e qual é só "azul de fundo").
Essa separação parece um detalhe técnico, mas é o que permite que um Design System escale sem quebrar: quando você muda um valor primitivo, todo o significado semântico que depende dele se atualiza junto, sem precisar caçar e trocar cor por cor, tela por tela.
Com essa base pronta, redesenhei os componentes essenciais e comuns aos três produtos, como alertas, inputs, modais, e outros elementos que só valem a pena existir como sistema se forem, de fato, padronizados. Depois, para cada produto, criei um sistema de componentes próprio para os elementos mais complexos e específicos daquele contexto, porque nem tudo deveria ser genérico, e forçar isso teria criado o mesmo problema de novo, só que disfarçado.
Entender o produto foi parte do processo
Uma coisa que não dá pra planejar 100% antes de começar: ao longo da reestruturação, fui entendendo melhor o que realmente era usado no dia a dia, o que estava faltando, e o que precisava existir mas ainda não tinha um lugar certo. Cada decisão, inclusive as que pareciam pequenas, eu documentei, para que o sistema continuasse fazendo sentido mesmo sem mim editando ele diretamente depois.
Uma coisa que não dá pra planejar 100% antes de começar: ao longo da reestruturação, fui entendendo melhor o que realmente era usado no dia a dia, o que estava faltando, e o que precisava existir mas ainda não tinha um lugar certo. Cada decisão, inclusive as que pareciam pequenas, eu documentei, para que o sistema continuasse fazendo sentido mesmo sem mim editando ele diretamente depois.
Uma transição gradual, não uma reconstrução do zero
Não dava para simplesmente apagar tudo e recomeçar, os produtos estavam no ar, sendo usados todos os dias. Então a implementação também precisou ser gradual: fui criando novas versões dos produtos aos poucos, sempre alinhando com o time antes de implementar o novo sistema em cada parte. Essa transição segue até hoje, continuo alimentando esse sistema diariamente e evoluindo os produtos junto com ele, porque um Design System nunca fica "pronto": ele acompanha o produto enquanto o produto existir.
Não dava para simplesmente apagar tudo e recomeçar, os produtos estavam no ar, sendo usados todos os dias. Então a implementação também precisou ser gradual: fui criando novas versões dos produtos aos poucos, sempre alinhando com o time antes de implementar o novo sistema em cada parte. Essa transição segue até hoje, continuo alimentando esse sistema diariamente e evoluindo os produtos junto com ele, porque um Design System nunca fica "pronto": ele acompanha o produto enquanto o produto existir.
O resultado
Com a reestruturação, os três produtos passaram a falar a mesma linguagem visual,
Pela primeira vez, os três produtos deixaram de parecer três empresas diferentes. E o ganho mais concreto veio do lado técnico: o time de desenvolvimento e de design deixaram de recriar telas do zero a cada fluxo novo. Segundo o próprio time, isso reduziu o tempo de entrega de meses para semanas.
Do lado do design, o ganho foi de escalabilidade. Hoje, quando preciso pensar em um novo fluxo ou funcionalidade para um produto, gasto menos tempo desenhando o que já deveria estar pronto — os componentes — e mais tempo pensando no fluxo em si e no resultado que ele precisa entregar.
O tempo de ideação e prototipação também caiu bastante, o que abriu espaço para gastar mais tempo testando o que estamos construindo, em vez de só produzindo tela.
Mais do que um projeto de UI, esse foi um lembrete de que Design System não é um arquivo, é um sistema vivo, que só funciona se continuar sendo usado, questionado e ajustado junto com o produto.
Com a reestruturação, os três produtos passaram a falar a mesma linguagem visual,
Pela primeira vez, os três produtos deixaram de parecer três empresas diferentes. E o ganho mais concreto veio do lado técnico: o time de desenvolvimento e de design deixaram de recriar telas do zero a cada fluxo novo. Segundo o próprio time, isso reduziu o tempo de entrega de meses para semanas.
Do lado do design, o ganho foi de escalabilidade. Hoje, quando preciso pensar em um novo fluxo ou funcionalidade para um produto, gasto menos tempo desenhando o que já deveria estar pronto — os componentes — e mais tempo pensando no fluxo em si e no resultado que ele precisa entregar.
O tempo de ideação e prototipação também caiu bastante, o que abriu espaço para gastar mais tempo testando o que estamos construindo, em vez de só produzindo tela.
Mais do que um projeto de UI, esse foi um lembrete de que Design System não é um arquivo, é um sistema vivo, que só funciona se continuar sendo usado, questionado e ajustado junto com o produto.
A reestruturação do Design System é um projeto real, desenvolvido durante minha atuação profissional como UI/UX Designer.
A reestruturação do Design System é um projeto real, desenvolvido durante minha atuação profissional como UI/UX Designer.
Jéssica Bortolan
30 de julho de 2026
Publicado em 30 de julho de 2026