4 modelos de times de Design Systems
Nesse artigo vou mostrar 4 modelos de times mais conhecidos para desenvolver e manter um Design System e quem sabe te ajudar a escolher o modelo apropriado :)
Primeiro passo é entender o seu contexto
Aqui eu conto um pouco sobre o que já estudei (Vou deixar as referências no final desse artigo) e minha experiência com times de Design Systems por onde passei, cada empresa é diferente. Elas têm equipes de tamanhos diferentes, usuários diferentes e desafios diferentes. A única comparação que você deve fazer ao criar um Design System é como era antes de tê-lo.
Tendo isso bem claro, você e sua equipe poderão ser mais assertivos no momento de escolher o modelo de time para desenvolver e manter seu DS.
Antes também de pensar em times, você talvez tenha que vender essa idéia dentro da empresa
Conversando com designers e desenvolvedores já escutei algumas vezes que muitos desejam começar um Design System por que acreditam que isso iria colaborar com suas atividades diárias e consequentemente entregar mais valor, mas não sabem por onde começar e como convencer os envolvidos que isso tem valor.
Dado isso, eu acredito que temos que dar um passo atrás e validar se faz sentido para o seu produto ter um Design System, pode fazer sentido não tê-lo.
Validado que o Design System realmente tem um potêncial de ajudar o negócio e seus clientes, então como vender essa idéia dentro da empresa?
É ai que eu acredito que vem o primeiro modelo de time de Design System que pode te ajudar com isso.
Modelos de times de Design System mais conhecidos
1. Modelo de equipe solitária
O modelo de equipe solitária existe com frequência e eu acredito que é um bom modelo para iniciar um Design System dentro de uma empresa.
Esse modelo geralmente é composto por um designer e um desenvolvedor, que por conta própria e a parte de suas responsabilidades diárias, começam a desenhar e codar componentes, desenvolver e compartilhar UI kits e assim começam a colher os benefícios iniciais de um Design System. São os apaixonados que vão dentro da empresa iniciar esse produto.
É importante dar visibilidade desses primeiros benefícios que surgem, para que os envolvidos vejam o valor e o Design System possa evoluir.
Essa iniciativa de começar algo por conta própria é importante. Você tem que vir com o bolo pronto às vezes em vez de perguntar se pode fazê-lo. Faça, se tiver que pedir desculpas depois, ok!
Comece pelo básico, e um exemplo disso é o Mondrian, Design System da Claro. Como eles apresentaram no Design System Conf, inciaram padronizando assets da marca, como os logos, imagens, tipografias e disponibilizando isso de forma organizada para ser consumido. Hoje o Modrian é um Design System estabelecido e conhecido, com uma ótima equipe por trás, reconhecida por isso, ou seja, dá pra chegar lá :).
Mas esse modelo solitário não tem poder de escala, são profissionais que estão por conta própria, desenvolvendo utilizando um tempo extra do que eles tem disponível. Você tem que trabalhar com um número maior de pessoas dedicadas caso queira escalar. Por que ninguém é onipresente né :)
2. Modelo de equipe centralizada
Você já conseguiu provar o valor dos benefícios do Design System e agora precisa evoluí-lo como produto e precisa de pessoas dedicadas. Se o seu contexto é esse talvez o modelo de equipe centralizada possa te ajudar.
Um modelo de equipe centralizada desenvolve e mantém um Design System com um grupo de pessoas dedicadas em tempo parcial ou integral.
Com esse modelo a equipe consegue escalar melhor e manter um Design System, tendo mais tempo para atender os outros designers que demandam, por exemplo, componentes novos.
Com mais tempo e autonomia essa equipe consegue estabelecer práticas e processos que vão ajudar o Design System evoluir.
É possível estabelecer rituais onde essa equipe se junta com os outros designers para entender as necessidades e assim manter o Design System em constante evolução, afinal um Design System também é um produto e sempre está evoluindo.
É sempre muito importante manter uma abertura para ouvir os outros designers que consomem o Design System, ou seja, essa equipe centralizada não toma as decisões sozinha, na verdade ela está para atender as demais equipes.
Assim também é importante promover essa participação, as pessoas não vão se juntar a essa equipe por que sim, elas tem outras entregas, outras prioridades, então promova essa colaboração, no final tudo se trata de pessoas.
3. Modelo de equipe Federada
Nesse modelo federado é possível ter embaixadores que desenvolvem e mantém o Design System coletivamente. Nesse caso não temos uma equipe centralizada e sim embaixadores espalhados pelas squads, eles tomam decisões coletivamente, mesmo que nem todos eles desenvolvam e documentem todas essas decisões.
Nesse modelo temos um ganho porque o embaixador não fica somente focado no Design System, ele continua com as outras demandas como por exemplo desenvolvimento features, pesquisas etc.
O embaixador está inserido dentro de uma squad, o que pode evitar o distanciamento do Design System das reais necessidades daquela squad, ele tem um contexto muito melhor, logo, as decisões que ele toma em conjunto com os outros embaixadores atendem a real necessidade da sua equipe, isso pode não acontecer no modelo centralizado, por exemplo.
Esse modelo começa a permitir uma visão multiplataformas e elimina os viéses de uma equipe centralizada abrindo seu Design System para várias perspectivas.
4. Modelo de equipe Combinada
Não é um quarto modelo e sim a fusão entre o centralizado e o federado.
Talvez na teoria o modelo Federado sugere ser o ideal, mas pode acontecer desses embaixadores, estarem muito ocupados com demandas de suas squads e mesmo que eles desejem contribuir e documentar, eles não tem tempo ou simplesmente não o fazem, estão pouco engajados.
Com o tempo pode acontecer que o processo de decisão se torne confuso, reuniões pouco produtivas, ninguém lembra quais foram os caminhos que levaram a tal decisão, começam a tomar decisões isoladamente e com isso o Design System pode não funcionar como deveria.
Então podemos pensar nessa fusão, de modelo centralizado como bibliotecária, distribuidora e facilitadora, com o modelo federado que traz as demandas e atualizações para o Design System.
Resumindo
Existem pontos fortes e fracos em cada um dos modelos acima. O que se vê por ai é que muitas equipes estão se afastando do modelo solitário para o modelo centralizado, compartilhado ou combinado.
Mais modelos por aí?
Sem dúvida, existem outros modelos de times para desenvolver e manter Design Systems e quem quiser bater um papo sobre esse assunto, é só me adicionar no Linkedin e bora trocar conhecimento :)
Referências desse artigo e leitura recomendável:
- Design Better Manual de Sistemas de Design: https://bit.ly/2yvjyrc
- O modelo da Salesforce: https://bit.ly/3cf7qJT
- Modelos de equipes para criar um Design System: https://bit.ly/2SBUS7g
- Criando uma equipe de sistemas: https://bit.ly/2L4jj9b
- Vale acompanhar o Nathan Curtis autor de alguns artigos mencionados acima
