Trabalhar com Design System é muito ingrato — ou não
Como trabalhar com Design System e não perder as estribeiras.

Neste artigo trago algumas experiências minhas estando no mercado de trabalho com foco nessa área que doa altruistamente suporte a todas as áreas.
Observação: Como o foco desse artigo é Design System, usarei a palavra abreviada “DS” para simplificar o texto.
Altruísta é a pessoa que age de forma preocupada com o bem-estar dos outros, sem esperar nada em troca.
Queremos ver as pessoas utilizando nosso DS, se deliciando com os componentes maravilhosos e inteligentes que criamos, que leiam a documentação, que nos procurem na dúvida e na sugestão, que nos envolvam. Somos um suporte para outras pessoas, queremos ajudar!
Mas a realidade é que não somos tão altruístas assim. Digamos que queremos ver resultados e também avançar e escalar cada vez mais nosso sistema, que a empresa veja o valor de um bom DS e do que o time está fazendo:
- Organização
- Documentação
- Gerenciamento de criação e manutenção
- alinhamento de processos
- Gerenciamento de tarefas
- Organização de conceitos e linguagem
- Desenvolvimento e validação, e o principal
- Design.
Acredito que muito dessa minha descrença vem da falta de conhecimento de contratantes do que é design e quais são suas variadas áreas. Quais profissionais uma empresa precisa contratar para o que deseja produzir? Os vários estudos e especificações de design não estão atingindo quem contrata e isso gera uma escassez de organização, tanto para a pessoa designer quanto para a pessoa contratante.
Um artigo publicado no UX Collective destaca que a formação de designers muitas vezes carece de clareza em relação às competências desenvolvidas, o que impacta diretamente na contratação desses profissionais. A ausência de uma definição precisa das habilidades esperadas pode levar a processos seletivos confusos e desalinhados com as reais necessidades do mercado.
Outro ponto relevante é a interdisciplinaridade do design, que pode causar confusão e, consequentemente, falta de demanda em algumas especificidades da área.
Como no caso do DS, isso ocorre porque muitas vezes, os contratantes não têm uma compreensão clara sobre as competências de um DS e o papel do designer dessa área, o que dificulta a definição de perfis adequados durante a contratação.
Portanto, a falta de conhecimento específico sobre as áreas de design por parte dos recrutadores e gestores pode resultar em processos de contratação mal direcionados, afetando tanto as empresas quanto os profissionais da área. Além disso, gera uma necessidade diária de provar seu trabalho, e como venho falar de DS, cria uma necessidade de provar o valor de um DS para a empresa e pessoas envolvidas a todo momento.
Esse designer de DS na realidade está alinhado com outros clientes: as outras pessoas que trabalham na empresa. Já pensou que louco criar um produto para outras pessoas, que vão utilizá-lo para criar outros produtos?
Dá licença?
Se tudo fosse cheiroso e belo, a gente chegaria numa mesa com todos os sócios, designers, pessoas desenvolvedoras e donas de produto, e toda a gama de stakeholders possíveis numa empresa e iria aplicar DS em todo canto. Mas não é bem simples.
Tem um conceito que aprendi assistindo à série da Marie Kondo — A Magia da Organização na Netflix há alguns anos. Em todos os episódios existe alguma situação complicada na vida de alguma pessoa quanto à sua organização, e a Marie Kondo ajuda essas pessoas, mas ela sempre segue um roteiro: ela pede licença pra casa!
Sim, a diva se senta e fecha os olhos, coloca as mãos sobre o colo e pede licença para a casa com uma reverência, porque a casa não tem nada a ver com aquela desorganização que tá acontecendo ali.

