Como estamos fazendo Design System na Conta Azul — parte 1: pessoas, modelo de time e contribuição
Design System é sinônimo de consistência, padronização e identificação. É a área de criação e manutenção de componentes para a composição de interfaces. Para garantir sua continuidade, precisamos de uma boa estrutura e muita organização. Quer saber como atuamos na Conta Azul? Confira neste texto.
Dentro do nosso método, consideramos alguns alicerces que precisam estar equilibrados:
- Pessoas e papéis
- Modelo de time
- Contribuição
- Processos
- Cerimônias
- Métricas
Neste artigo, vamos explorar os três primeiros pontos: pessoas e papéis, modelo de time e contribuição.
1. Pessoas e papéis
A squad de Design System (DS) é composta por profissionais dos times de design e de engenharia. Natan Curtis, especialista em Design System, sugere os papéis necessários dentro de uma equipe de DS no artigo Designing a Systems Team.
Neste ano, a Zeroheight divulgou o resultado da sua pesquisa “How We Document 2022”. Podemos observar que 50% dos times têm equipes compostas de 4 a 9 pessoas, e os papéis consistem em designers, engenheiros, PM e content designer, a depender da sua maturidade. Confira o artigo completo aqui.
Ao longo dos anos, nossa equipe foi aprendendo quais seriam as pessoas ideais para criarmos um time de Design System multidisciplinar na Conta Azul. Com isso, chegamos a um modelo contendo os profissionais abaixo:
Liderança de design e liderança de desenvolvimento
A liderança dos times, além de fazer a gestão de pessoas e governança de impedimentos, garante o sincronismo dos objetivos estratégicos do negócio com os objetivos táticos da equipe.
Junto ao PM e ao Tech Lead, o líder também acompanha as métricas de performance e do produto Design System.
Product Manager
Além de ter visão de produto, será um diferencial se o Product Manager (PM) tiver background como designer, uma vez que o product designer também é seu cliente, além da necessidade de análise da experiência do usuário aplicada aos componentes.
Este é o papel que garante a organização do roadmap do time, a priorização das necessidades junto aos stakeholders e a evolução do produto Design System. Sempre zelando pela consistência holística da experiência em todas as plataformas.
Como PM, essa pessoa recebe os pedidos e propostas dos Product Designers, outros PMs e desenvolvedores, busca entender as regras de negócio, adiciona uma visão de futuro, relaciona a pedidos e demandas já existentes e busca dados de comportamento para fazer análises.
Isso tudo para ser certeiro antes e durante o processo de criação ou melhorias de componentes.
Deve definir a prioridade das entregas com os PMs das squads e cuidar para que o roadmap cumpra as datas estipuladas casando com o roadmap de Produto. Após o desenvolvimento, disponibiliza o release das novas funcionalidades do DS. Além disso, analisa e compartilha métricas de performance do time.
Designer
É a pessoa responsável pela padronização da interface dos produtos, discovery dos novos componentes e melhorias dos atuais, levando em conta a identidade da marca, com o objetivo de garantir nossa consistência visual, além das boas práticas de acessibilidade.
Esse profissional precisa entender com o time de design quais as dores que temos em relação ao nosso Design System, bem como os feedbacks dados pelos usuários, e a partir daí deve detalhar e refinar a necessidade com os desenvolvedores.
Além disso, em seu dia a dia, faz revisões nos protótipos do time, trazendo análises e sugestões durante o processo de discovery.
Por último, é responsável por garantir que qualquer alteração ou novo comportamento esteja disponível e bem descrito na documentação do nosso Design System.
Tech Lead Engineer
É o(a) engenheiro(a) responsável tecnicamente pelo time DevX (Developer Experience).
Sendo uma pessoa mais experiente na área, esse profissional participa de reuniões referentes ao contexto não só do time, mas da engenharia (conversa sobre problemas, incidentes, post-mortem, etc); representa o time em reuniões com a liderança; auxilia na tomada de decisões da squad, durante os refinamentos de design e técnicos (junto aos demais colaboradores do time), se envolve em assuntos relacionados a decisões arquiteturais da engenharia, analisa métricas de desenvolvimento da squad, e além disso, tem as mesmas responsabilidades de um Front-End Engineer.
Front-End Engineer
O(a) engenheiro(a) de front-end é responsável principalmente pela execução das atividades na squad.
As principais atribuições são: colaborar nos refinamentos de design e técnico; criar e manter componentes; investigar erros reportados pelos usuário; responder e dar suporte às issues (questões) abertas nos repositórios de responsabilidade do time; e dar suporte ao time de desenvolvimento de produto.
Outras pessoas especialistas
Sempre que necessário, fazemos trabalhos em colaboração com profissionais de writing e ilustração, que fazem parte do time de Design. Já quando se trata de acessibilidade, buscamos especializar os integrantes de DS, incluindo a obrigatoriedade desta disciplina no nosso processo.
2. Modelo de time
Nosso modelo de time é hibrido ou cíclico (que combina os modelos centralizado e federado). Nascemos como um DS centralizado, baseado na definição proposta por Natan Curtis. Mas, ao longo dos anos, a colaboração espontânea se tornou cada vez mais perceptível (modelo federado), por isso hoje trabalhamos com um modelo adaptado à nossa realidade.
Essa estrutura de time é a mesma utilizada na Salesforce, porém, na Conta Azul, tudo o que é previsto pelas squads passa pela validação de DS.
A squad de DS centraliza a governança, então temos a responsabilidade de organizar, atualizar, documentar, corrigir, fazer melhorias e também releases de tudo que foi desenvolvido.
Designers e desenvolvedores de produto colaboram quando trazem as necessidades dos usuários, participam dos refinamentos e desenvolvem o componente.
3. Contribuição
Além das necessidades de atualizações e melhorias identificadas pelo designer e PM do próprio Design System, as contribuições vêm geralmente de product designers e desenvolvedores, conforme abaixo:
Product Designers
Durante o processo de discovery, muitas vezes os Product Designers (PDs) percebem a necessidade de serem criados ou atualizados os componentes para o produto.
É normalmente nas cerimônias de Review de Design System e Collab que eles trazem propostas e solicitam melhorias com base nas discoveries que realizam.
Junto com a squad de DS, os PDs desenham propostas e estudam se a melhoria atende a necessidade levantada.
Desenvolvedores
Os Devs colaboram tanto de forma espontânea, por exemplo quando encontram e resolvem bugs, ou sob demanda, quando desenvolvem o componente com o apoio de DS.
Buscamos a participação deles nos refinamentos e apoiamos no desenvolvimento.
No nosso próximo artigo, mostraremos como essa colaboração acontece durante nosso processo.
Resumo
Neste artigo, falamos sobre os profissionais atuantes na squad de Design System e seus papéis, nosso próprio modelo de time e como funciona a contribuição entre squads de produto e a squad Design System.
Como comentamos acima, nosso modelo de trabalho começou a partir de referências como a de Natan Curtis. Com o tempo e o nosso amadurecimento como time, fomos criando nosso próprio formato.
Assim, concluímos que cada empresa adapta os modelos à sua necessidade. Por isso, incentivamos você a compreender de que maneira sua empresa pode adequar formatos como o nosso para sua realidade.
Que tal comentar abaixo como tem sido o modelo de Design System no seu time de Design?
E se liga que, em breve, vamos falar sobre os outros alicerces do nosso Design System.
