Desafios de liderança em DesignOps

Os primeiros passos na liderança de operações de design no QuintoAndar

Imagem com o título do post, "Desafios de liderança em DesignOps". Ilustração por Duds Saldanha.

Entrei em janeiro no QuintoAndar com a missão de organizar as operações de design de produto. Foi dentro desse desafio que escrevi, lá no início do ano, sobre aquilo que envolve operações de design. Falei um pouco sobre o dia a dia em tarefas mais tangíveis.

Desde então, o cenário mudou um pouco por aqui: saímos de uma pessoa com foco em operações de design para uma equipe com cinco designers. Tivemos que repensar nossa estrutura, papéis, rituais, objetivos, comunicação, enfim. Tudo isso enquanto entendia meu papel enquanto líder de operações de design, a diferença entre operacionalizar e facilitar a operacionalização.

Desafio 1: Ter uma missão

Diversas mãos sobre uma série de janelas abertas em um desktop. Ilustração por Duds Saldanha.

Hoje, em operações de design no QuintoAndar, focamos em pesquisa, escrita e design system. Os nomes e descrições dos cargos são o de menos. Na prática, são designers de produto dentro de um time de operações de design — a diferença é que podem navegar por diferentes squads depois de uma estadia em DesignOps. Aqui no QuintoAndar, entendemos design de produto como uma disciplina generalista e criamos uma estrutura maleável o suficiente para que as pessoas tenham sempre desafios diferentes. Apostamos nisso para dar mais autonomia na tomada de decisão dentro de design e manter a curva de aprendizagem em constante atualização.

Para nós, DesignOps é uma forma de dar respaldo para generalistas tomarem decisões com a ajuda de especialistas e não um passo para a especialização do time todo.

Por exemplo, uma designer generalista pode se apoiar em um guia de UX writing para escrever o diálogo de uma interface; usar uma base de conhecimento para decidir como aplicar um método de design; inserir achados de pesquisa em uma base de dados gerida por operações de design. E por aí vai.

É por isso que pensar na missão de DesignOps para o nosso contexto foi tão desafiador. Não ter papéis fechados para cada especialidade é algo diferente do que vemos no mercado e precisávamos adaptar diversas práticas ao nosso contexto. Queríamos que pesquisa, UX writing, design system e melhorias de processo fizessem parte da rotina de todas as pessoas, e uma camada operacional deveria ajudar nisso.

Foi pensando nisso que definimos como nossa missão: empoderar os designers de produto para que atuem cada vez mais em uma camada estratégica, automatizando processos, tornando-os fáceis e acessíveis.

Nosso maior receio era que DesignOps virasse uma espécie de agência interna, fornecedora de pesquisas, componentes de design system e revisão de textos. Por isso, foi tão importante definir essa missão e deixar evidente o que fazemos e o que não fazemos. Até mesmo design system, que pode facilmente se tornar uma disciplina isolada dentro de um time, foi pensado de forma colaborativa, com todas as pessoas auxiliando no desenho e desenvolvimento das regras e componentes.

Desafio 2: Definir um escopo

Duas mãos desenhando um fluxograma. Ilustração por Duds Saldanha.

Definir uma visão é tangibilizar a missão construída pelo time; é definir um escopo. E, convenhamos, uma missão ajuda a dar direcionamento, mas se não tiver artefatos, entregas mais tangíveis, de nada serve. Como explicar o que é uma entrega em operações de design? Contei um pouco no post anterior sobre como fizemos uma imersão no QuintoAndar no início do ano, e todo o insumo gerado lá atrás nos ajudou a desenhar uma proposta relevante para a empresa.

Decidimos por manter uma base comum de conhecimento e criar ferramentas que facilitam o trabalho das designers de produto da empresa. Essas ferramentas são: guias de UX writing; novos componentes no design system; guias e boas práticas de pesquisa; treinamentos internos para a equipe de design. Optamos por esses artefatos porque escalamos rápido nos últimos meses, e manter uma base comum de conhecimento é importante para que todos os designers bebam da mesma fonte de informação (imagina só: fomos de 15 para 40 designers em menos de um ano).

Dividimos essas demandas entre 3 grandes áreas: pesquisa, UX writing e system. Falando em estrutura de empresa e produto, e considerando o famoso modelo Spotify, somos uma espécie de tribo com alguns squads — sendo Design System o mais completo, com tech lead, product manager e três engenheiras/os. As outras disciplinas, de escrita e pesquisa, estão em fase mais embrionária e se encontram num único squad.