Acredito que, para iniciar uma nova jornada, numa empresa, time e DS novos, a gente tem que pedir licença. Aquilo já começou a acontecer ali, ele pode só estar um pouco desorganizado.
Respeitar o DS como um produto que precisa ser lapidado, organizado, que exige manutenção, que precisa de um cuidado exclusivo e dedicado a ele, gera consistência em todos os lados e não só visual, porque a gente olha pra raiz do problema e tentamos ajustar, e é a desorganização que queremos eliminar.
Seria um problema de virginianos ou de compulsivos por organização?
A saga comum de designers de DS
Quando a gente ingressa num novo time de DS numa empresa nova, a gente já começa com a ansiedade fazendo morada, querendo ver o que tem ali no Figma (ou em outra plataforma de criação).
- Abre todos os arquivos do Figma
- Fuça todos os projetos de outros designers
- Começa a anotar o que tá fora do lugar e desajustado
- Lista todos os componentes já criados
- Gera pesquisas de melhorias e novas necessidades
- Gerencia as tarefas que precisam ser atacadas para ajustar o “irreajustável” e vem a pergunta…
Por que não criar um DS novo?
Ah, o ledo engano! Quando cai nessa ideia já se começa a fantasiar uso, novas propostas, novo design, tentamos até fazer a cabeça de outros pra criarmos uma nova marca pra adaptar ao DS que estamos pensando.
Mas não é bem assim que as coisas precisam acontecer tá? Respira fundo. Anota tudo num papel, vai lá, seja feliz. Essas ideias tu pode usar pra criar algo próprio depois. #dicaDePortfolio
Pra não cair no conto do vigário acima de criar um novo DS, vamos pensar no DS atual que estamos trabalhando como um produto.
DS como produto
Costumo fazer isso em todo lugar que trabalho e com a ajuda do Design Thinking consegui chegar a algum lugar.
Pesquisa de componentes
Como um produto que gera outros produtos o ideal é verificar de perto o uso de cada componente, por isso sugiro que faça uma pesquisa que pode até demorar num primeiro instante, mas depois vai ficar fácil de continuar atuando.
Tire print — isso mesmo, facilita na agilidade dessa etapa — de todos os componentes utilizados nos projetos. Separe cada componente por página, cole em cada página todos que encontrar. Assim você tem um estudo de uso recorrente de vários cenários agrupados num único arquivo, o que facilita na identificação de inconsistências entre várias telas.
De ideias para tarefas
Anote tudo que verificar ser necessário e vá direcionando as demandas que forem surgindo conforme a matriz de priorização com quatro quadrantes organizados por custo — exemplo abaixo — facilitando na identificação de tarefas imediatas que precisam de mais urgência para serem resolvidas.

Atomicidade de componentes
Gosto de chamar assim uma tabela gigante que possui todos os componentes necessários para um DS. A medida que for adicionando componentes, selecione quais outros são necessários para construí-los. Isso facilita na priorização de componentes interligados, evitando mexer em algo que vá reverberar em muitos outros componentes.
Importante aqui ter a ideia de Design Atômico: por exemplo, vamos pensar num componente-molécula simples: um botão. Ele precisa de texto, cor, cantos arredondados, espaçamento, etc.
Na tabela de atomicidade são selecionados todos esses átomos, já que ele é feito de tudo isso. Se em algum momento der na telha de alterar o botão, precisamos nos atentar para todos esses outros componentes em questão.

