Os pilares estruturais de um Design System
Entendendo como um design system funciona e o que é essencial
Nota do Autor
O que você encontrará nesse artigo é um pequeno resultado de alguns anos de trabalho, testes, estudos e muita paixão sobre o tema. Espero que este conteúdo lhe seja de grande utilidade em sua jornada. Te ajudarei durante o caminho com algumas dicas e complementos (👨🏻💻)
Tenha uma ótima leitura 🙏🏼
Introdução
Quando ouvimos sobre Design Systems, é muito comum resumirmos o tema em um conjunto de bibliotecas com componentes reutilizáveis seguindo uma semântica de uso, e tudo isso de forma unificada e disponível para uso dos times que atuam na construção de produtos. Porem ao longo desses anos trabalhando na criação e estruturação de design systems, sempre me deparei com cenários e complexidades que vão além desse conjunto de bibliotecas e das características técnicas ali atreladas, envolvendo cada vez mais uma visão ampla de ecossistema e entendendo que design systems tem muito mais a ver com Interação entre sistemas do que somente a entrega de elementos reutilizáveis.
Afinal, quais são os pilares de um design system? Para isso precisamos dar um pequeno passo atrás.
👨🏻💻 Para saber mais sobre:
Artigo — Introdução a Design Systems ( Em Breve )
Entendendo qual é o objetivo de um Design System
O objetivo de um design system o próprio nome ja diz, é sistematizar o design de algo, e esse algo podemos considerar como uma empresa, que possui uma marca e oferece produtos a seus consumidores.
A Etimologia da palavra "sistema" do grego SYNISTANAI, a traduz como "fazer funcionar junto" ou "reunião de várias partes diferentes."
Podemos assim entender que sistematizar aplicado ao contexto de design systems, seria de reunir essas "partes" de forma que se interajam entre si cumprindo um papel e gerando benefícios aqueles que o consomem.
Existem inúmeros benefícios de se implementar um design system, porem os principais motivos que fazem uma empresa investir tanto dinheiro em times dedicados a isso são principalmente:
Padronização
Permite que todos os elementos que influenciam na construção dos produtos e na marca, estejam alinhados a mesma visão da organização, permitindo muito mais direcionamento na criação de interfaces e materiais, evitando ruídos no meio do caminho.
Ganho de Eficiência ( Escala )
Permite que os times envolvidos ganhem agilidade e velocidade na construção das interfaces e materiais, escalando a operação e permitindo diversos ganhos tanto para o colaborador quanto para a organização.
Redução de Custo ( ROI )
É com certeza o benefício mais importante para os stakeholders* e o principal motivo de um grande investimento em times dedicados. Um design system tem o poder de reduzir custos operacionais de uma organização, pois acelera o ritmo de construção de novas soluções, diminuindo muito a manutenção a longo prazo de interfaces e permitindo o foco dos colaboradores em pesquisa e inovação.
É tudo de bom não é?
Pilares Essenciais
Agora aprofundando um pouco mais no tema. Ao longo desses anos identifiquei alguns pilares que acredito serem essenciais, ou seja, sem eles, provavelmente um design system não para muito tempo de pé.
Esses pilares de alguma forma dependem uns dos outros, e quando um não está muito bem desenvolvido, você com certeza enfrentará dificuldades em seu dia a dia, então o segredo aqui é construi-los "juntos" ou em curto espaço de tempo, mas de forma que atendam o mínimo viavel para funcionar. ( ou MVP, falaremos mais sobre ) e ir evoluindo-os ao longo do tempo.
Esses pilares são:
A Fundação é o conjunto de decisões "base" das areas envolvidas na criacão dos produtos, essas "decisões" são aquelas que vão servir como norte na idealização e desenho de interfaces e materiais, servindo de alimento para o próximo pilar, que falaremos em breve.
Entende-se "decisões" como qualquer tipo de ação tomada por um grupo de colaboradores que impactarão em como serão as próximas melhorias ( ex: o tom de vermelho usado em uma mensagem de erro. )
Aqui ja deu pra perceber que não é só a squad* de design system que toma decisão, e sim todos os envolvidos, e para isso existem tipos de decisões diferentes que vão colaborar com iniciativas diferentes, alguns deles são:
Decisões de Marketing
São aquelas que envolvem em como a marca se posiciona e quais são os elementos e regras que precisam ser respeitadas nos produtos para manter esse posicionamento.
Algumas iniciativas que se relacionam com o Marketing:
- Padrões Visuais de Marca ( Cores, Tipografias, e afins )
- Padrões de Ilustrações
- Comunicação e Tom de Voz da Marca
- Internacionalização ( Como falar com diferentes países )
Em muitos casos, o marketing da organização é aprovador de mudanças que interferem em como a marca será exibida, então é importante te-los como parceiros em seu projeto.
Decisões de Design
São aquelas que envolvem em como os produtos serão desenhados e quais atributos devem ser respeitados para uma melhor experiência de usuário, alem de padrões de design para manter a consistência de todos os entregáveis.
Algumas iniciativas que se relacionam com o Design:
- Design Tokens* ( Grid, Espaçamentos, Bordas, Opacidade, etc.. )
- Principios de Design
- Padrões de Construção ( Breakpoints, Escala, Ferramentas, e afins)
- Acessibilidade
- Iconografia
Decisões de Desenvolvimento
São aquelas que envolvem em como os produtos serão construidos tecnicamente e quais atributos devem ser respeitados para uma melhor codificação, segurança e legibilidade.
Algumas iniciativas que se relacionam ao Desenvolvimento:
- Framework de Codificação ( Ex: React, Angular, Vue, etc.. )
- Repositorios ( Ex: Github )
- Versionamento e Cadência de Releases.
- Ferramentas de Documentação Técnica ( Ex: Storybook )
Decisões de Conteúdo
São aquelas que envolvem em como o conteúdo textual é trabalhado dentro dos produtos e quais atributos devem ser respeitados para garantir para o usuário final a experiência, a compreensão e direcionamento correto.
Apesar de ter forte sinergia com as decisões de marketing, aqui falamos de um universo muito mais próximo dos produtos do que da marca.
Algumas iniciativas que se relacionam com o Conteúdo:
- Tom de Voz
- Linguagem Inclusiva
- Gramática e Mecanica
- Padronização de Mensagens ( Ex: Erros )
- Vocabulário e afins.
👨🏻💻 Para saber mais sobre:
Artigo — A Fundação de um Design System ( Em Breve )
O pilar de Componentes é o mais conhecido dentro de um design system, ele representa um conjunto de bibliotecas que possuem diversos componentes reutilizáveis, que se usado corretamente permitem a escala, o padrão e a agilidade na produção de interfaces para os produtos da organização.
Eles carregam dentro deles as decisões que foram tomadas na fundação ( ex: Design Tokens* ), e é o que os usuários utilizam em seu dia a dia, e por consequência o que o cliente final interage ao utilizar os produtos.
Algumas bibliotecas que podemos ter dentro desse pilar:
Bibliotecas de Design
Disponibiliza os componentes para utilização dos designers no desenho de interfaces, normalmente são quebradas conforme a necessidade, o mais comum é existir bibliotecas Web ( Desktop ) e Mobile ( iOS & Android ).
Bibliotecas de Desenvolvimento
Disponibiliza os componentes para utilização dos desenvolvedores na construção das interfaces, tambem costumam ser quebradas conforme a necessidade e o mais comum é existir uma Web ( React ) e Mobile ( React Native ).
Bibliotecas de Ilustração ( Opcional )
Disponibiliza as Ilustrações para utilização, seguindo a mesma lógica das bibliotecas de design, porem nesse caso é mais comum em empresas que possuem ilustrações como parte da identidade da marca.
Obs: Existem tambem algumas bibliotecas como as de Tokens e Iconografia, porem as mesmas fazem parte da fundação do DS*, e os componentes se alimentam delas.
👨🏻💻 Para saber mais sobre:
Artigo — Componentes em um Design System ( Em Breve )
Artigo — O que são Design Tokens* e qual sua importância? ( Em Breve )
Enquanto de um lado disponibilizamos componentes e materiais, do outro precisamos entender se todo esse material está atingindo os objetivos que descrevemos lá no comecinho desse artigo, e é ai que o pilar de métricas entra, seu papel é medir a performance do design system diante dos objetivos que ele se propõe a resolver, e auxiliar a tomada de decisão. É um dos pilares mais essenciais quando precisamos gerar visibilidade para stakeholders* e usuários.
Métricas Quantitativas x Qualitativas
As métricas extraídas podem ser de caráter quantitativo ( ex: quantidade de inserções ) ou qualitativo ( ex: NPS*, opinião, feedback* de usuarios ). O importante é sempre entender qual é o problema a ser resolvido e adaptar as métricas para sua necessidade.
Existem inúmeras métricas que podemos extrair em um design system, porem as mais relevantes são:
Métricas de Negócio ( ROI )
Importante para os stakeholders* de negócios e lideranças, são métricas que permitem a visibilidade da gestão do projeto e resultados obtidos até o momento.
Exemplo de Métricas de Negócio:
- Lead time* de desenho e codificação de interfaces ( Antes x depois do uso do DS* )
- Estimativa de R$ economizados através de horas de desenvolvimento e design. ( antes x depois )
- Custo de Estrutura de um DS* x Economia total de R$ ( ROI ).
Métricas de Produto
Permitem a visibilidade da performance do design system e auxiliam a tomada de decisão, impactando na priorização de novas iniciativas.
Exemplo de Métricas de Produto:
- Quantos usuarios ou squads* estão utilizando o DS*
- Quantos % dos produtos foram implementados com DS*
- Lead time* do time de design system em iniciativas especificas.
Métricas de Bibliotecas ( Design & Dev )
Permite a visibilidade de perfomance das bibliotecas , auxiliando nas futuras evoluções, e aqui falamos de componentes, tokens*, icones, ilustrações e afins.
Exemplo de Métricas de Bibliotecas:
- Quantidade de componentes disponíveis
- Componentes mais utilizados nos ambientes.
- Componentes que sofreram "Detach" ou Quebra de Estilo.
👨🏻💻 Para saber mais sobre:
Artigo — Metrificando o seu Design System ( Em Breve )
A Governança é o pilar que foca em como criar os processos adequados para que os times possam usar o DS* sem grandes esforços, sem esses processos, é muito provável que você tenha um produto bem completo porem sem uso e sem perspectiva de evolução.
Algumas atenções que temos dentro desse pilar são:
Processos Internos
Relacionados a squad* dedicada ao DS*, são pensados de forma que automatizem e forneçam todo o entendimento necessário para o time rodar sem impedimentos.
Processos Externos
Direcionam os usuários em como utilizar o design system e fornecem todo o entendimento necessário para que possam encontrar tudo o que precisam.
Contribuição
Dedicados a como abrir o design system para que os usuários possam contribuir na construção e alimentação das bibliotecas.
👨🏻💻 Para saber mais sobre:
Artigo — Governança em Design Systems ( Em Breve )
Ufa.. É só isso? Calma que estamos quase no fim ;)
Artefatos Complementares
Conforme os pilares se tornam mais robustos e cada vez mais completos, começamos a identificar algumas áreas que permeiam esse universo e que nos permitem ter um impacto maior na organização, é ai que entram os artefatos.
O papel dos artefatos é complementar o design system de forma a olhar para a organização e os usuários e permitir o total entendimento da disciplina e de sua importância. Os artefatos são:
Você provavelmente já navegou em alguma documentação de um design system, temos muitas referências bacanas no mercado como : Material Design ( Google ), Carbon ( IBM ), Spectrum ( Adobe ), Solaris ( Shopify ) entre outros. A documentação é algo que nos permite instruir os usuarios das melhores práticas e uso, sem gerar dependência de suporte por parte do time do DS*. Normalmente nesse artefato temos:
Documentação de Design ( ex: Zeroheight )
Exibe todas as boas práticas e instruções de uso de componentes, bibliotecas, tokens* e outros materiais necessários para o usuário.
Documentação Técnica de Desenvolvimento ( ex: Storybook )
Permite a instrução dos desenvolvedores em como utilizar os componentes e tokens* no ambiente de desenvolvimento.
Documentação de Produto ( Interno )
Permite o registro e anotação de documentos de uso exclusivo da squad*. ( ex: Inventário de componentes, planejamentos, e afins.
👨🏻💻 Para saber mais sobre:
Artigo — Documentando seu Design System ( Em Breve )
Assim como qualquer produto, a manutenção é algo frequente e recorrente em times de design system , conforme a empresa e seus produtos evoluem, nós temos o mesmo papel do nosso lado, garantindo que todas as inovações presentes sejam tambem implementadas no DS*.
O papel desse artefato é revisar os pilares e realizar as mudanças necessárias para manter o produto sempre atualizado.
Sem muitos segredos ;)
👨🏻💻 Para saber mais sobre:
Artigo — Manutenção de um Design System ( Em Breve )
O que adianta ter um design system perfeito se ninguém sabe que ele existe? ja deu pra entender qual é a importância desse pilar não é mesmo?
Brincadeiras a parte, a comunicação é um dos artefatos mais importantes quando falamos em um produto desses, afinal, manter tantas coisas padronizadas e organizadas, e ter pessoas utilizando, é preciso muita comunicação pra fazer acontecer.
Podemos dividir a comunicação em um design system em:
Comunicação com Stakeholders e Liderança
Stakeholders* e a liderança são otimos parceiros para ajudar a cascatear o uso de um DS* em uma organização, eles tem o poder de influência, e é uma ótima estratégia tê-los como parceiros de seu projeto. A comunicação com os mesmos é fundamental para a escala e garantir uso pelas squads*.
Relacionamento com Squads e Times
Sempre ouvimos que temos que escutar nossos usuários, e por aqui não é diferente, ter um relacionamento constante com as Squads* e usuários ( designers e devs* ), permitem que você influencie e acompanhe de perto o uso e ainda por cima colha feedbacks* que permitirão identificar os pontos de melhorias futuras.
Divulgação de Resultados e Demonstrações de Novidades
Um design system tende a crescer rapidamente, e toda novidade nesse contexto é de grande valor para toda a organização, por isso divulgar os resultados e demonstrá-los constantemente é uma das chaves para garantir um bom uso por parte dos usuários.
Suporte aos Usuários
Por fim, seus usuários não possuem a obrigação de serem mestres na disciplina de design system, sempre haverá duvidas e dificuldades de uso em algum aspecto, e é ai que você assume o papel junto ao time de gerar o suporte necessário para eles, alem de resolver o problema, você provavelmente ganhará um usuário fiel ao produto. Então sempre separe um tempo de sua sprint para gerar esse suporte.
👨🏻💻 Para saber mais sobre:
Artigo — A importância da Comunicação em um Design System ( Em Breve )
Imagino que se você chegou até aqui, é bem provavel que esteja procurando aprender mais sobre esse tema certo? Fazendo parte de um Design System, seus usuários tambem precisam entender como as coisas funcionam e qual a importância desse tipo de produto na organização.
A Educação possui o papel de educar seus usuários e stakeholders*, nivelando o nível de entendimento e permitindo que usem o produto da melhor maneira possivel. Alguns focos que temos dentro deste artefato:
Capacitação de Usuários ( design + dev )
Iniciativas dedicadas a capacitação específicas dos usuários ( designers e desenvolvedores ), alguns exemplos são: Workshops, Palestras, Vídeos e afins.
Capacitação de Stakeholders ( produto, liderança, etc.. )
Iniciativas dedicadas a capacitar as outras áreas envolvidas, desde os gestores até os P.O's*, P.M's*, Agilistas e afins.
Capacitação do Mercado ( Abrir para o Mercado o DS* )
Aqui falamos de contribuir com a maturidade do mercado em relação ao tema Design System, esse tipo de iniciativa é importante para captação de novos colaboradores, criação de autoridade no mercado, e ajudar a comunidade através da troca de conhecimento.
👨🏻💻 Para saber mais sobre:
Artigo — A responsabilidade de criar uma cultura de Design system. ( Em Breve )
Mantendo a Máquina Funcionando
E para finalizar nosso assunto de hoje, você deve estar se perguntando:
Meu deus! Como meu time vai dar conta de tanta coisa? Como operar com todos esses pilares e artefatos?
Para responder essa pergunta, precisamos primeiramente entender que cada empresa possui a sua realidade, burocracias e necessidades, é importante sempre olhar para o seu contexto antes de começar a priorizar o que foi apresentado aqui em cima. Levando isso em conta, recomendo 3 ações que vão te permitir evoluir com consistência e sem perder os cabelos.
1. Entenda que o processo leva tempo.
Tudo que trouxe até aqui é uma visão de estrutura idealizada. Para que seu time domine todos esses pontos, provavelmente levará tempo de projeto e dependerá da maturidade de design de sua organização ( ex: Não dá para exigir que uma startup nova tenha toda essa estrutura implementada ne? ) sempre avalie a realidade de sua empresa e as oportunidades que existem.
2. Adote sempre a lógica do MVP.
Adote desde já a mentalidade de tudo que você for construir seja pensado em forma de MVP, em outras palavras O "Mínimo Produto Viavel".
Qual é o mínimo viável que eu possa fazer para estruturar esse pilar ou artefato?
Com certeza você encontrará as respostas.
3. Tenha um Roadmap bem definido.
Se por um lado você precisa visualizar o MVP para cada pilar que você deseja construir, do outro lado é recomendado você construir um roadmap* bem organizadinho que permita que essas iniciativas aconteçam. Isso irá proporcionar um crescimento constante e controlado, sem sobrecargas
para o time e o produto.
Afinal, ninguem suporta aquela pressão de ter que entregar algo "urgente". Se em seu roadmap* tudo é urgente, é bem provavel que seu time se desgaste em pouco tempo.
👨🏻💻 Para saber mais sobre:
Artigo — Priorizando o seu design system ( Em Breve )
Conclusão
Construir design systems nem sempre é facil, são muitas variáveis que é preciso ter visão e muitas pessoas envolvidas, então quando for olhar para o seu projeto, pare para entender os pilares e artefatos que são precisos e entenda como projetar uma evolução para o seu produto. Sempre levando em conta que não é um processo rápido e caminhe um passo de cada vez. Garanto que seguindo essas orientações você atingirá algum sucesso na criação do seu produto.
Se chegou até aqui, agradeço sua leitura e espero ter ajudado.
Gratidão e espero tê-lo novamente em novos artigos. 🙏🏼☸️
Sobre o Autor
Herrero é Designer e Especialista em Design System / Ops. Atua a mais de 7 anos na área e possui histórico de projetos em grandes empresas como: Accenture, Itaú, BTG Pactual, Santander, Porto Seguro, etc.. em grande parte projetos direcionados ao tema Design System e Ops, e hoje está por trás do Pulso, o Design System da RaiaDrogasil, que atende multiplas marcas do setor farmaceutico como : Droga Raia, Drogasil, Onofre, Vitat, Needs, entre outras.
Glossário:
DS* = Abreviação de Design System
Squad* = Time dedicado a construção de produtos
Stakeholders* = Pessoas e areas envolvidas no projeto ( ex: diretoria, marketing, comercial, e afins.. )
Tokens* = Variaveis de estilo que são atribuidas aos componentes e refletem as decisões tomadas pelos designers e envolvidos.
Roadmap*= Cronograma e planejamento das entregas do time.
P.O's e P.M's* = Abreviação de Product Owner e Product Manager, papéis presentes em metodologias ágeis como o Scrum.
NPS* = Abreviação de Net Promoter Score, uma forma de avaliar a opinião de seus usuários sobre o seu produto ou serviço
Feedback* = é utilizado, por exemplo, para avaliar uma pessoa, uma empresa, um produto ou um serviço.
ROI*= Abreviação de Retorno de Investimento, métrica e abordagem usada no ambiente de negócios e investimentos.
Lead Time* = Tempo que uma pessoa demora para realizar uma tarefa específica."
Devs* = Abreviação de Desenvolvedores
