Formação e organização de times de Design

Imagem: Designers em reunião no lounge da Conta Azul

Artigo publicado originalmente no design2020.

Enquanto algumas empresas já têm mais de 100 designers na organização, outras ainda estão aprendendo a estruturar e a escalar times de Design. Fato é que não importa o tamanho da empresa, uma discussão recorrente é a maneira adequada de organizar o time.

Você já deve ter ouvido falar no “modelo Spotify” na criação de times de produto. Várias empresas adotaram este formato — inclusive, aqui na Conta Azul, nos baseamos nele (contei um pouco neste post).

Com este artigo, pretendo discutir um pouco sobre organização de times de Design e porque eu acredito que o “modelo padrão Spotify” não funciona.

Minha opinião é baseada no que tenho vivido e na maneira como estamos organizados na Conta Azul. Espero que este texto também ajude você a refletir sobre o que pode funcionar na sua empresa e no seu time de Design.

Vamos lá? :)

‍

Você deve concordar, o modelo Spotify tornou-se comum. Várias empresas adotaram e são poucas as que têm organizado o time com outro formato. Mas, e qual o problema de pensar e organizar o time de maneira “padrão”? É fácil, conhecido, seguro.

‍

Imagem: Organização do time de Produtos na Conta Azul

Quando entrei na Conta Azul já havia uma organização em squads e, no início, realmente parecia fazer sentido.

Entretanto, após um tempo gerenciando o time, consigo entender melhor sobre este formato e ter mais clareza sobre alguns pontos que podem ser um problema.

O que não funciona

1. Tendo um designer por squad, você, líder, terá um especialista em determinado assunto. Isso pode parecer bom, afinal, essa pessoa conseguirá entender com profundidade o produto e terá um ownership maior sobre as entregas. O problema que as pessoas não ficam para sempre na mesma empresa. Então se elas saírem (e vão sair), você perderá um especialista. Isto tem um custo altíssimo para a empresa, pois, quanto tempo levará para que outra pessoa aprenda tudo novamente? Sem falar no conhecimento que vai embora com a pessoa que saiu.
2. Quando você tem um especialista no assunto, ele pode não conhecer com profundidade o restante do produto. Isso é ruim, pois, as discussões com outros designers (ou pessoas do time de produto), ficam pobres. E ritos como design critique (leia sobre este rito aqui), ficam rasas.
3. Sempre que uma squad nova é formada, você precisa de um designer. Este problema é o mais comum. Tenho conversado com pessoas de várias empresas e é impressionante como o número de designers tem crescido em função disso. Além de impactar em custos, isso impacta na eficiência da empresa. Duas coisas importantes para um líder se preocupar.
4. O designer pode virar “recurso” do PO/PM. Isso é extremamente comum. O time de gestão de produto tem um controle maior sobre quem está na squad e quais entregas estão acontecendo. Dessa maneira, o designer passa a atender somente demandas provenientes daquele time. Quando iniciei um movimento para tirar os designers das squads, vários POs vieram conversar comigo porque não podiam ficar sem designer no time (mesmo eu explicando que eles estariam atendendo a tribo como um todo).
5. Com os designers alocados em squads fixas, se você precisa de um designer para um projeto específico, possivelmente terá que contratar outra pessoa.
6. A cocriação entre designers acontece com uma frequência menor. Geralmente eles se encontram apenas nas design critiques e poucas vezes conseguem trabalhar em conjunto — principalmente nas fases de ideação.

Como organizar o time

Quando me deparei com esses problemas, comecei a pensar em outros formatos que atendessem alguns pontos, os quais eu acredito serem importantes para organização do time de Design — independente do tamanho da empresa:

1. O modelo precisa facilitar a cocriação entre designers;
2. O conhecimento não pode ficar somente com uma pessoa;
3. Designers não podem ser “especialistas”. É necessário que o formato favoreça a criação de uma visão sistêmica do produto;
4. Os designers não devem ficar atrelados a um PO/PM. E o roadmap deles precisa estar sob o controle da liderança de Design;
5. O time não pode virar uma “agência in house”. Ou seja, não pode ser um time que só atende demandas. Os designers também serão responsáveis por gerar demandas e fazer entregas maiores para o time de produto.

Para onde estamos indo

Com base nesses aprendizados, consegui entender um caminho que pode funcionar para a Conta Azul e que atende as premissas listadas acima.

Compartilhei algumas hipóteses com o time e todos os caminhos tinham prós e contras. Por isso, decidi rodar um piloto com dois designers, com o objetivo de gerar aprendizados sobre a nova estrutura antes de replicar para outros times.

Até então rodamos com um Product Designer (PD) por squad, conectado a um Product Owner (PO) que está conectado ao time de desenvolvimento (DEV).

Minha intenção é tirar os designers de squads específicas e colocar eles olhando para a jornada do cliente. Dessa maneira, criamos um “pool de designers”, que passa a atender a uma determinada etapa da jornada. Com isso, deixam de olhar para as features e passam a ter uma visão sistêmica do produto.

Iniciamos o teste piloto pela etapa de conversão. Colocamos dois designers trabalhando juntos para aprender sobre o modelo e entender o que funciona e o que não funciona. Esta etapa é extremamente importante para criarmos aprendizados antes de virarmos a chave com todas as squads.

O que temos visto até agora é que este modelo, além de facilitar a cocriação, ajuda no entendimento do negócio como um todo. Do mesmo modo, traz mais responsabilidades para os designers, já que eles passam a ter um controle maior sobre as demandas. Eles não podem ficar esperando alguém dizer o que precisam fazer, já que o objetivo final é o resultado esperado atrelado ao negócio e não a entrega de uma feature ou melhoria no produto.

Conclusão

Como ainda estamos testando o modelo, é difícil dizer se ele dará certo. A certeza que tenho é que o “modelo padrão” não funciona para nós. Isso já é meio caminho andado para entendermos outros modelos e fazermos testes até encontrarmos o que realmente funciona para a gente.

É clichê dizer isso, mas é importante entender que não existe uma resposta/modelo certo. É preciso compreender, antes de tudo, o contexto em que você está inserido e avaliar o que pode funcionar neste cenário.

Além disso, é importante você ter em mente a visão de Design da empresa em que você está, isso ajuda a firmar estruturas coerentes com esta visão.

E você, como está organizado na sua empresa? Se quiser falar mais sobre o assunto é só me enviar um e-mail: victor@zanini.design

:)