Além do feijão com arroz, que são os guias iniciais para o time de design, todas as pessoas de operações trabalham no entendimento das oportunidades de atuação no QuintoAndar. Como estamos crescendo de maneira exponencial, precisamos entender como escalar essas práticas além de uma base de conhecimento. Por isso, rodamos uma série de treinamentos internos para que as pessoas coloquem em prática esse conteúdo.

Desafio 3: Comunicar as entregas

Uma série de janelas abertas, uma sobre a outra, contendo gráficos e newsletter. Ilustração por Duds Saldanha.

Com cinco designers o desafio extrapola o da auto-organização (o da one woman band). Agora, nós nos reunimos semanalmente para planejar e acompanhar as tarefas que definimos e priorizamos. Também fazemos tudo o que outras tribos fazem: rituais de health check, retrospectiva, entre outros.

No caso da liderança, surgiram outras demandas, como o acompanhamento de cada pessoa, seus planos de desenvolvimento, 1:1s recorrentes e alinhamentos macro com outros stakeholders. Esse último, pessoalmente, considero o maior desafio: como definir as pessoas-chave e comunicá-las sobre nossas entregas? Como saber se a comunicação está efetiva, se as pessoas entendem o que fazemos e para onde queremos ir?

Foi aí que criamos nossas primeiras newsletters mensais de DesignOps, falando sobre os ganhos gerados pela base de conhecimento, treinamentos e guias construídos para o time. Dá uma sensação de dever cumprido: é bom para o time parar e ver o quanto foi entregue e para formalizar as entregas com os principais stakeholders.

Além da newsletter, também nos orientamos a algumas métricas (traduzidas em OKRs — objectives and key results), que ajudam a alinhar as expectativas do time com as expectativas do QuintoAndar como um todo. Faz o time se sentir parte de algo maior. Mas um aviso: não definimos OKRs com esse objetivo (de alinhar com stakeholders). Definimos OKRs para o próprio time enxergar o progresso e o impacto que tem sobre o negócio. Métricas não devem ter fim em si mesmas. Antes de pensar em sair metrificando tudo, é importante ter um time alinhado, definindo uma missão, tangibilizando em uma visão e quebrando em objetivos. Isso, para mim, é o mais importante.

Desafio 4: Desenhar possibilidades de futuro

Uma bola de cristal em cima de um computador, acompanhada por gráficos e uma barra de progresso. Ilustração por Duds Saldanha.

Dentro de startups, as coisas mudam constantemente — não é conversinha. Nos dividimos em trimestres e, a cada bloco de tempo, surgem inúmeras oportunidades e desafios complexos. A gente aprende, cresce, desapega, reconstrói.

Com DesignOps não é diferente. Tudo o que escrevi aqui está longe de ser um trabalho feito ou um trabalho em andamento, porque é um processo de redescoberta constante, não tem fim. Confesso até que fiquei receosa de escrever um post sobre algo que não está (mesmo!) escrito em pedra. Daqui seis meses eu posso escrever outro post falando sobre o quanto é importante termos profissionais especialistas em determinada disciplina, porque as coisas mudam.

Precisamos nos ajustar e o tempo é curto. São trimestres. Um ano tem apenas quatro desses blocos de tempo. Louco, né? Pensar que a gente mal piscou e já tem panetone na prateleira do mercado! Mas é nessa loucura do tempo que vem o ato de refletir e desenhar possibilidades de futuro. Porque mal saiu o panetone da prateleira e já entrou a colomba pascoal, e você ficou parado no tempo.

É nesse movimento de ação-reflexão-ação (sou fã de Paulo Freire, e esse termo é todo dele) que alguns questionamentos vêm à tona: Será que design system faz mais sentido em um guarda-chuva de engenharia ou produto? Será que UX writing é uma especialidade que faz sentido dentro dos squads? Como escalar uma nova disciplina?

Todas essas perguntas podem soar polêmicas (e entrar em conflito com tudo o que eu disse até agora), mas elas precisam ser feitas. Um dos piores erros em gestão é estacionar e parar de refletir sobre a ação. Significa achar que se sabe tudo, que existe uma resposta certa para tudo e, o pior, parar de aprender e evoluir.

As ilustrações deste post são de autoria da rainha, contadora de histórias, designer e ilustradora Duds Saldanha.