O Design System nasceu! E agora? Como manter ele funcionando?

Em 2019 muito se foi falado sobre criação de Design Systems, Metodologias, Princípios e tudo mais. Só que, todo case que achamos na internet parece perfeito, poucas pessoas falam sobre erros e isso gera muitas frustrações em quem está começando.

O assunto que eu realmente sinto falta é “como manter um Design System?”. Poucas pessoas falam sobre e há poucos artigos também. Nada é perfeito e sempre aparecerá uma variável que vai fazer você se perguntar “O que devo fazer agora?”.

Vou te deixar um pouco mais tranquilo(a) contando a minha experiência sobre como entendemos que deveria existir uma Governança do Design System.

Iniciamos nosso projeto já tendo uma biblioteca de Design, com componentes que atendiam perfeitamente os Product Designers. Até aí, tudo bem, mas não conseguíamos fazer tudo sozinhos e, na atual situação, não podíamos tirar os devs de seus respectivos squads.

Uma das principais soluções foi criar uma reunião semanal com os pontos focais de cada plataforma para estruturarmos e irmos criando os componentes juntos. Em uma dessas reuniões, fomos questionados sobre alguns processos, como: “Quando teremos especificação dos componentes?”, “Vocês fazem algum tipo de alinhamento com os Designers?”, “Por que os Designers estão alterando componentes?”, “Vocês não fazem um “Code Review” de Design?”.

Perguntas que já deveríamos ter as respostas antes de iniciarmos o projeto.

O que podemos concluir com isso então? Faltavam processos de governança!

Então, criamos alguns processos. O primeiro foi dar autonomia aos desenvolvedores para que eles conseguissem se comunicar com os designers. A outra dor foi como manteríamos a consistência dos itens da biblioteca sem limitar a criatividade dos Designers?Para conseguir resolver essa e outras questões, de início tivemos a ideia de gerar um pequeno fluxograma de como funcionaria a criação de componentes, esse que separamos em sete partes:

1 - Ideia

É quando o Designer vê a necessidade de criar um componente para atender a demanda em andamento, sempre pedimos para eles verificarem se não tem nada de parecido em nossa Biblioteca que posso ser utilizada, caso não tenha, seguimos para a próxima etapa.

2 - Validação

Nessa etapa o Designer deverá trazer a Ideia, componente ou bug, para nós - Área de Design Ops - para entendermos e validar se de fato há essa necessidade. Ajudamos a entender não só a necessidade, mas sim, a funcionalidade do componente, tendo em vista que já tivemos problemas de tentarem mudar a funcionalidade e isso atrapalharia o processo de onboarding de um Design recém-chegado, assim como a vida do DEV tendo que alterar a funcionalidade de algo pré-definido. Por isso, nessa etapa tentamos validar com os Desenvolvedores também.

3 - Especificação

Nessa parte voltamos para o Designer responsável pela criação do componente, ele deve nos explicar como o componente vai funcionar e quais serão seus comportamentos.
O DEV precisa disso para a construção, sem a especificação tudo pode acontecer e isso seria uma loucura.

4 - Inclusão na Biblioteca de Design e no Zeplin

Depois da ideia passar pela validação e especificação, nós criamos as variações do componente na nossa biblioteca e subimos no Zeplin, em um projeto de componentes que está dividido para cada plataforma, aqui trabalhamos com Web, Android e IOS.
É através esses projetos que os DEVs também sabem o que tem ou não no Design System.

5 - Construção do Componentes

Seguimos então para a etapa cinco, que é a criação do componente. Essa etapa é dedicada exclusivamente aos DEVs, onde eles irão codar seguindo as especificações e se baseando nos estados definidos e inclusos no Zeplin, depois de criados eles também já fazem os testes unitários para validação deles.

6 – Documentação

A documentação é algo que ainda precisamos aprimorar. Já estamos construindo, mas ainda falta bastante coisa. Nessa etapa iremos descrever qual a finalidade do componente, como ele deve se comportar e como deve ou não ser usado. Seria uma documentação maior e baseada nas especificações para que qualquer pessoa que leia, entenda para que serve e em qual contexto aquele componente deve ser usado.

7 – QA

Iremos validar se aquele componente está seguindo todas as especificações proposta pelo Designer, tanto funcionalmente quanto visualmente. Se “OK”, o componente segue para produção, se “NOK” o componente volta para o DEV realizar os devidos ajustes.

‍

Com tudo isso, conseguimos matar parte dos problemas. Mas, para continuarmos mantendo a consistência do nosso Design System, incluímos também o Design Review, que nada mais é do que o Designer apresentar seu projeto para nós antes de ser apresentado para a Squad. Lembra que eu comentei sobre funcionalidades de componentes? Nesse processo conseguimos pegar muito disso e é muito bom para mantermos a saúde do nosso produto.

Esses pequenos processos já nos ajudaram muito e foi a maneira que encontramos para acompanhar a validação dos componentes criados e melhorar nossos processos para mantermos a consistência. Lembrando que, pode ser que para você esse processo não funcione da mesma maneira. Uma coisa que costumo dizer é que “Nada é uma verdade absoluta”, então o que é certo para mim, pode não ser para você, mas podemos aprender juntos. Então, compartilhe seus aprendizados, tudo de bom e de ruim que aconteceu em sua jornada e lembre-se de já criar processos antes de iniciar o seu Design System, muitas complicações e dores de cabeça podem ser evitadas.

Depois me conta!  😉