Vamos voltar aos anos 60 quando a evolução tecnológica possibilitou que computadores fossem mais acessíveis e performáticos. Esse “boom 💥” tecnológico, trouxe grandes impactos mercadológicos, mas também revelou um problema substancial das empresas de desenvolvimento: elas não conseguiam acompanhar esse avanço acelerado o que tornava os softwares difíceis de manter e extremamente propensos a erros.

Em busca de uma solução para isso, em 1968, durante a NATO Conference on Software Engineer, Douglas Mcllroy apresentou o desenvolvimento baseado em componentes, que consistia na reutilização de blocos de códigos que, por fim, gerariam escalabilidade e aumentariam consideravelmente o potencial de programação. Esta metodologia é utilizada até hoje e permite entregas rápidas e de qualidade. No entanto, quando se trata da “conversa” entre design e programação, o cenário muda.

Público NATO Conference on Software Engineer realizada em 1968

O grande desafio enfrentado atualmente é fazer com o que o design também seja escalável, consistente e consiga acompanhar a velocidade de desenvolvimento. Você pode até aumentar o número de designers trabalhando no projeto, mas não garantirá ganhos em performance e ainda amplificará problemas de inconsistência e manutenção. Por conta disso, o Design System ganhou destaque na indústria de softwares.

Quando implementado da forma correta, gera ganhos exponenciais em velocidade de desenvolvimento, consistência de UI (User Interface) e experiência do usuário, além de reduzir custos e gaps, entre designers e engenheiros. Mas seus benefícios podem ir além e, apesar do claro objetivo que lhe origem, o Design System nunca foi e nunca deverá ser considerado como um projeto exclusivo de design.

Não é só sobre design

À primeira vista, uma estrutura de DS parece ter um grande foco em bibliotecas de UI. Eu mesma já li e contribuí para a definição de um DS como um sistema fundamentado em decisões de design. No entanto, por trás destas bibliotecas, estão intricadas estratégias, processos, fluxos de trabalho e métricas que podem se tornar contraproducentes se deixadas à decisão exclusiva do designer.

Exemplo de um ecossistema simples de Design System

É essencial reconhecer que um Design System vai além da simples organização e definição de elementos visuais e sua utilização pode não ser limitada à times de produtos. Imagine uma empresa que tenha implementado um Design System para garantir, principalmente, a experiência da marca. O marketing também se faz usuário deste sistema.

Em um processo de coleta de feedbacks para melhorias do Design system, a equipe de marketing apresenta demandas e aplicações particulares, resultando em insights específicos. É crucial também direcionar a atenção para um segundo nível de usuários, cujos feedbacks têm um impacto ainda mais significativo: aqueles que serão diretamente afetados pelas iniciativas de marketing.

Este cenário destaca as múltiplas ramificações e a complexidade processual que um Design System pode assumir, especialmente diante de suas definições estratégicas. A gestão eficiente é viável somente com uma equipe devidamente estruturada, funções claramente definidas e uma boa dose de governança.

E sim, o designer tem um papel fundamental no meio disso tudo…

É sobre o “como?”

Eu costumo dizer que um design system tem mais relação com o “como?” do que com o “o que?”. E este “Como?” é aplicado antes, durante e depois da implementação de um design system, para que, enfim, seus usuários possam se perguntar com “o que” irão trabalhar.

  • Como vamos construir um sistema de design escalável?
  • Como serão as nossas releases?
  • Como devemos priorizar as histórias?
  • Como os testes de UI serão realizados?
  • Como vamos metrificar a adoção do design system?
  • Como vamos distribuir os design systems?
  • Como vamos garantir o entendimento e a adoção do Design System?

Essas poucas perguntas já deixam claro o quão essencial é a presença do “como” no universo do Design System e como, por si só, o designer não seria capaz de sustentar o projeto de maneira isolada.

A jornada na construção de um design system me apresentou uma dura verdade: só é possível ter um DS maduro com um time focado. Isso não significa que você não possa começar com recursos reduzidos e/ou compartilhados, mas é importante já ter a visão e projeção deste crescimento.

Infelizmente, grande parte dos design systems falham devido à empolgação inicial em tê-los, sem a devida consideração dos aspectos cruciais necessários para sua manutenção a longo prazo. Por isso, antes de começar, avalie a viabilidade da empresa.

Em suma, não é simples e nem fácil construir um Design System. Exige infraestrutura, estratégias bem elaboradas, investimento e claro: a concordância de todos os stakeholders. É preciso entender que seus resultados são a longo prazo e que ele nunca vai cobrir 100% dos seus produtos. Por isso a empresa precisa pensar bem antes de tomar a frente de um. Benefícios? Existem milhares. Desafios? Milhões! Mas as vezes, uma biblioteca que já existe no mercado, resolve grande parte dos seus problemas.

Bote na balança! ⚖️