Gestão visual de demandas para times de design (para líderes de design)

Um líder notável é aquele que possuí profundidade e visibilidade de todos os temas tocados pelo seu time. Para que isso seja possível sem sobrecarga, é preciso definir práticas que sejam capazes de dar autonomia mantendo alinhamento e visibilidade de todo o processo trabalho de cada liderado. O conceito de gestão visual é bastante antigo e foi consolidado com os métodos ágeis para organização de processos em times de engenharia do software sendo o método Kanban o mais popular. Sua utilização tem sido cada vez mais disseminada para outros contextos inclusive em times de design. Se você é líder de design e ainda não utiliza, está perdendo tempo e a oportunidade de construir com seu time um ambiente mais dinâmico e eficiente.

Montar um quadro de gestão visual que exponha as informações que você precisa e fomente um processo coerente com a necessidade do time não é algo simples, mas calma! Vem comigo que vou te ensinar como criar um quadro legalzudo agora mesmo.

Neste artigo você irá aprender sobre:

1- Como definir um processo de design
2- Como transformar o processo de design em um quadro Kanban
3- Como organizar tarefas em um quadro Kanban
4- Como obter informações sobre cada demanda
5- Como acompanhar a produtividade do seu time

1- Como definir um processo de design

Não é necessário inventar algo super novo, mas é importante que o processo seja coerente com a necessidade do time. Para definir comece mepeando o processo que as pessoas já utilizam e encontre suas similaridades, a partir disso defina steps que englobem diversas práticas e sejam capazes de comunicar se o processo está no começo, meio ou no fim.

Em uma visão bem simplista, começar com as etapas do double diamond pode ser um start interessante pois ele divide de maneira macro tudo o que um designer faz ao decorrer de uma demanda sendo investigação > solução > validação com usuários > entrega final, lembrando que em um quadro Kanban também sempre existirá uma fila de demandas para iniciar e outra das demandas finalizadas. Com isso, a gestão visual do seu time já ficaria como na imagem abaixo.

Na imagem, simulação de processo de design utilizando a funcionalidade de listas no Slack com os steps para iniciar > investigação > solução > ajustes > finalizadas, variando com cores marrom para a colunas das demandas a serem iniciadas, verde para as demandas finalizadas e roxo para os demais steps.

Se necessário podem ser inclusos steps que fomentem alguma prática ou exponham um momento de dependência externa. Por exemplo, algo que times de design pecam em não fazer ou fazem de maneira muito superficial é a documentação e isso é extremamente prejudicial pois detalhes acabam sendo esquecidos e dificultam tanto a contextualização quanto as orientações necessárias ao desenvolvimento, se esse for um problema no seu time pode valer a pena incluir uma coluna. Outra coisa que pode ser inclusa é um moento de review para garantir a qualidade e consistência da entrega, ou mesmo uma aprovação com stakeholders. Neste caso o processo poderia ter algo como investigação > solução > review interno> validação com usuários > aprovação com stakeholders > documentação.

Na imagem, simulação de processo de design utilizando a funcionalidade de listas no Slack com os steps para iniciar > investigação > solução > review > validação > aprovação > documentação > finalizadas, variando com cores marrom para a colunas das demandas a serem iniciadas, verde para as demandas finalizadas, azul para os steps de review e aprovação e roxo para os demais steps.

Pode até ser mais complexo ou mesmo mais simples, tudo irá depender da maturidade do time e empresa, a minha sugestão é que a primeira versão tenha os seguintes objetivos:

• Envangelizar processos e práticas;
• Dar visibilidade do tempo médio de entrega;
• Dar visibilidade de gargalos e bloqueios no processo.

Você deve concordar comigo que existem diversas maneiras de se "fazer design", processos que podem incluir mais explorações ou menos explorações, mais validações ou menos validações, tudo isso depende do risco que se pode tomar. Porém, não importa qual a abordagem, no fim todas elas vão passar pelas etapas que já desenhamos ali em cima, não concorda?! A diferença está nas práticas e entregavéis. Com isso, vão existir demandas que irão precisar de uma análise mais profunda sobre um problema ou oportunidade para então serem levantadas hipóteses de solução, mas também irão existir demandas que já serão provenientes de hipóteses, que precisarão de um processo mais focado na construção de solução ou ainda, se é algo mais provisório para ser testado e evoluído. Por isso, o segundo aspecto importante é identificar quais são as possíveis abordagens de design pois elas darão o direcionamento adequado a profundidade que o liderado deverá atuar e os alinhamentos necessários.

