Design Systems: organização e escalabilidade para design e desenvolvimento
Se você está, pelo menos um pouco, envolvido nas culturas de startups, produtos digitais, ou design nos últimos anos, com certeza o termo Design System não lhe passou despercebido. Não só o assunto tem sido muito falado pelas redes sociais, como também mais e mais empresas têm adotado ou aspirado adotar um.
No meio do hype atual, minha impressão é de que o nosso mercado ainda pouco entende o que é um Design System e porque ele é relevante. Poucos sabem sequer por onde começar. E eu não falo apenas de CEOs, Product Owners ou desenvolvedores. Mesmo entre designers, o meio ao qual você diria que o assunto pertence, ainda há uma grande margem para interpretação sobre o que define um Design System.
Para poder aprofundar o assunto aqui, é importante estarmos todos na mesma página. Começarei com as bases: um pouco da história de como chegamos ao termo usado hoje, e quais são os principais pilares que fazem de um design system… um Design System.
1: De onde surgiram Design Systems
2: Pilares de um Design System
De onde surgiram Design Systems
É perfeitamente compreensível que ainda haja muita divergência na hora de definir um Design System. O termo em si é relativamente novo, pelo menos usado da forma que está sendo usado agora. Se você procurar na Wikipédia em inglês, não vai encontrar uma página sobre o assunto. E até mesmo uma busca no Google vai trazer alguns conceitos conflitantes, como “Systems Design”, um assunto completamente diferente.
A verdade é que o conceito ainda está amadurecendo, mesmo que a ideia em si já tenha mais de cinco décadas. Ela nasceu separadamente nos meios de tecnologia e de design, e, finalmente, tem convergido quando essas áreas começaram a trabalhar cada vez mais próximas — nessa cultura de produtos e experiências digitais guiados por Design Thinking. Por isso se tornou tão relevante agora.
O Design System que falamos hoje é uma evolução de diversos conceitos que vêm aparecendo nas últimas décadas. Conceitos que surgiram para solucionar problemas de escalabilidade e consistência, tanto em código quanto em design: Desenvolvedores criaram linguagens voltadas a objetos, componentização de elementos, camadas separadas de códigos, frameworks, entre diversas outras soluções, todas com o intuito de escrever mais código, mais rápido e mais consistentemente.
Entre designers, também há décadas já percebemos a vantagem de se reaproveitar elementos criando padrões, especialmente quando o design precisa escalar até um ponto em que fica difícil gerenciar. Grandes empresas buscavam consistência em seus materiais de comunicação adotando Manuais de Identidade Visual — guias de como utilizar os elementos da marca para criar os materiais gráficos da empresa. Esse recurso é usado até hoje nos meios de design e propaganda, e alguns MIVs são verdadeiros ícones da história do design, como as Brand Guidelines da NASA.
Mais recentemente, profissionais de design e desenvolvimento começaram a convergir e trabalhar cada vez mais juntos. E desde o primeiro dia foi uma bateção de cabeça só. Essas pessoas não falavam a mesma língua: suas metodologias de trabalho eram diferentes, suas ferramentas eram diferentes, seus paradigmas e modelos mentais eram diferentes e suas prioridades eram diferentes. Levamos duas décadas para aprender a trabalhar juntos e ainda estamos aprendendo.
Mas foi dessa convergência que nossas soluções de escalabilidade evoluíram. Designers não podiam mais documentar como eles estavam acostumados, voltados para outros designers. Manuais de Marcas não eram mais suficientes. Surgiram conceitos que conversavam melhor entre as áreas: styleguides, stylesheets, pattern libraries, responsive web design, e mais recentemente, o Atomic Design System do Brad Frost, que meio que catalisou o assunto para a relevância que ele tem hoje.
Nos últimos cinco anos, muito se aprendeu, nossas ferramentas evoluíram, e nossas metodologias mudaram. A necessidade de escalar o design de produtos digitais de uma maneira flexível se tornou vital para nossa sanidade, em um mundo onde não conseguimos mais dar conta de todas as possibilidades de interações, devices, tamanhos de telas e até dispositivos de entradas. Gesture Interfaces e Voice Interfaces serão muito relevantes nas próximas duas décadas, e esse tipo de interação requer outro tipo de documentação, que designers no meio web ou gráfico não estão muito familiarizados.
Pilares de um Design System
Mas no que todas as essas ideias e metodologias evoluíram? O que exatamente é um Design System? Vamos tentar entender por partes:
Nate Baldwin, designer na Adobe, define Design Systems como “… a culmination of people, processes, and shared assets that work together in an iterative cycle in order to unify products, negotiate and align cross-team communication, and increase efficiencies in building products from design to implementation”.
Destaquei nessa definição o que eu acredito serem os quatro pilares que são fundamentais para que você possa realmente chamar sua padronização de design de “Sistema”: Uma Biblioteca (shared assets), Pessoas (people), Documentação (process / work together) e um Planejamento (iterative cycle).
Uma biblioteca
Como o próprio Brad Frost diz, a base fundamental de um Design System é um styleguide, uma biblioteca de componentes, estilos, templates, ou como quer que você chame as partes modularizadas de suas interfaces. Aliás, acredito que a maior genialidade de Frost em seu livro foi propor um padrão de nomenclatura com uma relação hierárquica clara e dedutível para as partes dessa modularização. Nós já fazíamos styleguides há anos, mas, agora, a comunidade começava a usar um léxico em comum. Isso nos deu base para evoluirmos a discussão.
Hoje alguns designers e desenvolvedores já questionam o formato atômico de classificação. A linha que separa Moléculas de Organismos é um pouco tênue, e algumas propriedades muito básicas, como Cor, não parecem pertencer ao conjunto dos átomos, especialmente quando comparada a outros átomos, como um botão, que alguns concordam ser composto de peças menores: cor, texto e forma.
Denis Rainmann, freelancer designer focado em Design Systems, propõe que outra nomenclatura e outra organização faria mais sentido: Foundations, Elements, Modules e Prototype. Já Jina Anne, da Design Co., chama as partes fundamentais do Design System de Visual Language, e as composições criadas de Visual Elements, que podem ser componentizados.
Mas na verdade, a nomenclatura e a forma de organização escolhida não precisa estar escrita em pedra. O mais importante é que todos os envolvidos estejam na mesma página. Por que no fim, essa library será usada e gerenciada por…
Pessoas!
Styleguides são, sim, um pilar fundamental de um Design System, mas eles são só um deles. Um Design System é um ecossistema inteiro que precisa ser planejado e gerenciado.
Fica claro que além de uma biblioteca compartilhada de componentes, um Design System precisa ter uma manutenção: Como ele é atualizado? Como sua cultura é difundida? Quem é responsável por ele? Se algo precisa ser adicionado, quem pode fazer isso? Se há uma dúvida, quem pode responder ela?
A resposta para todas essas perguntas é “Pessoas”. Pessoas dedicadas a manter, aprimorar e principalmente evangelizar a cultura do Design System dentro e fora da organização. Nathan Curtis propõe três possíveis modelos de como um time pode ser organizado para gerenciar um Design System:
- Overlord: Uma pessoa centraliza tudo. Ela recebe material de toda a organização e é responsável por difundir para toda a organização.
- Centralized: Um time centralizado coordena tudo e difunde para a organização.
- Federated: Um comitê de membros de diversas áreas direciona as decisões do Design System, delegando poder a grupos menores para mantê-lo e difundi-lo.
Na realidade do nosso mercado existe uma resistência para aceitar que um Design System precisa de pessoas dedicadas, quem dirá um time inteiro delas. A tendência é que o modelo Overlord seja o mais adotado por empresas tentando iniciar uma cultura de Design System. Isso está ok, provavelmente é a maneira menos burocrática de você começar a andar com o processo. Com o tempo, conforme isso se tornar muito trabalho para uma pessoa só, o modelo pode ir se adaptando para um cenário mais ideal.
Não há uma fórmula certa, cada empresa é uma empresa e parte do trabalho que fazemos na Trinca quando nos procuram para criar um Design System é entender a realidade do cliente e ajudar a planejar um curso de ação, para garantir que nosso trabalho inicial não seja simplesmente abandonado depois. Isso requer uma boa dose de imersão, e o envolvimento de pessoas em diversos níveis da hierarquia da organização. As pessoas precisam sentir que elas fazem parte daquele movimento, isso ajuda na adesão ao Design System.
Para dar esse passo inicial, ajudamos o cliente a passar uma fase de planejamento e outra de pesquisa, normalmente antes de começarmos a desenhar qualquer coisa.
O primeiro passo é, exatamente, entender quem se envolverá no processo de criar e, depois, de manter o Design System. O Team Model pode (e deve) mudar várias vezes ao longo do processo, mas é importante que isso seja pelo menos esboçado. Gostamos de envolver pessoas o mais cedo possível no processo de design.
Um segundo passo é entender as necessidades dos futuros usuários do Design System. Não existem pessoas apenas criando e mantendo ele, existem (provavelmente muito mais) pessoas usando ele. Conversar com elas antes e entender suas expectativas, pode trazer diversos insights e poupar trabalho desnecessário. Você precisa documentar componentes Angular se os desenvolvedores só irão usar React? Provavelmente não. Quanto mais alinhados com a realidade da empresa todos estiverem, melhor.
Uma documentação
Muito bem, temos uma biblioteca e temos pessoas. Mas essas pessoas sabem como usar essa biblioteca? Os componentes dela podem ser combinados de infinitas maneiras, se não houver algum tipo de guia que explique como eles devem ser usados nos possíveis contextos. Sem isso, não há como manter padrões.
Um exemplo simples disso na prática é a questão do uso das cores. A maioria dos styleguides irão definir uma paleta de cores, parametrizar na documentação de CSS do projeto e designá-las variáveis para garantir consistência. Perfeito. Por fim, tudo isso será disponibilizado em algum lugar onde todos os envolvidos possam facilmente acessar.
Mas, muito dificilmente todos os desenvolvedores e designers que forem criar algo para aquele produto irão saber quando aquele @azul_cobalto [#0047AB] deve ser usado. Intenção e propósito precisam ser documentados também.
Polaris, o Design System da Shopify, faz um excelente trabalho documentando e explicando com exemplos onde e quando cada cor de sua paleta deve ser usada:
Além disso, um bom Design System facilita ao máximo que os padrões sejam seguidos, tanto por designers, quanto por desenvolvedores. Oferecer recursos de fácil acesso e em contexto pode ajudar muito. Na página de cores do Polaris, estão disponíveis para baixar um kit UI em Sketch para os designers e os arquivos SASS para os desenvolvedores.
A solução é boa, mas requer um certo nível de organização por parte do time de manutenção. Qualquer alteração em um arquivo Sketch precisa ser gerenciada offline ou com uso de ferramentas semelhantes a um git, que não é algo que designers estão acostumados. Tudo tem que ser mantido sempre atualizado no site do Design System. Além disso, se algum designer baixou o arquivo há algum tempo atrás, ele precisa se certificar que o arquivo que ele possui é o mais atual. Esse processo dá alguma margem para erro.
Já existem soluções melhores. Aqui na Trinca, conseguimos implementar um processo com o uso do Figma, uma alternativa ao Sketch. A principal vantagem que o Figma nos trouxe foi o fato dele ser web-based e online. Nossos arquivos de design são os mesmo para todo o time, que pode inclusive trabalhar simultaneamente no mesmo layout, a la Google Docs. Isso deixa muito mais fácil manter uma única fonte de verdade, e acaba com horas e horas de transferências de arquivo, buscas pelos HDs e retrabalho causado pelo uso da versão errada do arquivo.
Adeus layout_home_valendo_FINAL3.sketch. Não vou sentir sua falta.
O Figma ainda oferece uma API que pode ser usada de diversas maneiras, entre elas ajudar a manter uma documentação viva de design ligando diretamente aos arquivos que os designers editam. Combine isso com conceitos como Design Tokens, e as possibilidades são muitas. Na verdade são tantas, que é impossível começar um Design System com tudo que você gostaria que ele tivesse. Por isso o quarto pilar é fundamental:
Planejamento
O último (mas não menos importante) conceito que precisamos ter claro sobre Design Systems é que eles não são projetos. Eles não têm uma definition of done. Eles são produtos. E como todo produto digital, eles estão em constante evolução. Eles precisam ser tratados com um produto e ter todas as características de um: roadmap, releases, iterações, versionamento, etc…
Nesse quesito existem muitas metodologias que podem ser usadas. Conceitos de Agile podem funcionar perfeitamente, cadenciando releases espaçados por sprints de design e desenvolvimento. Ou então, os releases podem ser gerenciados por features, se focando a lançar uma nova feature por vez. Ou talvez o Design System do seu produto precise crescer conforme seu conteúdo cresce, com novos padrões e templates sendo criados conforme a necessidade de criar novas partes do produto.
Um de nossos clientes nos procurou para construirmos um Design System para a versão digital de seus produtos de seguros. Um empresa centenária, atuando em diversas áreas que iria lentamente migrar seus produtos off-line para um ambiente digital. Para atendermos essa necessidade traçamos um plano de como essa migração seria feita, e atrelamos o desenvolvimento do Design System à ela. Em um primeiro momento precisávamos trazer um dos produtos online, então criamos a base da linguagem visual e apenas os elementos e templates que precisávamos para aquele produto funcionar.
Com esse sistema inicial, era possível trazer um segundo produto online, sem precisar de quase nenhum componente novo. Contudo, a partir do momento que tínhamos dois produtos, um agregador era necessário: a segunda release envolvia criar templates para uma loja online que serviria com centralizador para esses produtos.
Por fim, para uma terceira fase precisaríamos de gerenciadores para os clientes e parceiros envolvidos no processo, e seria para esse lado que evoluiríamos o sistema.
A maneira de gerenciar vai variar bastante de empresa para empresa, de produto para produto. Mas o importante é ter um plano, e todos estarem alinhados. Ou todo o esforço empreendido nos outros três pilares será simplesmente desperdiçado, se tornando obsoleto e desatualizado rapidamente.
In a nutshell…
Resumindo, um Design System é muito mais do que ele parece ser à primeira vista. Mas não se sinta mal se o seu não abrange tudo isso. A maioria ainda não faz. Em uma pesquisa recente sobre o estado dos Design Systems em 2018, a equipe do Figma levantou que dois terços das organizações que possuem um ainda não tem uma documentação coerente e nem um time dedicado. Mas 86% delas gostariam de ter.
Sem dúvida, o assunto ainda vai evoluir muito nos próximos cinco anos, mas os Design Systems vieram para ficar. Pelo menos até se inventar algo ainda mais eficiente.
