Validando a sua Proposta de Valor

É hora de testar com os usuários! (E coletar feedbacks)

A imagem mostra quatro quadrantes, sendo dois deles de fundo azul com o texto em branco “re:Bank —Teste com Usuários” e os outros dois uma composição de resultados quantitativos e qualitativos dos testes.

Introdução

Este artigo faz parte de um conjunto que estou publicando sobre o projeto re:Bank. Se você chegou aqui de paraquedas, recomendo que leia esses quatro artigos antes, na ordem:

Briefing de Negócios

re:Bank — A Pesquisa

O que vem depois da Pesquisa?

Tangibilizando a solução

Validando a sua Proposta de Valor

Estamos em nossas últimas etapas do projeto. Agora que já temos as interfaces em alta fidelidade do produto — que nada mais é do que um meio pelo qual entregamos aos clientes a nossa proposta de valor — vamos construir um protótipo para que possamos validá-la. Na abordagem de projeto que estamos adotando aqui — e explicada detalhadamente, passo a passo em outro artigo — estamos na etapa de Entregar.

A imagem mostra a abordagem do Duplo Diamante com a etapa de Entregar destacada em azul.

Nessa etapa vamos construir um protótipo de alta fidelidade e depois poremos nas mãos dos usuários para que testem e coletarmos feedbacks sobre o protótipo para que possamos preencher gaps e melhorá-lo.

Neste artigo, utilizarei o projeto re:Bank para ilustrar a forma como tudo isso é feito.

Construindo o Protótipo de Alta Fidelidade

Utilizei a ferramenta Figma tanto para projetar as interfaces em alta fidelidade quanto para construir o protótipo.

A imagem mostra um print de tela da interface gráfica do Figma contendo as telas em alta fidelidade. Além disso, mostra o modo Prototype do Figma onde podemos ver as ligações entre as telas.

Nesse momento, não tem muito segredo. Basta conectarmos as telas com as transições que mais se adéquam ao caso a caso.

A dica aqui é: conecte as telas incluindo transições entre elas que façam sentido ao tipo de ação que o usuário fará no protótipo, tentando espelhar o que será feito no produto real.

Abaixo, você conseguirá interagir com o protótipo que foi construído. Caso tenha ficado cortado, dentro do frame abaixo, vá em Options > Fit — Scale Down to Fit ou clique para entrar em modo tela cheia (no canto superior direito).

Protótipo de Alta Fidelidade.

Testes com Usuários

Agora é a hora de testar o seu produto com os usuários e coletar feedbacks. Contudo, não basta apenas "jogarmos" o protótipo nas mãos deles e dizer "testa aí". Precisamos, antes:

• Definir o que queremos testar e por quê.
• Uma vez definido, elaborar um roteiro de testes contendo as Tarefas que os usuários deverão completar no protótipo.
• Definir, após cada tarefa completada, perguntas a serem feitas aos usuários com o objetivo de capturar dados quantitativos e qualitativos.

Para este projeto, escolhi a ferramenta de testes remoto Maze.design porque é uma ferramenta simples para teste de usuário e podemos extrair dados quantitativos e qualitativos dela. Testei o protótipo com 10 usuários. Abaixo, alguns resultados dos testes.

A imagem mostra um print dos resultados da tarefa "Cadastrar para uma nova conta bancária". 60% dos usuários completaram com sucesso direto, ou seja, seguiram o fluxo esperado, enquanto 40% seguiram um fluxo indireto, ou seja, fizeram caminhos diferentes do esperado e 0% desistiram da tarefa.

A imagem mostra um print com uma pergunta quantitativa sobre a tarefa "Cadastrar para uma nova conta bancária”. A pergunta foi: "O quão claras estavam as instruções nas telas?". Para medir, foi utilizada uma escala de 1 (Não claras, inútil) a 5 (Claras, útil). 10% dos usuários deram nota 3 e 90% deram nota 5.

