Simplificar ajuda (sempre!)
Vida de UX não é fácil. Ainda mais quando você trabalha com agile e está há quatro semanas travado no mesmo problema: uma tela com inúmeras variáveis onde a regra de negócio, por si só, é confusa. Como deixar claro para o usuário (através da interface) o que está acontecendo, se nós que criamos as regras temos dificuldade para explicá-las?
A primeira brilhante ideia foi a mais óbvia: vamos alterar as regras. Vamos enxugar as variáveis e simplificar a vida. Corremos atrás das pessoas-chave para que isso pudesse acontecer e descobrimos que o buraco era um pouco mais embaixo. Essa era, sem dúvida, uma grande ideia mas era também muito custosa e demorada. Não tínhamos tempo. Rodaríamos essa solução em paralelo, mas precisávamos de uma interface que facilitasse o entendimento pra ontem.
Foi aí que começaram as quatro semanas de trabalho incansável. Pesquisa, estudo, dinâmicas, cowork, prototipação. Por fim, testes de usabilidade que acabavam invalidando todo o processo. E nós começamos de novo. E de novo. E de novo.
Sexta-feira da quarta semana. Final de tarde, mais um protótipo invalidado. Estávamos atrasando o cronograma da ação e correndo o risco de não colher os resultados no curto prazo que precisávamos. Montamos um cronograma para realizar em 2,5 dias o trabalho de toda uma semana.
E sabe o que nos fez ganhar tanto tempo, sem perder a qualidade? O famoso paper prototype. Sim, apenas sentar e desenhar no papel. Estávamos perdendo bastante tempo e colocando muito esforço em protótipos navegáveis com grande fidelidade e, com isso, atrasando a coleta de feedbacks.
A técnica foi aplicada em três etapas durante nosso cronograma de mini-sprint. A primeira etapa foi uma espécie de geração de alternativas, levando em consideração os principais problemas que estávamos propondo resolver e também as soluções que já haviam sido invalidadas.
Todas as possibilidades encontradas foram apresentadas às principais pessoas envolvidas no processo (PO, UXs e alguns devs) e, após confrontar com os problemas a serem resolvidos, muitas opções foram excluídas. Esse processo durou, em média, duas horas. Dessa dinâmica, também saíram insights que uniam algumas das soluções apresentadas. Na segunda aplicação do paper prototype, trabalhamos justamente com o merge das ideias.
Desta vez, a solução foi apresentada para o time que trabalharia no processo e para UXs de outros times. Nosso protótipo estava em uma fase bem adiantada e o melhor, não havíamos gasto nem um dia nele ainda. Novas pequenas melhorias foram sugeridas e desenhadas na hora seguinte, no que seria a última aplicação da técnica neste projeto.
Este protótipo foi apresentado para as mesmas pessoas que acompanharam o processo e validado internamente, com o time de Sales e Customer Success. Sucesso!
Em resumo, a técnica nos fez adiantar possíveis erros e trouxe muita agilidade para pequenas correções e novas tentativas. Quando finalmente chegou o momento de fazer o protótipo navegável e realizar testes externos, todos estavam mais confiantes da solução encontrada e o tempo gasto no processo reduziu (muito)!
