Os desafios e aprendizados em estabelecer um processo de Design Handoff no PAN
Com certeza em algum momento da sua carreira você precisou, ou se envolveu em algum tipo de processo em prol de otimizar tempo, padronizar e melhorar eficiência na sua entrega. Bom, aqui no Banco PAN não é diferente… Temos nossos processos de pesquisa, design e desenvolvimento em cada iniciativa.
Quando entrei no PAN em 2019 percebi que havia um processo de design muito bem estruturado, principalmente no time de pesquisa. Mas como tudo está em constante evolução, esse processo também passou por algumas melhorias ao logo do caminho. Principalmente quando o Design Ops criou um framework para os Products Designers, onde passamos a dar visibilidade do nosso processo de design na organização dos arquivos no Figma em cada produto.
Esse framework garantiu ao time maior padronização na condução de todas as iniciativas, evitando pular passos considerados importantes dentro das etapas de ideação, prototipação e validação. A partir disso, todos os Stakeholders podiam consumir, de forma simples e padronizada os arquivos do time de design.
Esses arquivos são separados no Figma em projetos chamados:
Discovery – Melhorias do funil e de usabilidade, propostas visuais e outros. Essas iniciativas estão em fase de concepção e em validação.
Delivery – Iniciativas validadas com usuários e pelas áreas necessárias. Essas iniciativas estão prontas para serem implementadas via teste AB ou entrar na fila de desenvolvimento da Squad.
Para as iniciativas que estavam em Discovery, nosso processo foi atualizado em conjunto com o novo padrão de organização e teve um ótimo engajamento entre os PDs do time. Pra facilitar ainda mais, foi criado um arquivo template para o Figma com todas as etapas do processo. Cada página do arquivo era uma etapa do microprocesso dos Products Designers.
O desafio em Delivery
Com o padrão e o processo definido para os arquivos das iniciativas em Discovery, a gente ainda enfrentava um problema em uma das partes mais cruciais projeto, o momento que os desenvolvedores iriam repassar nossas ideias para o código. Desde minha entrada no PAN, tivemos diversas formas de passar a iniciativa em Discovery para Delivery e por não ter um padrão, acabaram surgindo situações como:
- Cada Squad tinha um modelo de handoff diferente;
- Dificuldade em visualizar todos fluxos, cenários de uso e cenários alternativos;
- Inconsistência visual entre protótipo e produto final;
- Falha na comunicação entre Dev e Designer;
- Má elaboração ou falta de informações na documentação
A partir daí vimos que existia a necessidade de se estabelecer um padrão para nossos entregáveis, assim como fizemos no framework para etapa de discovery. Nos últimos meses, passamos por alguns desafios ao tentar criar esse novo modelo de handoff e resolvi escrever para contar sobre os aprendizados.
Entendendo o cenário atual
O primeiro passo foi sentar junto com o time de Design Ops, os Products Designers, os Desenvolvedores e PO's para entender como as squads estavam consumindo os handoffs, o que eles achavam do modelo atual, quais eram as dores e o que eles mais sentiam falta.
Fazer esse posicionamento e saber qual era a maior dificuldade em compreender a documentação atual, mesmo com os designers investindo grande parte do tempo em tentar deixar claro quais eram os fluxos e seus cenários foi o ponto chave pra construção da nova documentação. Abaixo está o exemplo de um fluxo utilizando o plugin Auto Flow do Figma.
Estruturando a nova documentação
Após as conversas com os Stakeholders, vimos que um bom handoff vai além dos fluxos, dos cenários, dos elementos de tela que geram ações e das novas telas que o usuário deve ser direcionado. Existe uma questão de compreensão e leitura das informações do documento. Tínhamos em mãos um grande desafio: Como deixar nosso handoff com uma usabilidade melhor?
Por conta disso, resolvemos dividir a entrega em 3 grupos, para que pudéssemos destacar melhor os pontos chaves de cada aspecto do handoff, são eles:
- Componentes e composição;
- Fluxos e casos;
- Interações e transições.
Componentes e composições
Mesmo com o Mahoe, nosso Design System, decidimos detalhar e separar quais os componentes e composições os Dev's vão visualizar nos cenários de uso desse handoff. Repassar todos esses elementos ajudou o Desenvolvedor a identificar se já existia uma funcionalidade pronta em outra iniciativa ou se tratava de alguma funcionalidade nova, sem contar que preveniu a inconsistência visual entre protótipo e produto final. Agora os desenvolvedores tinham detalhes da anatomia geral dos componentes e composições que seriam necessários para o desenvolvimento dos futuros fluxos e cenários.
Fluxos, use case, main case e os edge cases
Uma coisa que eu tinha percebido antes mesmo de iniciar essa nova documentação, era a dificuldade em ligar os fluxos e cenários de uso com a história que o PO escrevia. Os desenvolvedores tinham três lugares para consumir informações do que precisava ser desenvolvido, o Jira, o próprio Figma e em alguns casos ainda havia o protótipo navegável feito no ProtoPie. Durante a etapa de pesquisa ficou claro que o Figma era sua principal fonte de consulta, sempre deixando ele aberto na maior parte do desenvolvimento.
Outro ponto de dor descoberto foram os casos onde tínhamos fluxos gigantes. Ligando os pontos de navegação usando o plugin Auto Flow, exemplificando os caminhos "Se SIM" ou "Se NÃO" e colocando a seguir o próximo fluxo. Isso não era nada usual, eram tantas opções que alguns desenvolvedores se perdiam entre todos aqueles caminhos e setinhas. Até eu mesmo tinha dificuldades em visualizar e construir todos o cenários de uso.
Para estruturar a documentação dos fluxos e cenários, o primeiro passo foi quebrar em grupos todos cenários de uso, discutido previamente com os QAs afim de entender as quebras do BDD (Behavior driven development). Dentro de cada Caso de uso fizemos a separação em boards do cenário principal, dos cenários alternativos e dos estados que o fluxo poderia ter, por exemplo uma página de Empty State ou sem internet.
Exemplo dos boards com os cenários de uso e fluxos:
Cada cenário tem sua própria descrição pra ajudar a identificar de qual fluxo estamos falando. As interfaces estáticas desse cenário ficam logo abaixo da descrição, exemplificando qual é o fluxo daquele caso e onde deve ser a ação para ir para próxima tela. Colocamos os links do Jira e do ProtoPie para que o desenvolvedor possa consultar a história daquele fluxo ou visualizar o protótipo navegável.
Interações e transições
Talvez seja um dos itens mais importantes dessa documentação, pelo fato que na maioria das vezes as microinterações eram esquecidas no momento de desenvolvimento, alguns Devs se arriscavam em fazer essas interações por conta própria e por isso não havia consistência entre o que foi definido no Design System e o produto final. De modo geral, as animações eram idealizadas pelos Designers, escritas pelos POs, mas não eram implementadas por falta de informação e comunicação.
Por isso, criamos um board focado nas interações e transições que estavam presentes na iniciativa. Nesse momento, os designers especificam as boas práticas de cada interação.
Por exemplo:
- O gatilho para iniciar a microinteração;
- O que pode e o que não pode acontecer quando uma microinteração é acionada;
- Qual o feedback para que o usuário perceba o que está acontecendo enquanto uma microinteração esta ativa
Junto a essas informações podemos incluir um trecho de código com a ação necessária. Também adicionamos os links com os exemplos de cada microinteração e dos arquivos Lottie.json caso for necessário implementar para animação acontecer.
Testando com nosso usuário
Após estruturar a documentação, convidamos uma squad para participar do piloto utilizando esse novo modelo de handoff. De cara, comentaram que estava mais fácil visualizar as informações pela diagramação desse arquivo. Ao final da sprint teste, fizemos uma retrospectiva com o time de desenvolvimento e o feedback foi bastante positivo. Eles relataram, que a nova documentação reduziu o tempo de desenvolvimento por entender de forma clara todos os fluxos e cenários. Para os QAs ficou mais fácil repassar todos os cenários de testes de acordo com as quebras do BDD. Mas como se trata de um piloto, também fizeram algumas críticas para melhoria que nós analisamos e acrescentamos no nosso backlog de evolução do handoff.
Tenha em mente que esse processo é uma ferramenta para os designers e os desenvolvedores se aproximarem ainda mais. Apesar de trabalharem bem perto uns dos outros, ambos possuem habilidades e backgrounds diferentes. Além disso, é importante garantir que as ideias tenham ficado claras, não podemos esperar que todos entendam o que queremos dizer logo de primeira.
Próximos passos
Como todo produto, nosso plano é escalar esse modelo para mais squads dentro do PAN, mas para isso acontecer precisamos evoluir alguns pontos de atenção. A ideia é que seja um framework, assim como o processo do Product Designer.
E o que precisa ser feito para escalar?
- Em primeiro lugar, para fazer essa documentação a iniciativa deve estar muito bem validada e refinada, para não trocarmos o pneu com o carro andando. E a gente sabe que no dia a dia, nem sempre é assim.
- Aplicar as melhorias e validar novamente essa documentação. Pela ordem de prioridade de algumas iniciativas, pausamos a evolução do handoff. Mesmo sendo aplicado em nossas iniciativas, essa nova documentação ainda precisa de algumas melhorias.
- Nosso Design System está passando por uma atualização de componentes e com isso os nossos princípios de design estão sendo revisitados.
Por fim, sabemos que para chegar no modelo ideal e estabelecer um padrão para nosso Design Handoff será necessário alguns refinamentos. E apesar de parecer uma etapa simples, deve ser feito de forma colaborativa para que possamos ter guardiões e promotores desse processo.
Obrigado por ter chegado até aqui nesse artigo
O que achou da forma que trabalhamos aqui no PAN? Você trabalha de forma parecida? Tem alguma dúvida? Deixe um comentário e vamos conversar! Caso tenha gostado, deixe suas 👏 pois nos motiva a escrever mais por aqui, em nome do PAN Design.
Se tiver interesse temos outros artigos contando um pouco do nosso dia a dia de trabalho aqui no Banco PAN.