Com essa lógica poderiam ser criados os seguintes tipos de demandas:

(1) Investigação
Direciona para um processo focado em pesquisa, com o objetivo de reconhecer problemas e levantar oportunidades que irão direcionar o futuro de um produto ou serviço.

(2) Validação de hipótese
Direciona para um processo focado transformar uma ideia em solução para ser testada e muitas vezes evoluída a partir do aprendizado mensurado pelo uso dela. É possível tomar um risco maior. Normalmente um quick-win.

(3) Solução "final"
Direciona para um processo focado em remodelagem ou mesmo construção do zero de uma solução. Também será mensurado e evoluído em algum momento, mas neste momento o risco é maior, é preciso ter mais certeza do que vai ser implementado para que resolva de modo efetivo um determinado objetivo.

Tá fazendo sentido pra você?!

2- Como transformar o processo de design em um quadro Kanban

Pra começar é simples, as etapas viram colunas. Os diferentes tipos de demandas poderão ser identificados com cores e/ou tags. Caso o time ainda atenda projetos ou squads diferentes, elas também podem ser identificadas para facilitar a filtragem da informação, assim como colocar o nome ou a foto do responsável pela tarefa a qual deverá ser representada em um card.

Na imagem, simulação de um card para demanda utilizando a funcionalidade de listas no Slack. Este card possui background branco e está posicionado no step de investigação que recebe a cor roxa. Dentro do card está em negrito e letras maiores "nome da demanda", logo abaixo campo "prioridade" com três estrelas douradas, ao lado campo "squad" com nome check-out seguido do campo "processo" com o nome hipótese. Abaixo campo "responsável" com foto e nome. Na quarta e última linha o campo previsão de entrega com uma data qualquer.

Mas, Ju, onde eu coloco isso tudo?

Talvez sua empresa já utilize uma ferramenta de gestão visual como o Jira que é bem comum, mas você pode utilizar Trello, Miro, Figjam, Slack e até post-it colado na parede. O importante é não colocar a ferramenta como uma barreira.

3- Como organizar tarefas em um quadro Kanban

Agora a brincadeira vai ganhar forma e ficar mais divertida, eu prometo! 😜

Lembra que ali em cima comentei sobre as demandas serem representadas pro cards? Pois bem, uma demanda é caracterizada por um conjunto de artefatos gerados, ou seja, se uma demanda necessitar de entrevistas, benchmarking, geração de alternativas, prototipação, teste de usabilidade e sabe lá mais o que, o card será único pois o quadro Kanban tem o objetivo de dar visibilidade da etapa de design e o entregável em si sempre será o resultado final de tudo o que foi necessário para chegar em uma determinada conclusão. Se for necessário expor artefato por atefato, a dica é construir um check-list na descrição da demanda.

Na imagem, simulação do card de demanda descrito na imagem anterior sendo arrastado do step de investigação para o step de solução os quais recebem a cor roxa utilizando a funcionalidade de listas no Slack.

Com tudo o que definimos até agora você terá todos os elementos básicos exigidos pela metolodologia Kanban. Se a empresa de modo geral trabalhar com sprints de desenvolvimento o time de design pode refletir a mesma prática, eu particularmente não gosto e utilizo as sprints muito mais para ter referência de quando a demanda precisa estar pronta para o time de engenharia, sendo assim o fluxo de design passa a ser contínuo sem necessitar fechar pacotes de entrega.

Falei grego?!
Então meu caro líder, estude sobre métodos ágeis e gestão de roadmap.

Aliás, roadmap é outra ferramenta suuuuuuper importante de você organizar para que o time tenha visibilidade do que vem pela frente e para que você tenha visibildiade do capacity, consiga negociar prazos, alocaçõs e eventuais contratações.

4- Como obter informações sobre cada demanda

Tudo lindo, tudo maravilhoso, mas nem tanto…

Uma das maiores dores dos times é obter informações suficientes para iniciar uma demanda. Aposto que você já passou por situações em que seus liderados iniciaram um trabalho "no escuro" e tiveram muitas idas e vindas no escopo e até mesmo refações. Essa falta de informações prejudica inclusive a abardagem de design e consequentemente gera disperdícios de tempo. Para minimizar tal problema pode ser criado uma espécie de briefing, que na verdade as metodologias ágeis chamam de DoR (definition of ready) e um check-list de artefatos chamado de DoD (definition of done).

