O Processo de Governança de Sistemas de Design.
10 passos para organizar seu processo.
Introdução
Você pode ter um sistema de design abrangente, com uma série de componentes bem estruturados, documentação completa, diretrizes cuidadosas e uma linguagem de design bem pensada. Mas se um usuário do sistema de design não conseguir realizar o que está tentando fazer, todo o sistema corre o risco de se tornar obsoleto.
As equipes de produto têm como principal preocupação entregar o trabalho, não manter a integridade do sistema de design. As equipes se tornam criativas e encontrarão maneiras de fazer as coisas, o que pode envolver hackear estilos, criar uma série de componentes únicos ou abandonar completamente o sistema de design.
É por isso que é extremamente importante que os criadores do sistema de design estabeleçam um processo de governança cristalino que ajude os usuários a entender o que fazer quando:
- Não conseguem encontrar um componente que faça o que precisam
- Um componente do sistema de design os leva 90% do caminho, mas não 100%
- Têm perguntas ou preocupações sobre o sistema de design
Em nosso trabalho com sistemas de design em grandes organizações, descobrimos que um processo de governança é um dos ingredientes mais importantes de um sistema de design saudável que resiste ao teste do tempo.
O Processo de Governança em 10 Passos
Passo 1: As Equipes de Produto Usam o Sistema de Design
As equipes devem usar por padrão os componentes do sistema de design para criar novos trabalhos de produto. O melhor cenário é quando uma equipe acessa a biblioteca, encontra o componente necessário e descobre que ele atende a todos os seus requisitos. Eles simplesmente plugam o componente e seguem em frente com questões mais urgentes.
Passo 2: Quando os Componentes Não Existem ou Não Atendem aos Requisitos
Se a equipe não encontra o componente necessário, se um componente existente não atende a todos os requisitos, ou se não têm certeza se o sistema tem o que precisam, o primeiro passo é entrar em contato com a equipe do sistema de design. Isso pode ser feito via Slack, rastreadores de problemas (Github, Jira, etc.) ou outros canais.
As equipes terão uma conversa para entender melhor o problema e determinar se um novo trabalho precisa ser feito. Frequentemente, a equipe do sistema de design pode orientar a equipe de produto para uma solução existente que atenda aos requisitos.
Passo 3: Determinando se o Novo Trabalho é um “Floco de Neve” ou Parte do Sistema de Design
Se as equipes concordam que um novo trabalho precisa ser feito, a primeira coisa a ser determinada é se o trabalho é:
- Um “floco de neve”: um componente único que se aplica apenas a um produto ou caso de uso específico.
- Parte do sistema de design: um componente ou variação que faz parte da biblioteca que atende a todos os produtos.
Se o trabalho for um floco de neve, será adicionado ao backlog da equipe de produto específica. Se for parte do sistema de design, será adicionado ao backlog do sistema de design.
Passo 4: Prototipar o Conceito Inicial
Uma vez que as equipes determinam quem liderará o conceito inicial, essa equipe produzirá os conceitos iniciais para o trabalho. Isso pode assumir a forma de um wireframe, esboço, protótipo no navegador ou qualquer outro artefato que articule rapidamente e claramente o caso de uso e defina o trabalho a ser feito.
Passo 5: Revisar o Conceito Inicial
A equipe do sistema de design e a equipe de produto se reunirão para revisar o conceito e determinar se ele atende a todos os requisitos. Se algo estiver faltando, a equipe iterará sobre o conceito e as equipes continuarão revisando até que os requisitos sejam atendidos.
Passo 6: Processo Formal de Design/Desenvolvimento e Testes do Sistema de Design
Com o conceito aprovado por ambas as equipes, a equipe do sistema de design assumirá o trabalho como parte do roteiro de produto do sistema de design. Este processo envolve:
- Representar o novo componente ou variação em ferramentas de design estático (como Sketch ou Figma)
- Construir o componente no ambiente de workshop frontend do sistema de design
- Seguir as diretrizes de código do sistema de design
- Considerar reuso, flexibilidade, acessibilidade, desempenho e outras melhores práticas
Quando o componente é construído, os testes serão realizados nas seguintes áreas:
- Conteúdo
- Acessibilidade
- Cross-browser/dispositivo
- Responsividade
- Funcionalidade
- Testes de estresse
- Revisão interna de código
- Revisão interna de design
- Testes em aplicações
- Qualquer outro QA e teste interno
Passo 7: Revisão Final com a Equipe de Produto
A equipe de produto e a equipe do sistema de design se reunirão para uma revisão final. Se a equipe de produto não aprovar o trabalho, a iteração acontecerá e as equipes se reagruparão até que a equipe de produto aprove o trabalho.
Passo 8: Documentação e Preparação para Lançamento
Uma vez que a aprovação aconteça, o componente/variação será documentado no site do guia de estilo, a documentação de código e API será finalizada, o changelog será atualizado e o branch de feature será mesclado no branch de desenvolvimento.
Passo 9: Novo Lançamento do Sistema de Design
Quando for hora de criar um novo lançamento, uma nova versão do sistema de design é lançada contendo o novo trabalho, seguindo as diretrizes de versionamento semântico delineadas pelo sistema. A equipe de design comunica o novo lançamento por todos os canais apropriados.
Passo 10: Processo de Adoção e QA pela Equipe de Produto
A equipe de produto puxa a nova versão do sistema de design para seu ambiente de aplicação e testa o novo trabalho. Se surgirem perguntas ou bugs, eles seguem o processo de suporte para lidar com quaisquer questões ou problemas. Se nenhum bug for encontrado, o trabalho é preparado para o próximo lançamento da aplicação.
Adaptar e Evoluir
Este é um processo bastante longo para ir de “Não vejo o componente que preciso” a “Esse novo componente agora está lançado em nosso produto”. Mas descobrimos que detalhar as coisas dessa maneira granular ajuda a construir confiança entre as equipes de produto e a equipe do sistema de design, e reduz a ansiedade em torno de como o novo trabalho é criado.
Vale notar que o título deste post é “Um Processo de Governança de Sistema de Design”, não “O Processo de Governança de Sistema de Design”. Embora este fluxo de trabalho possa ser um ótimo ponto de partida para conversas, é absolutamente essencial estabelecer um processo de governança que melhor se adapte à sua organização.
Estabelecer um processo de governança de sistema de design é talvez uma das coisas mais importantes que você pode fazer para evitar que a entropia tome conta do seu sistema de design. Desejo a você o melhor sucesso (a longo prazo) com seu sistema de design!
Este artigo foi inspirado no trabalho de Brad Frost sobre governança de sistemas de design. Brad Frost é um consultor de sistemas de design, web designer, palestrante, escritor e músico em Pittsburgh, PA.
Referência
FROST, Brad. A Design System Governance Process. 2020. Disponível em: https://bradfrost.com/blog/post/a-design-system-governance-process/. Acesso em: 24 jul. 2024.
