Conheça o seu novo amor: Design System — o que é e porque amar trabalhar com um
Esse artigo é para fazer você, designer, se apaixonar por Design System (DS) e também um agradecimento à comunidade que mais adoro, PretUX, por terem me dado a oportunidade de participar do curso Design System Boost, oferecido pelo Pixelcast.
Lendo esse artigo você irá:
- Entender a essência de um Design System;
- Conhecer sua história;
- Sua função principal;
- O que há em um DS;
- Quem é que constrói um;
- E também as dificuldades de se implementar um.
E ao fim, você terá motivos suficientes para desejar implementar ou trabalhar com um na sua empresa, além de conhecer alguns DS famosos para ficar namorando. Prepara o coração, e vamos lá!
Compreendendo um Design System
Dizem que a gente só gosta do que conhece. Então, pra entender o que é um Design System (do inglês Sistema de Design) vamos voltar no tempo, quando você era criança e gostava de brincar de montar castelinho — eu pelo menos adorava. Mas, mesmo se você não gostasse, imaginemos aqui que você e seus amiguinhos querem montar um castelinho bem lindo, com uma torre super alta, pontes e tudo mais. Porém, vocês não têm as peças prontas como um Lego ou Pequeno Arquiteto. Então, vocês resolvem construir as peças, modelando cada uma delas com argila, pintando-as das cores escolhidas, para depois, montarem o castelo como vocês querem. Contudo, por não ter um molde, cada peça sai de um formato próprio ou de um tom de cor diferente e, no fim, ou o castelo sai tipo um Frankenstein ou vocês simplesmente desistem de fazer porque vai dar muito trabalho.
Bem, é exatamente isso que acontece quando as equipes de uma empresa constroem produtos digitais sem terem como base um Design System (DS). Cada design vai criando um botão aqui, mudando uma letra acolá, e aí, depois, vêm os desenvolvedores e mudam os espaçamentos e o tamanho das fontes para tornar o código rodável… Essas e outras situações que tornam o processo cada vez menos ágil e gera inúmeras inconsistências e retrabalho.
Contudo, se tanto as crianças quanto as equipes de desenvolvimento de produtos tiverem em mãos as peças já prontinhas e pintadas, com um manual de instrução dizendo como se encaixa, então, construir um castelo ou uma plataforma digital será muito mais fácil, não acha? Pois bem, o DS é justamente esse kit de peças anteriormente fabricadas, pintadas e rotuladas, que irá facilitar a vida de desenvolvedores, designers, coordenadores de projeto e, até mesmo, dos executivos e investidores, pois, os produtos entregues serão mais assertivos e tenderão a satisfazer melhor aos usuários finais.
Conhecendo a história e função de um Design System
Porém, pode-se dizer que o conceito de Design System é uma evolução de diversos conceitos e questionamentos feitos por desenvolvedores e designers nas últimas décadas sobre como ter mais agilidade e consistência na construção de produtos digitais.
Percebeu-se que apenas Guias de Estilo (Style Guide) e os Manuais das Marcas (Brand Book) não eram suficientes para guiar e documentar os processos de um produto digital como um todo, pois não envolviam apenas os designers, mas também os desenvolvedores.
Surgiram, então, diversas metodologias, entre elas, a mais famosa foi o Anatomic Design, encabeçado por Brad Frost em 2013, na qual ele cita o termo “sistema de design”. Porém, foi o surgimento do Material Design, da Google, e do Human Interface Guideline, da Apple, que marcou a popularização dessas guias (guidelines) entre as grandes empresas. Mesmo assim, o conceito de Design System ainda é muito novo e ainda está sendo construído e ampliado de acordo com as constantes mudanças no meio digital.
Contudo, uma coisa já é clara, o DS não se resume a um Style Guide para designers pois deve ser também lido pelos desenvolvedores, ou seja, deve ser uma linguagem comum as essas duas áreas que andam lado a lado. Portanto, pode-se definir que a principal função de um DS é, e deve ser, garantir mais agilidade para a construção e escalabilidade de produtos digitais dentro da empresa, uma vez que já reúne em sua biblioteca as diretrizes gráficas dos componentes e também parte do seu código, permitindo que tanto designers quanto os desenvolvedores estejam alinhados.
Ou seja, garante-se que o produto seja entregue mais assertivamente e com mais consistência, sem erros grotescos e variações básicas de design. Lembrando que agilidade não é necessariamente rapidez, mas qualidade na entrega dentro de diferentes aspectos como o técnico, o organizacional, o cultural e também o estratégico (business).
Agora que você já sabe de onde veio e para que serve um DS, é preciso entender que o DS não é um projeto, mas sim, um produto que serve a outros produtos, que serão construídos a partir dele. Diferente de um guia de estilo (style guide), o DS não é um produto fechado, que tem data de término e de validade. Ele deve estar sempre sendo revisto e renovado, sempre alinhado com as diretrizes da empresa, o que permite que os produtos criados a partir dele sejam mais adaptáveis e estejam sempre conectados aos processos e resolvendo os gargalos da produção.
Conhecendo o que há em um Design System
Olhando para a estrutura de um DS, tem-se basicamente duas diferentes partes dentro: os design tokens e os componentes. E podemos diferenciá-los por:
Design Tokens:
É a abstração da menor decisão de design possível sobre um elemento, ou seja, aquelas decisões básicas e indivisíveis como o estilo de fonte (font style), as cores (colours), ou se o componente está visível ou invisível (visible/hidden), entre outras ações.
- Eles devem ser representados de uma forma que tanto designer quanto desenvolvedores possam ler, ou seja, não pode ser só traduzido em códigos ou em símbolos, é necessário os dois.
- Devem ser armazenados em uma plataforma multidisciplinar, para que todos tenham acesso.
- Eles são divididos em 3 tipos:
→ Tokens de aparência: Seletores visuais de CSS. Ex: color; alignment; opacity; border; background; margin; padding; font style; etc (os termos estão em inglês porque o idioma padrão de codificação na web é inglês).
→ Tokens de comportamento: Eventps de JS e HTML que realizam alterações nos elementos de acordo com o comportamento do usuário. Ex: on click; on tap; on hover; on pageupp; on load; on focus; etc.
→ Tokens de estado: São todas as variáveis que podem afetar os estado de um elemento após uma ação do usuário. Ex: visible; hidden; pressed; highlighted; class; ID.
Componentes (components):
São os elementos em si. Ou seja, tokens definem a aparência, o comportamento e o estado desses elementos.
- Eles podem ser divididos em 2 tipos:
→ Master: são os componentes-mãe, aquele que foi o primeiro a ser criado e deve ser guardado com carinho, pois, caso haja alguma alteração nele, todas as cópias (instâncias) também serão modificadas.
→ Instâncias: são as cópias do componente master. Elas podem ser copiadas várias vezes e utilizadas em diferentes telas. Porém, se o componente master for modificado, todas serão (e essa é toda magia do DS).
- Os componentes podem ser guardados em 3 diferentes tipos de bibliotecas:
→ Biblioteca matriz (core): onde são guardadas os componentes masters originais. Essa biblioteca será a matriz de todas as outras.
→ Biblioteca do time (team): cada time deve ter a sua própria biblioteca de instâncias, que serão usadas para os desenvolvimentos das plataformas em que estão responsáveis.
→ Biblioteca não pertencente ao DS (not in DS): são os componentes que não fazem parte do Design System em si. Normalmente, são aqueles que eram usados antes ou que foram criados em situações de exceção.
- Os componentes devem também ser bem rotulados para todos possam entender suas características sem problemas. Normalmente, é usada a seguinte rotulação (mas não é regra, só uma sugestão):
Objeto → Contexto → Tipo → Hierarquia → Modificador → Tamanho → Estado
Ex: Button — light — navigation — primary — normal — large — hover
Desse modo, para designers e desenvolvedores, o DS será a sua fonte para a construção dos produtos. Enquanto os usuários finais serão beneficiados pela maior qualidade e agilidade em que esses produtos vão ser construídos. Assim, os investidores e planejadores da empresa também serão positivamente impactados, já que acontecerá uma redução de erros no processo de entrega do produto paralelo ao crescimento da satisfação dos usuários finais. Ou seja, todos envolvidos no processos (stakeholders) terão motivos de amar um bom DS.
Conhecendo as dificuldades de implementar um Design System
Porém, esses ganhos que o DS traz à empresa como todo são de médio-longo prazo, mesmo que sejam medidos desde o começo do processo. Portanto, é necessário um investimento alto inicialmente para que o DS seja construído.
O ideal seria que fosse a primeira coisa a ser pensada em uma empresa que tem como objetivo escalar os seus produtos digitais. Todavia, a gente sabe que a realidade não é bem assim, pois, muitas empresas que já estão consolidadas no mercado digital só implementaram um DS posteriormente, o que torna esse processo de adaptação um tanto caótico.
Outras vezes, as empresas nem trabalham com um, pois os seus executivos ainda não conseguem enxergar os benefícios de investir na sua construção. Nesses últimos casos, o DS tende a ser pensado só depois de reivindicações dos colaboradores e por proatividade deles mesmo.
Em conclusão, o que se nota é que, apesar dos benefício de ter um Design System, nem sempre é fácil ou viável se implementar um dentro da empresa. Mesmo assim, muitas das grandes corporativas e das pequenas startups já estão estudando e se apaixonando pela ideia de um ter um DS.
Conhecendo os criadores de um Design System
Mas vamos supor que sua empresa vai implementar um DS, então, quem faria um? A resposta ideal é que seja delegado um time específico para a construção do DS, com profissionais experientes em suas áreas e dispostos a ouvirem todos os stakeholders envolvidos. Essa escuta é fundamental, já que todos esses agentes serão impactados de alguma forma pelo DS. Ou seja, deve-se desenvolver o DS como qualquer outro produto, usando as metodologias, pesquisas necessárias e um time multidisciplinar com profissionais com grande experiência para encarar o desafio de criar esse o produto que irá servir outros produtos. Contudo, vale lembrar que, no fim das contas, toda a empresa deve se sentir protagonista da criação de um DS, para que ele possa servir da melhor forma a todos.
Motivos para amar
Se você chegou até aqui e ainda não está desejando trabalhar com um DS, vou listar os principais motivos para se amar ou se investir em um:
· Os designers e desenvolvedores vão ter uma biblioteca de componentes para usar, evitando conflitos entre os protótipos e o código, ou seja, melhora a comunicação entre os dois mundos;
· Nenhum designer vai chorar porque o outro colocou um botão (ou qualquer componente) diferente do que era para ser.
· Ninguém entrará em desespero profundo quando um erro for feito, porque o erro pode ser corrigido em uma instância, sem alterar os componentes master.
· As equipes abraçarão melhor as mudanças, já que só é necessário mudar a biblioteca core para modificar todos as instâncias;
· Os produtos digitais podem ser facilmente escaláveis com mais agilidade e diretrizes claras.
· Em resumo, as equipes serão mais eficientes e felizes na entrega dos seus produtos, ou seja, entregarão produtos melhores com menos erros;
· Equipes felizes e projeto lindos, também deixam os usuários e os executivos felizes.
Alguns bons exemplos
Para finalizar, aqui vão alguns bons exemplos de DS famosos para você ir namorando:
· Material Design — da Google
· Human Interface Guidelines — Design — Apple Developer
· Design Guidelines — Lightning Design System
· Copan — Loft Design System
Conclusão
Se depois de toda nossa conversa você não lembrar de nada sobre o que leu, leve consigo pelo menos essas palavras de Nathan Curtis, da Eightshapes:
Design System não é um projeto, é um produto servindo outros produtos. Ele precisa de um MVP, um roadmap, atualizações e melhorias. Se possível, até um time focado nele.
E se você estiver, ou não, querendo um DS para ontem, deixa sua opinião nos comentários e me conta o que você achou.
Referências
· O que é, e porque criar um Design System? | by Guilherme Gonzalez | //ux.blog (uxdesign.blog.br)
