Gestão em design
Um pouco sobre minha experiência em lideraça e gestão de times de Designers
Lideraça no BanQi
Após muitos anos atuando como Product Designer, assumir uma posição de liderança exigiu a aquisição de novas habilidades que, embora estejam presentes no cotidiano de um designer sênior, não eram tarefas tão claras ou bem definidas. Liderar uma equipe de designers exige um olhar mais analítico e estratégico sobre o produto, para que seja possível guiar o time de forma ágil e eficiente rumo aos objetivos estabelecidos.
Para isso, é necessário desenvolver competências como: comunicação assertiva e não violenta, saber ouvir ativamente, fornecer feedbacks construtivos, acompanhar o progresso da equipe, ensinar, defender as ideias, fornecer as informações necessárias e sempre explicar o propósito por trás de cada decisão e ação tomada.
A seguir, compartilho um pouco da minha experiência ao liderar meu time na empresa Banqi, os desafios enfrentados, as metodologias adotadas e os rituais que moldaram nossa jornada.
Estrutura
Na empresa o Capítulo de de Design estava na área de Produto. Existia até a discussão em um futuro Designer ser um pilar ao lado de Produto e Tecnologia.
Dessa maneira o time e Design era estruturado como no organograma abaixo:
No papel de Product Design Lead eu atuava liderando 4 (quatro) PDs distribuídos em 2 (duas) Tribos: Jornads do Usuário e Serviços Financeiros. Sendo liderado por um Gerende de Design que respondia diretamente ao CPO.
Processos
Ser Lead requer aprender e estudar todos os processos, ferramentas e metodologias da empresa para que possamos orientar da forma mais clara os liderados como a empresa pede que o trabalho seja realizado. Isso varia de empresa para empresa. Ferramentas mudam de acordo com o local onde trabalha e muitas vezes, dentro do atual local. O Lead precisa estar à frente dessas mudanças e saber dar suporte a sua equipe.
No processo de orientar o time de Design passávamos por algumas etapas que quase sempre seguia a seguinte ordem:
Outras Responsabilidades:
Além de trabalhar seguindo todas as metodologias listadas, eu como líderassumia as tarefas burocráticas do dia a dia.
-
Acompanhamento e correção de marcação de ponto dos designers
-
Controle de Férias do time
-
Organização e lembrete de escala de apresentação do onboarding da empresa
-
Acompanhamento de Plano de Voo e promoções
-
Entrevista para novas vagas
-
Compilar dados e oportunidades para o time
-
Mediador de situações comportamentais
-
Facilitador de impedimentos
-
Cobrir Férias
-
Reportar andamento dos trabalho para Gerência em Design
-
Apoio ao time de Marketing
-
Estreitar comunicação de Design com o time de CX e suporte
Papel como PM/designer na CASSSI
Uma outra experiência que tive além do papel de um Product Designer foi a necessidade de assumir responsabilidades de um PO/PM na CASSI.
Nela a estrutura de desenvolvimento trabalha diretamente com as demandas das áreas enviadas para o time de tecnologia, não existindo nenhum time de produto responsável pela priorização e controle dessas demandas.
Por isso o time de UX assume, na maioria das vezes responsabilidades de um Product Manager para conseguir entender as necessidades da área e transformar tudo isso em backlog para o time desenvolver.
Aqui eu separei um exemplo de uma demanda que era bem recorrente no nosso dia a dia de trabalho.
-
Recebíamos as demandas em uma documentação técnica separada em tópicos geralmente em arquivo DOC.
-
Líamos todo o documento e tentávamos entender o problema levado pelo Stakeholder. Em alguns desses casos a gente precisava fazer um alinhamento para decupar juntos a real necessidade daquele pedido. Um dos meus papéis como Designer era entender que algumas funcionalidades pedidas não eram exatamente o que eles precisavam.
-
Depois de entender todas as dores nós voltávamos para o Figjam e tentávamos transformar a documentação em histórias.
-
Alguns projetos eram desenvolvidos por uma dupla de Designers e neste caso eu ficava encarregado de escrever as histórias mais diretas e facilitadas para o designer Pleno puxar na sua lista de backlog.
Separando histórias
Além de transcrever o documentos em User stories era necessário identificar os sistemas que aquelas histórias faziam parte e se ja existia algum legado daquelas tela.
A imagem mostra um exemplo de uma tabela que usei para separar as histórias por sistemas e se era um serviço novo ou que já existia.
Também indicávamos os pedidos da documentação que não eram necessários interfaces e sim apenas orientação para o time de Desenvolvimento.
Épicos, Histórias e features
Direto no Figjam já montávamos quadros com post its dos épicos com cores que representam os sistemas que aquelas demandas estariam atendendo.
Épicos
Desmembrávamos em uma tabela os épicos em suas histórias. E suas histórias em suas Features. Fatiando assim as tarefas para alimentar tanto o nosso board de design quanto posteriormente o do time desenvolvimento.
Checklist
Também mantínhamos no documento de consulta do Figjam um Checklis dos nossos processos de design para garantir que estaríamos passando por todas as validações e DODs das nossas entregas.
