Criando um Design System — Do nascimento à publicação, conheça alguns dos processos.
Escrito por: Diego Curumim
Overview do nascimento
Um Design System pode oferecer uma vantagem competitiva, eles reduzem os custos, oferecem agilidade nas soluções que funcionam para vários produtos. Mas antes de sair criando um, com foco apenas no visual ou entregas pontuais, é importante ter a visão do todo, pensar nos processos para a criação e analisar os benefícios, os custos. Analisar os prós e os contras para criar um design system.
Ter essa ponderação, é crucial para que o DS seja escalável e possa alcançar o objetivo. Nesse artigo vou compartilhar quais são os processos que costumo seguir para a criação de um design system, falar um pouco das dores, erros e acertos e alguns dos impactos do design system implementado.
Vamos do começo?
Para começar, podemos elencar as dores que motivam a construção e evolução de um Design System.
Ao trabalhar em uma empresa sem um DS maduro, ou até mesmo na sua falta, as dores que aparecem são bem rotineiras para pessoas que começam a enfrentar o desafio de evoluir um produto ou de construir um Design System, na maioria das vezes elas são as mesmas ou tem proximidades, listo aqui algumas que já me deparei no caminho:
Dores Mapeadas
- Alto questionamento sobre padrões reutilizáveis
- Alto custo de manutenção
- Inconsistência visual entre produtos
- Componentes não desenvolvidos no código ou no design
- Retrabalho por parte dos designers e desenvolvedores
Em seguida
O desafio é catalogar e documentar todos os componentes já existentes, e assim amadurecer o arquivo que virá a ser DS, podemos fazer isso dentro de uma planilha ou mesmo em um arquivo no notion ou até mesmo em um mapa no figma.
A depender do tamanho do time, e com as dores mapeadas, talvez seja necessário realizar muita evangelização de UX para chegar nas camadas mais altas. Isso é bem comum ocorrer em times pequenos pois provavelmente terá que dividir atenção com demandas do dia-a-dia. Mas tenha certeza que essa conscientização dos padrões visuais será muito útil em tarefas compartilhadas entre os times. Ter uma base ajudará na evangelização o DS, podemos ver alguns princípios que essa base vai apoiar a seguir:
- Guiar decisões de design do time CC;
- Ser autênticos e específico, em vez de genérico;
- Boas práticas de acessibilidade
- Foco na usabilidade dos sistemas
- Código limpo e bem estruturado
- Ser facilmente memorizável, fácil de lembrar e reutilizável no dia a dia.
Roadmap e governança, Mapa de progresso e entregáveis
Dando vida ao DS
Depois de mapear os produtos que utilizarão o DS, os problemas e entender a realidade de todo o ecossistema, começo a rascunhar um modelo de start e coloco para rodar naquele momento. Entendendo um pouco mais dos pilares do start, é possível acompanhar o status de toda a vida do DS e ter clareza das etapas da vida do DS, a seguir o que costumo utilizar:
- Roadmap
- Governança
- Mapa de progresso
- Changelog
Um pouco sobre o Roadmap
O ponta pé inicial é fazer um roadmap com entregas pontuais que quero usar e criar, com etapas e datas para ter visão das entregas e avanços. Geralmente uso um cronograma de entrega com as sprints semanais, porém com apenas uma ou duas horas diárias do capacity, isso pode ser usado com uma ideia pra você, vai depender do tamanho do time e do desafio que vc tem em mãos.
Governança
Aplicando a governança
Na tecnologia da informação, o objetivo da Governança de TI é gerar valor. Isso é traduzido em resolver as necessidades das partes interessadas gerando benefícios, basicamente otimizando riscos e otimizando recursos.
Então, trazendo o conjunto de boas práticas (metodologias, métodos, processos, gestão, mecanismos de controle e etc), com o objetivo de reduzir custos e riscos, escalar, otimizar, acelerar e impactar diretamente as entregas. Então, ao aplicarmos a governança no Design System seguindo um processo bem definido para a criação de componentes.
Mas como podemos aplicar isso em uma Biblioteca de Design?
Bem, desenhando etapas de um processo de criação de um novo componente, com perguntas que devem ser respondidas antes de um componente ser alterado, ou instruções de como deve ser documentado melhorias. O fluxo atual que trabalho de forma macro, se apresenta em Descoberta, Design, Construção, Documentação e Aplicação.
(Imagem acima)
Os construtores
Feito por pessoas e áreas
Criar um DS leva tempo, paciência e braço, quanto mais plural e estruturado for o time e as áreas envolvidas, melhor para manutenção e evangelização do produto. Isso pode contribuir com o entendimento das vantagens e desafios desse modelo, o que ajuda a construir um Design System sólido e estruturado mas com alta adaptabilidade, autonomia e com qualidade nas entregas dos componentes. Nesse ponto, vai garantir um Design System dinâmico e mutável, ou seja, não funcionando de forma estática, mas sim repleto de componentes vivos que necessitam ser projetados, codados e revisados. É importante reforçar que o DS deve ficar visível para todos os stakeholders envolvidos no produto e o mesmo sempre passará por diversas manutenções durante sua existência. As etapas anteriores vão ajudar muito (Roadmap e Governança).
A metodologia
Atomic Design
O design atômico é uma metodologia para categorização e padronização de elementos de uma interface, e também na criação de sistemas de design criado pelo Brad Frost. Com essa estrutura, podemos criar átomos, depois, componentes reunindo átomos existentes e assim vamos criando nossos templates e páginas. Assim como no desenvolvimento o design as interfaces são feitas de componentes menores. Isso quer dizer que podemos quebrar interfaces inteiras em blocos de construção fundamentais e trabalhar a partir daí.
Existem cinco níveis distintos no design atômico:
- Atoms
- Molecules
- Organisms
- TemplatesPages
Essa é a essência do design atômico. O impacto disso na manutenção é extremamente importante, pois podemos evitar muita refatoração de telas, é importante ter clareza dessa construção e seguir essas diretrizes, pois com inúmeros arquivos é necessário ter atenção.
O garçom
A quem serve o DS
Com a construção de um Design System, devemos ficar atentos para que o mesmo não sirva somente para especificações visuais de design, as vezes é necessário existir um documento onde as pessoas envolvidas em todos os produtos da companhia podem extrair conteúdo para agilizar seu trabalho e facilitar a implementação de regras de design e código. A estrutura do design system pode servir diversas squads, pode ser descentralizado, e inclusive distribuído a parceiros.
Regras de construção
Metodologia de componentização e Regras de nomenclatura
Para construção dos componentes, geralmente utilizo como inspiração a metodologia BEM, aplicada em desenvolvimento web. Esse padrão consiste de nomeações de classes para os elementos baseado na função estrutural e não na sua função de apresentação. Levando em consideração o componente principal, que entendo como padrão/default, e os seus modificadores/características.
Já quanto à nomenclatura dos componentes, defino algumas regras na montagem, como separação das propriedades com barra e palavras da mesma propriedade separadas em caixa alta. Também considero o que será analisado e levado em consideração no componente, por exemplo, em propriedade analiso se o componente tem a aplicação da cor sólida, apenas contorno, aplicação de contraste, em estado analisamos o estado de interação, se o componente surge como padrão, selecionado, ativo, desabilitado, com interação de hover e etc…
Design Tokens
O que é e pra que servem?
São atributos visuais muito utilizados por times de design e de tecnologia para criar os elementos visuais na construção de produtos.
Para que servem?
Os Tokens são essenciais para facilitar o escalonamento e simplificar as decisões de design, desempenhando um papel fundamental na garantia da consistência de estilo em nosso Design System.
Por que os Design Token são importantes?
Os Design Tokens são importantes por vários motivos, entre eles:
Coerência: Os Tokens de Design viabilizam que times de design e desenvolvimento apliquem de maneira uniforme as diretrizes de design em toda a aplicação, assegurando que o design permaneça homogêneo em todas as páginas e telas.
Flexibilidade: Através dos Tokens de Design, equipes de design e desenvolvimento podem efetuar mudanças e atualizações nas propriedades de design de maneira simples, sem interferir em outras áreas da aplicação.
Simplicidade na Manutenção: Os Tokens de Design são configurados como arquivos de configuração, de fácil processamento e conversão em diversos formatos, o que simplifica a implementação e manutenção das diretrizes de design por parte dos desenvolvedores.
Otimização para Múltiplas Plataformas: Os Tokens de Design podem ser aplicados em diferentes plataformas e tecnologias, abrangendo web, dispositivos móveis e aplicativos de desktop.
Isso possibilita que os times de design e desenvolvimento otimizem o design de acordo com cada plataforma específica.
O impacto no dia a dia
Design System Integrado
Como citei anteriormente, para que a construção de um Design System não sirva somente para especificações visuais de design, podemos e devemos ter um documento onde as pessoas envolvidas em todos os produtos da companhia possam extrair conteúdo para agilizar seu trabalho e facilitar a implementação de regras de design e código.
Vantagens
Com um Design System mais maduro e completo, o ganho que temos em relação ao esforço x tempo é muito grande, com isso podemos focar em validações e etapas mais críticas para o produto em relação a experiência.
Isso vai proporcionar:
- Agilidade
- Padronização
- Documentação
- Co-criação (Whitelabel)
- Redução de custo
- Novas possibilidades de negócio
Logo abaixo trago uma uma tabela com um exemplo prático do impacto de um Design System implementado, essa tabela contém dados previamente testados para implementações de média complexidade, isso será diferente para features e empresas diferentes. Obviamente existem outras maneiras de analisar o impacto de um DS no dia-a-dia, porém não é o foco do artigo.
Documentação
Documentação eficiente
Por último precisamos ter uma documentação eficiente que deve conter todas as informações essenciais sobre uma tarefa, um projeto, produto, em um local centralizado e organizado. Se tratando de documentação de um design system, é de suma importância a documentação dos itens que vimos mais acima, tais como a metodologia utilizada, as regras, o backlog, o fluxo de governança, além dos componentes em sí.
Com a documentação você consegue manter as engrenagens e o padrão rodando sem ter que gastar horas tentando encontrar componentes, templates, informações de como usar, direções e outras coisas, evitando assim retrabalho. Além disso, o mapeamento dos processo, do modelo e da estrutura é útil para novos colaboradores, além de detectar gaps e traçar uma linha de backlog completamente funcional, o que resulta em um processo de melhoria continua.
Conclusão
O foco desse artigo não é a criação de componentes, dos templates e das técnicas que podemos utilizar no FIGMA, isso também é importante para ter um DS funcional. Quis compartilhar um pouco dos processos e da complexidade para criar um design system, ter essa visão pode apoiar os times que estão em processo de formação ou com esse desafio no momento.
Sigo em minha experiência atual e sempre em constante aprendizado, amadurecendo e ouvindo atentamente todas as pessoas ao redor. Espero ter ajudado de alguma forma, compartilhando um pouco da jornada e processo para criar um Design System.
Agora gostaria de saber:
Já participou da construção de um DS, como funciona o seu processo para criar um? Você faria algo diferente do que relatei aqui?
Deixe seu feedback do que achou para que possamos sempre melhorar e entregar o melhor para vocês.
Fale comigo no linkedin(Diego Curumim) ou uxtation@gmail.com
Até a próxima estação!!🚉
#designsystem #organizacao #uxtation #diegocurumim #uxdesign #uidesign #atomicdesign