A imagem mostra um print dos resultados da tarefa “Encontre as informações do seu cartão e veja os detalhes da sua fatura”. 30% dos usuários completaram com sucesso direto, ou seja, seguiram o fluxo esperado, enquanto 70% seguiram um fluxo indireto, ou seja, fizeram caminhos diferentes do esperado e 0% desistiram da tarefa.

A imagem mostra um print com uma pergunta qualitativa: “O que você acha do design geral do extrato da conta?”

A imagem mostra um print com uma pergunta quantitativa: “O quão clara estavam as instruções nas telas?”. Para medir, foi utilizada uma escala de 1 (Pobre, ruim) a 5 (Ótima). 20% dos usuários deram nota 3 e 10% deram nota 4 e 70% deram nota 5.

Principais Aprendizados dos Testes com Usuários

• Ao solicitar aos usuários que visualizassem suas receitas e despesas, o uso dos termos "account statement" para "extrato da conta" e "card statement" para "fatura do cartão" confundiu 33,3% dos usuários e eles desistiram. Apenas 22,2% conseguiram entender e tiveram sucesso direto (completaram o caminho esperado da tarefa), enquanto 44,4% tiveram sucesso indireto (completaram a tarefa por caminhos inesperados).
• O problema acima também teve impacto quando os usuários foram solicitados a ver os detalhes das faturas do cartão. 30% tiveram sucesso direto, enquanto 70% tiveram sucesso indireto.

Iterando no Produto

Como observamos nos aprendizados acima, há melhorias a serem feitas no protótipo. Assim, voltando ao diagrama da nossa abordagem, precisamos voltar para a etapa de Elaborar e pensar em como aplicar os aprendizados.

A imagem mostra a abordagem do Duplo Diamante com as etapas de Elaborar e Entregar destacadas em azul.

Dessa forma, fiz alguns ajustes na interface.

Alterei o texto de "View Statement" para "View Income and Expenses" para deixar mais claro ao usuário quando ele quiser cosultar o extrato da conta (receitas e despesas). Além disso, incluí um ícone padrão (chevron down) que é comumente utilizado e que indica que quando o usuário clicar, verá mais informações. Além disso, explicitei essa consulta por meio de uma opção clicável para usuários mais iniciantes.

A imagem mostra mockups de alta fidelidade da "Home" do app, o antes e o depois de ter aplicado o aprendizado citado anteriormente.

Alterei o texto de “View Statement” para “View Invoice”, pois o termo "Invoice" é mais conhecido e utilizado em outras plataformas e facilmente reconhecível pelos usuários.

A imagem mostra mockups de alta fidelidade da tela "Your credit card" do app, o antes e o depois de ter aplicado o aprendizado citado anteriormente.

Aprendizados

A imagem mostra a abordagem do Duplo Diamante com a etapa de poc + aprendizados destacada em azul.

Agora que ajustamos o nosso protótipo, poderíamos testá-lo novamente com os usuários, coletar feedbacks e analisar se realmente houve uma melhoria ou não. Isso vai depender de quanto tempo temos para iterar no protótipo, pois impacta no cronograma e no orçamento do projeto.

Nesse projeto, não testei novamente com usuários, pois o cronograma do projeto seria afetado e o orçamento também (para 10 usuários, foi feito um investimento de R$160).

E é isso! Chegamos ao fim de um projeto feito de ponta a ponta passando por todas etapas da abordagem do Design Thinking — explicada detalhadamente, passo a passo em outro artigo.

Espero que essa série de artigos tenha contribuído para com o seu aprendizado e tenha trazido informações ricas e que você poderá utilizá-las em seu próximo projeto! 😉

Se você curtiu tanto este artigo quanto essa série, por favor, clique e segure quase que infinitamente no botão de "palmas 👏" do Medium! Dessa forma, a plataforma saberá que é um conteúdo relevante e mostrará para mais pessoas!

Muito obrigado e até mais! 🥳