É muito comum ouvir o termo “validação”, pois isso foi incorporado no cotidiano das startups e nos ciclos de conversa de designers. Porém, acho que você está fazendo isso errado. Duvida?
Academicamente falando, tudo precisa ser provado. Quando vamos para o mundo dos negócios, a coisa precisa ser validada. No frigir dos ovos, a lógica é a mesma porque é necessário reunir indícios de que o seu produto realmente atenderá ao objetivo e se resolve as “dores” dos usuários.
Existem diversos métodos para validar uma ideia, ou provar uma hipótese. Vão desde observação e registro, até questionário e imersão. O que não pode é sair criando coisas, botões e artefatos sem passar pelo processo de validação. Mas, infelizmente, as coisas acabam mal interpretadas e a “validação” fica apenas como um “achismo” da equipe.
Vamos as dicas de como não validar seu produto/serviço ou ideia
1 – Perguntar aos colegas ou parentes
Não estou dizendo aqui que os colegas e parentes não são válidos, mas se eles não são realmente o público-alvo do seu produto, nem adianta apresentar para seus 10.000 amigos do Facebook e postar no grupo da família. Os feedbacks vão ser diversos e inválidos.
Essa ideia de perguntar para os amigos é boa e incentivada em vários best sellers sobre startups, mas possui uma entrelinha ai: apresente/teste seu produto/serviço apenas com o público específico. Use mapa de personas para te ajudar a montar um perfil médio de quem é esse público.
2 – Só teste com alguém se o produto estiver pronto (ou o sistema/site funcionando)
Nesse momento você vai ter gasto muito esforço, tempo, dinheiro e paciência para desenvolver todas as funcionalidades do seu maravilhoso produto. Ai quando o usuário vai mexer nele, podem acontecer duas coisas: ou ele vai achar um monte de erros, ou não vai dizer nada.
Por quê? Simples… a primeira reação é porque você foi desenvolvendo sem perguntar se isso era relevante e está do jeito “certo” para o usuário. A outra reação, a de não dizer nada(ou quase nada de valioso), é porque as pessoas podem ter receio de apontar defeitos em algo que você levou muito tempo para fazer e está na cara que foi difícil.
Na dúvida, faça um rabisco em uma folha de papel (ou em um quadro) e mostre para um usuário. Você pode obter tantas informações sobre esse rabisco que nem imagina.
3 – Fazer uma pesquisa quantitativa sobre a interface, sem indicadores precisos
Essa é mais difícil de explicar para quem não é da área, mas vou tentar.
É muito comum encontrar pessoas que publicam uma pesquisa para que outros usuários deem sua opinião sobre o novo site, sistema ou aplicativo. O problema é que uma pesquisa assim pergunta, geralmente, se o usuário gostou de X ou Y tela… isso quando não fazem um NPS geral do sistema.
Lembre-se de que o usuário não entende de interface e vai te dar respostas inválidas. Aliás, se você estiver fazendo as perguntas erradas em qualquer questionário, suas respostas sempre vão ser ruins e a culpa não é do entrevistado.
Para se livrar disso, sempre defina KPIs para sua análise antes de fazer um questionário. Ex.: quero saber se os usuários encontram o botão “novo” e quantos saem da tela sem salvar. Daí você pode mostrar 3 ou 4 tipos de botão e analisar quais desses o usuário identifica como “Salvar”. Entendeu?
4 – Fazer roteiros de teste com passo a passo
Testes com usuários são feitos para testar o sistema, não o usuário. O que isso significa?
Se você quer testar seu sistema é necessário deixar com que o usuário descubra(ou não) a rota para a tarefa. Quando você diz um passo a passo para realizar uma tarefa no sistema, está invalidando o modelo mental do usuário e o teste.
Dê instruções mais gerais como: entre no sistema, realize uma compra, deixe apenas 3 itens ativos. Isso fará com que o usuário exponha a sua forma de fazer aquilo, não que siga a TUA forma de fazer isso.
5 – Não testar
Mais conhecido como o método eXtreme Go Horse, o jeito mais fácil de errar é não pensar que existe um erro e seguir desenvolvendo/idealizando.
Se você tem muito tempo para perder e não tem como objetivo produzir algo pensado no usuário, com organização e pensando na sua evolução… abstraia essa dica.
Esse post serve tanto para designers quanto para desenvolvedores, pois o produto digital envolve muitas semelhanças e métodos compartilhados.