Gerar essa tabela pode facilitar na tomada de decisão para manutenção, criação ou despriorização de componentes, e ajuda a não alterar coisas desnecessárias que poderiam ser evitadas se estivessem mais evidentes — como na tabela.
Pesquisas com usuários de DS
E vamos pra parte mais interessante do DS, o seu uso.
- Como outras pessoas veem seu produto?
- Como outras pessoas o consomem?
- Existe algum gap de informação?
- O que mais elas gostariam e do que elas sentem falta?
- O que poderia melhorar?
Colha informações, metrifique, brinque com os números, suponha cenários e teste. Acho que o que mais gostei de fazer foi de testar, errar, testar de novo… e acertar!
Em vários cenários o que mais prejudicava não era o design em si, mas a comunicação. Mas antes de falar algo, ouça.
- Participe de critiques e testes de usabilidade com outros designers para colher feedbacks e fazer uma validação mais assertiva.
- Deixe a janela de comunicação sempre aberta, as pessoas querem falar com você.
Rode algumas pesquisas qualitativas com pessoas desenvolvedoras, designers, stakeholders e outras pessoas envolvidas. Isso abre espaço para as pessoas verem você com mais respeito dentro da sua área, o que facilita mostrar com mais acuracidade a necessidade de um DS mais robusto e como fazer isso, atendendo às expectativas e necessidades dos seus usuários.
O que colher dessas pesquisas, volta-se para a etapa “Das ideias para tarefas” onde você organiza em tarefas o que precisa ser feito — ou não.
Depois você pode organizar suas ideias e tentar trazer algumas formas de disseminar o conhecimento em DS:
- Criação de workshops ensinando o uso do DS.
- Gravação de onboardings por todo o projeto disponibilizado para novos funcionários que necessitem saber dessa informação.
- Criação de workshops de Figma. No meu caso já ensinei bastante gente a usar o Figma antes mesmo de explicar o uso do DS em si.
- Criação de documentação detalhada com especificações, conceito, como usar e não usar, anatomia, etc.
Por fim, todo esse trajeto se resume em você mostrar o seu serviço e cobrar que os outros usem seu serviço também — ora, por que não? — , porém muitas vezes somos vistos somente como um suporte que não tem autonomia para cobrar o outro.
Seria altruísta mesmo? Ou ditatorial? Policial de Figma?
(Des)usando um DS
Sabe quando aquele designer te manda uma mensagem dizendo que não sabe usar o autolayout do Figma, ou que não consegue trocar um componente por outro e precisou dar “detach component”?
Acho que esse é um dos principais problemas que temos hoje como designers de DS, o desuso, o descaso. É aqui que piadinhas e comentários tristes vão encontrar espaço pra matutar na nossa cabeça.
"Ah dei detach, a Natasha vai me matar!"
"Não usei o componente do DS e fiz um novo, se for passar pelo time de DS vai demorar."
"O time de DS faz publicação no Figma o dia todo, odeio ter que atualizar meus projetos."
“DS não é uma prioridade pra gente agora, precisamos de tela do produto.”
Tudo bem, o DS está aí pra uso de quem pode e quer usar.
Essa ideia de padronização para escalabilidade tem que partir de quem te contratou, pois partindo da raiz as coisas se adequam de forma mais orgânica.
Se não o é, é preciso mais uma vez validar o projeto e defendê-lo para continuar existindo, e é aqui que o designer arca com uma batalha homérica com todo mundo, e onde começa a preferir estar na solitude.
É ingrato porque a partir desse ponto as coisas podem melhorar ou partir dessa para uma pior, e não estamos falando de demissão.
É hora de arregaçar as mangas e ir pra batalha
Na realidade essa batalha vai ser com você mesmo. Para não enlouquecer, desistir ou o pior: criar um novo DS.
Realmente criar um novo DS às vezes não é o melhor cenário a não ser que esse seja o intuito da empresa em ter te contratado.
É aqui que entra a defesa do DS como um produto e onde você precisa mostrar conhecimento no quesito design e organização para tentar emplacar com uma ideia que pode dar muito sucesso: o seu DS.
- Mostre para stakeholders outros casos de sucesso que aplicaram DS em seus processos de design (como Airbnb, Uber, Duolingo, etc).
- Crie ritos para tirar dúvidas para que nenhuma pessoa fique desamparada no uso do seu DS. Participe de critiques, abra agendas no seu calendário para ficar de plantão.
- Comunique toda e qualquer atualização do DS e não deixe ninguém com medo de atualizar a biblioteca importada do Figma.
- Versione seus updates no Figma com Version History.
- Aproveite a ideia de estar num DS e crie novas aplicações utilizando o DS que você está dando manutenção. No meu período no banco Inter incentivei criando aplicações fictícias (Inter Movies, Inter Donation, Inter Music, entre outros) no único intuito de mostrar valor no uso real.
- Dê alguns passos pra trás e olhe para as tarefas reais do seu backlog, não fantasie, olhe o real. Olhar pro real te dá segurança do que está no seu controle e do que não está.
- Consuma artigos, tutoriais, livros de arte e design. O conhecimento nessa área nunca é demais para aperfeiçoar seu processo de trabalho.
Por fim, fica uma mensagem encorajadora para você que como eu está numa luta diária como designer de DS: se manter no mercado ainda com brilho nos olhos, atuando e aprendendo coisas novas para aprimorar e escalar seu trabalho.
O design precisa de um pouco de regras, e a gente está aqui pra fazer essa ponte entre o subjetivo e o tecniquês. Lembre que seu papel é dar suporte, ser ponte e ajudar outras pessoas. O DS mais do que tudo é um auxílio para criação de novas peças, por isso precisa de regras.
Embora todo processo pareça meio subjugado por outros, isso se limita até colocarmos pra nós que é uma escolha estar onde estamos, e que temos liberdade de nos expressarmos da forma que a gente achar melhor. Daí fica a escolha: de atuar de forma mais organizada em outro lugar, ou de bancar essa escolha e tentar fazer mais uma vez algo legal.
Acredito que esse texto não é só para designers de DS, mas para pessoas que trabalham com organização no geral, porque no final de tudo vejo DS como potes de canetas, lápis e pincéis, em como posso categorizar alguns agrupamentos, seja por tamanho, tipos, cor, formatos, etc.
Essa forma de pensar é única, intrínseca e inerente do que você faz como trabalho, e independentemente do Design System que esteja trabalhando, a forma de pensar é a que mais vai validar a forma que você precisa organizar seu trabalho, por isso consumir cada vez mais tipos de conteúdos abrangentes é importante pra continuar expandindo as várias formas de organizar as coisas.
Se mantenha ativo na arte, se inspire, entre em contato com coisas que te deixam feliz só de ver, a arte é subjetiva.
Talvez disso tudo você consiga tirar proveito e fazer o seu trabalho de forma legal pra você! Criando o seu canto, conhecendo a sua forma de pensar, alinhando o seu processo de trabalho. Conheça o que gosta e aplique isso. Estude e se questione o tempo todo.
Fica firme, vai dar tudo certo!
Referências
- Atomic Design Metodology, por Brad Frost.
- Quem somos nós: uma lupa sobre as competências em design, por Igor Casenote.
- Dica de ferramenta do Figma: Version History.
- Foto de Marie Kondo por Revista Haus.
- Cases de design de sucesso: Airbnb, Uber, Duolingo.
- Projetos de adaptação do Orange DS do banco Inter: Inter Movies, Inter Donation, Inter Music.
- Design Thinking, por Wikipedia.