Um framework de UX para aplicar Design Review com o time de desenvolvimento
Viemos compartilhar nossa experiência com Design Review, cerimônia que visa garantir mais qualidade de entrega do produto do ponto de vista de experiência do usuário, após muita prática, aprendizados e evoluções.
Um pouco de contexto
Trabalhar em uma grande empresa que atua em produtos digitais, como o PagSeguro, é lidar com uma série de fatores e desafios.
O tempo de lançamento de produtos é rápido e dinâmico, onde temos releases (lançamento de novas versões) do aplicativo a cada 15 dias. Lidamos com cenário em que demandas menores podem ser disponibilizadas em semanas e demandas maiores em poucos meses.
Temos um Design System, chamado Colmeia, bem estruturado e organizado, que visa garantir a governança dos padrões em todo ecossistema do aplicativo e também de outras soluções da empresa.
O processo de design é permeado por algumas cerimônias como Fórum de Design, Comitê de Design e outras iniciativas que também visam garantir a manutenção e evolução dos padrões.
Como designers, temos opções de trabalhar solo como Product Designer ou em dupla com UX Designer e UI Designer. O designer solo ou a dupla de design atua em múltiplos times e demandas ao mesmo tempo.
Há 2 anos atrás, nós éramos novos na empresa, tudo era novidade, Design System, processos… Pensamos: e agora?
Foi quando sentimos a necessidade de ter uma cerimônia ou alguma forma de verificar se o que estava sendo projetado de experiência era o que de fato estava sendo entregue para o usuário. Será que condizia com o que tinha sido projetado, passado no Fórum de Design, com padrões de Design System?
Foi assim que surgiu a primeira iniciativa de Design Review.
As primeiras iniciativas surgiram de maneira despretensiosa, sugerindo para o time “Olha gente, uma semana antes de entregar em produção, tem como darmos uma olhada juntos? Ver se está tudo de acordo?”. Na época, os times receberam bem e abraçaram a iniciativa. Nesse momento, não tínhamos nenhum processo para isso e era feito de maneira informal.
Atuando em dupla, passamos a dividir papéis e o olhar. Após dezenas de sessões de Design Review juntos, pudemos evoluir essa cerimônia e esse processo aprendendo com nossos erros.
Conceitos #teoria
A Design Review é uma cerimônia dentro do ciclo de desenvolvimento do produto onde designers, desenvolvedores e outros envolvidos verificam o que será entregue ao usuário no ponto de vista de experiência.
Dentro do processo de design, a Design Review fica na última etapa de Distribuição, quando já foi entregue pelo design, já foi desenvolvido, mas ainda não foi para as mãos do usuário.
E por que aplicar Design Review?
- Para garantir a qualidade de entrega do produto: garantindo que o que é entregue pelo desenvolvimento condiz com o que foi projetado pelo design.
- Para alinhar as expectativas de todos os envolvidos na entrega: é o momento que todos sabem o que de fato será entregue para o usuário como experiência.
- Para descobrir e tomar ações sobre melhorias necessárias: muitas vezes na Design Review descobrimos, por exemplo, que um componente não está de acordo com Design System, que precisa gerar uma atualização, então serve também para dar essa manutenção para o processo.
- É uma oportunidade de tirar dúvidas: às vezes uma coisa ou outra não fica clara, esse é o momento de esclarecer e corrigir o curso se necessário.
Como nós aplicamos #prática
Quem participa?
Dentro do nosso cenário, é obrigatória a presença de PO (Product Owner), AM (Agile Master), um dev (Developer) front-end de cada frente (Android, iOS e/ou Web), um dev (Developer) back-end e um QA (Quality Analist), além dos designers, é claro! Se todos do time quiserem participar não há problema, é até melhor pois todos participam da validação e ficam alinhados.
A presença obrigatória vai depender do contexto e de como é estruturado o time na sua empresa. Se no seu time não tem todos esses papéis ou tem nomenclaturas diferentes, não há problema. O importante é ter um representante de cada frente.
Quando fazer?
Antes de entregar em produção (óbvio né?).
Legal, mas quanto tempo antes? 🤔
Recomendamos, no mínimo, 2 semanas antes, para que dê tempo de fazer a Design Review, efetuar os ajustes e fazer nova Design Review de conferência.
Em nossa experiência, observamos que dependendo do tamanho da demanda e sinergia do time, é recomendável fazer com mais antecedência para ter mais tempo para efetuar os ajustes.
Se a entrega final for grande, planeje a Design Review de entregas parciais, pois assim fica menos cansativa e longa a Design Review final. Esse foi um aprendizado que tivemos após fazermos uma Design Review de 3 horas para uma demanda complexa, algo que foi muito cansativo para nós e para o time.
Quantas sessões é preciso fazer?
Depende. Se você fizer uma Design Review e não tiver nada para ajustar (raro, nunca aconteceu conosco!), não precisa de mais nenhuma sessão.
Se tiverem pontos de ajuste, será necessário mais uma Design Review para conferir os ajustes. Pode ser que na conferência, descubram outros pontos para ajustar que passaram despercebidos. O intuito é fazer as Design Reviews até que não tenha mais nenhum ponto de ajuste.
Já tivemos casos em que 2 Design Reviews bastaram e outros casos em que foram necessárias 5 sessões. Nesse caso das 5 sessões, na primeira começamos com 55 ajustes e fomos diminuindo até zerar. Imagina se não tivéssemos feito?
Como funciona?
O Dev front ou QA (se você tiver esse papel no time) apresenta o fluxo em cada plataforma, uma de cada vez. Passamos pelas telas de fluxo feliz e também pelas telas de exceções. O QA ajuda muito nesse momento, pois tem esses cenários mapeados. Se você não tiver esse papel no time, significa que não será possível testar essas coisas na Design Review? Não necessariamente. A diferença é que o UX Designer terá que puxar mais esses cenários de condicionais e casos de uso.
Em cada tela, há uma parada para os designers analisarem, questionarem e tomarem nota dos ajustes. É aquele famoso momento de silêncio. É importante tomar nota, além dos ajustes, das decisões também. Por exemplo: identificamos que um componente que o time consome não está adequado ao Design System e o time não tem como alterá-lo. O plano de ação será prosseguirmos com componente dessa maneira e entrarmos em contato com responsáveis para adequação.
Ao lado da aplicação funcionando, é ideal manter o protótipo aberto para tirar possíveis dúvidas que venham a surgir. Por exemplo: estamos em dúvida se o espaçamento é 8 ou 16. Tiramos a dúvida no protótipo e depois conferimos como está no emulador. Tem coisas que a olho nu já sabemos que não está correto, mas se for algo muito sutil, olhamos no código na hora pra ter certeza.
Da segunda Design Review em diante, é necessário conferir se os pontos de ajuste anotados anteriormente foram resolvidos e anotar se há novas inconsistências. No começo, nos organizávamos nas notas do computador mesmo. Atualmente, estamos nos organizando no Notion, onde criamos a página do projeto e identificamos cada sessão. A ferramenta de organização pode ser qualquer uma de acordo com sua realidade, o importante é manter esse histórico de anotações e débitos de experiência.
O que os designers devem analisar?
Como trabalhamos em pares, UX e UI Designer, nosso foco na análise é distinta. No entanto, nada impede de olharmos e apontarmos também para o lado do outro caso notemos algo.
O UX Designer foca sua análise na interação da interface. Analisa fluxos, interações, comportamentos, mensagens, tratativas, fluxos de erros, cenários personalizados, etc. O UI Designer foca sua análise nos componentes de interface e é necessário nesse momento ser pixel perfect. Analisa cores, pesos, tamanhos de fontes, espaçamentos, alinhamentos de componentes, etc. Se você é um Product Designer, deve olhar para ambos.
À primeira vista, a Design Review parece uma cerimônia que carrega um sentimento de culpa, mas o intuito não é apontar culpados. O importante da Design Review é todos estarem alinhados no mesmo objetivo para garantir a entrega do produto com qualidade. Por isso, na hora de analisar, é importante que todos tenham sentimento de dono do produto. Encontrou um erro? Não importa quem errou, porque errou, o importante é: vamos entender porque está desse jeito, como é que consertamos e vamos consertar.
A Design Review roda muito bem quando o sentimento de dono do produto permeia todos que estão envolvidos na cerimônia. O problema de um é o problema de todos. Toda a experiência é responsabilidade de todo mundo.
Para evitar esse sentimento de culpa, como apontar é tão importante quanto o que apontar. Na hora de falar o que está inconsistente, é importante trazer por que está inconsistente, justificando com referenciais. Por exemplo: está inconsistente porque o padrão do Design System é outro ou porque o comportamento que definimos é diferente baseado no teste de usabilidade que fizemos.
Trazer dessa forma é importante para que todos os envolvidos entendam porque estamos fazendo as coisas de uma maneira e não de outra, comprem a importância de fazer aquilo e para que não fique aquela sensação mandatória de que tem que fazer porque está sendo dito para fazer.
Após a Design Review
Após a Design Review, o time decide quanto tempo vai levar para realizar ajustes a partir de uma estimativa de como encaixar a demanda. O AM tem um papel importante nesse momento, pois ajuda time a pensar nesses pontos.
É importante nesse momento já definir a data da próxima Design Review, pois se sair da Design Review sem definição de data para próxima, pode acabar caindo no esquecimento.
Saindo da reunião, os designers ficam responsáveis por compartilhar os pontos de ajuste que foram anotados com o time. Atualmente, compartilhamos pelo Slack, nosso principal canal de comunicação com times e depois eles replicam para tarefas no Jira. Mais uma vez, a ferramenta pode ser qualquer uma de acordo com sua realidade, o importante é repassar o que foi anotado o quanto antes para que time tenha visibilidade e possa prosseguir com trabalho.
Conclusão
Há cerca de 2 anos temos aplicado Design Review com nossos times, já tendo aplicado em mais de 10 times e inúmeras demandas.
No ano passado, apresentamos para todo time de Design do PagSeguro (+80 designers!) e o modelo tem sido adotado por outros designers, não só da nossa vertical de Conta Digital, mas por outras verticais da empresa.
Trouxemos nesse artigo o resultado de nossos aprendizados com erros, acertos e evoluções que promovemos no framework a partir da nossa experiência.
O framework de Design Review abaixo é um compilado de tudo que falamos nesse artigo e um convite para que você aplique a Design Review no seu contexto e volte aqui para nos contar como foi sua experiência.