Abaixo você confere alguns tópicos que normalmente são preenchidos:

DoR (definition of ready)

• Mapeamento de stakeholders e validadores;
• Descrição da história (EU…COMO…QUERO…);
• Critérios de aceite;
• Regras de negócios;
• Expectativas e dores;
• Quais serão os usuários impactados;
• Hipóteses já levantadas;
• Entendimento das limitações técnicas;
• Revisitar/aplicar o Design System;
• Alinhamento expectativas e objetivos com a validação com o demandante;
• Alinhamento do perfil de usuários ou stakeholders que participação da validação, contatos, roteiro, etc.;
• Acesso ao ambiente de homologação.

DoD (definition of done)

• Pesquisa qualitativa e/ou quantitativa realizada;
• Benchmarking e/ou análise de interface atual;
• Mapeamento de hipóteses;
• Alinhamento técnico;
• Mapeamento de cenários;
• Mindmap de conteúdo e/ou estrutura;
• Propostas iniciais das telas e fluxos em baixa ou média fidelidade;
• Compilação das descobertas e montagem da defesa de design;
• Alinhamento técnico da aplicabilidade das ideias;
• Alinhamento com stakeholders sobre o caminho a ser seguido;
• Criação do protótipo em alta fidelidade;
• Revisão dos textos validando interpretação, gramática e tom de voz;
• Organizar o Handoff de UI.

É claro que são exemplos e, de novo, nem todos os tópicos servem para qualquer tipo de demanda, mas pode ter certeza de que ao impulsionar que tais informações sejam trazidas pelo time de produto previamente, o time de design será muito mais assertivo. Num universo imperfeito, que é a maioria das realidades, o próprio designer pode buscar essas informacões pró-ativamente em um kick-off de demanda.

5- Como acompanhar a produtividade do seu time

Já dizia o mestre das métricas "aquilo que não pode ser medido, não pode ser melhorado", logo o interesse de um líder além de manter a visibilidade, autonomia e alinhamento com seu time deve ser buscar a eficiência. Fique de olho nos seguintes aspectos:

• Tempo que um card leva para passar por todo o quadro Kanban desde o primeiro step até a conclusão, pois essa informação te dará uma noção do tempo médio que as demandas de cada caracterísitca levam para ser concluídas pelo seu time;
• Tempo que um card fica em cada step, pois essa informação te dará uma noção de qual step é o mais complexo e que seu time eventualmente tem mais desagios ou dificuldades;
• Quantidade de entregas realizadas em determinado período (por dia, semana ou mês);
• Tempo que um card fica parado em um step de aprovação pois essa informação te dará uma melhor noção do quanto a devolutiva dos stakeholders atrapalha o prazo de entrega;
• Quantidade de cards que são trabalhados paralelamente pois essa informação irá te auxiliar a entender se o seu time está sobrecarregado.

Ufa! Quanta coisa.

Legal, né?!
Mas e se eu te disser que ainda não é o ideal. Pois bem, nunca será.

Eu trabalho com esse tipo de prática a anos e uma coisa que percebi é que sempre pode ser melhor, porém o nível de complexidade pode aumentar a ponto de desengajar o time a utilizar. Aliás, a gestão visual só funciona bem se o time comprar a ideia e manter os cards atualizados diariamente no step correto e pensando nisso eu opto sempre pelo mais simples possível, mas que me permita ter a visibilidade miníma necessária.

Vale lembrar que o quadro Kanban proporciona uma visão linear de processo, mas você sabe bem que em design as coisas nem sempre são lineares… quantas e quantas vezes chegamos no momento da prototipação e percebemos que faltou um detalhe lá na pesquisa e precisamos voltar? Quantas e quantas vezes fizemos um teste de usabilidade e o resultado nos fez voltar para os ajustes? Não sofra, apenas defina muito bem que tipo de artefatos cada step pode contemplar e tudo bem se em validação tiver protótipo pra refinar.

Nesse artigo tem anos de experiência resumidos em dicas práticas, simples e em uma linguagem mais popular para que você possa sair da estaca zero com seu time. Espero que esse conteúdo te inspire, te dê ideias e base para adaptar à sua realidade. Se quiser conversar mais sobre o assunto, me procura no Linkedin.