Identificando e definindo problemas a serem priorizados no desenvolvimento de produto

No post anterior “5 etapas de um processo de solução” passei uma visão geral do processo de solução que utilizo. Hoje pretendo falar sobre o "entendimento do problema" e como busco identificar e definir problemas a serem priorizados.

Para falarmos em identificação do problema, é preciso começar pelo aspecto mais importante desta etapa, a empatia.

A empatia em sua definição cognitiva, é uma habilidade socioemocional que permite aos seres humanos reconhecer, compreender e reproduzir emoções alheias.

Através da empatia deixamos de lado nossas opiniões, aprendizados, crenças e conhecimentos para nos alinharmos com as experiências de outras pessoas, buscando entender de maneira significativa quais são suas necessidades, desejos, motivações e por ai vai.

A empatia nos ajuda a compreender o que as pessoas esperam quando estão utilizando o que projetamos e evidencia os problemas em que devemos nos concentrar para entregar uma experiência adequada.

Através dela podemos identificar e definir problemas, nos colocando no lugar das pessoas, sentindo suas dores e anseios. Ela ajuda a projetar o entendimento do problema em três esferas que se complementam, que são:

1. O problema na visão do sistema
   Analisando o produto, como podemos resolver o problema em questão? É entregando uma feature nova? É melhorando a experiência de uma feature existente?
2. O problema na visão do usuário
   O quanto essa nova funcionalidade ou melhoria irá impactar a vida das pessoas, ela realmente soluciona o problema delas?
3. O problema na visão do negócio
   A entrega ou melhoria vem de encontra as necessidades do negócio? Além de solucionar problemas de usabilidade elas agregam valor para o produto?

Como mencionei no post anterior, existem várias técnicas que podem ser utilizadas para conseguirmos obter essas respostas e hoje vou falar sobre algumas delas.

Análise quantitativa

O "atendimento ao cliente" é uma das áreas que mais mantém contato com os usuários, além de auxiliá-los na utilização do software ele é responsável por classificar os principais problemas.

Imagine que uma das features do produto em que você trabalha está recebendo muitas reclamações, você até tem uma ideia do que pode ser mas ainda assim precisa saber qual é o motivador de tantas reclamações.

Antes de analisar os tickets dessa feature algo que pode ajudar a dar maior visibilidade é entender como o problema esta sendo categorizado, por exemplo:

• Bug (tem como fazer mas não esta funcionando)
• Comunicação (tem como fazer mas o usuário não sabe que tem como fazer)
• Educação (tem como fazer mas o usuário tem dúvidas conceituais sobre como fazer, porque fazer…)
• UX/UI (problemas de interface que interferem na finalização da tarefa)
• Funcionalidade inexistente (não tem como fazer)
• Tarefa manual (a funcionalidade não existe mas nós fazemos na mão.)

As categorias facilitam a visualização dos problemas em um range de tempo e possibilitam separá-los de forma mais consistente, dando uma visão mais precisa de quantas vezes o problema esta ocorrendo e em qual categoria, o que possibilita a priorização dos principais problemas e também gera insumos para a análise qualitativa.

Análise qualitativa

Já a análise qualitativa tem como objetivo trazer os usuários para o centro da resolução dos problemas e coletar suas percepções, escutar suas dores.

O que costumo fazer nessa fase é entender como o usuário está utilizando determinada feature, reconhecendo padrões de uso, como por exemplo se o usuário:

• Utilizou a feature X vezes, mas depois parou de usá-la.
• Não utilizava a feature, mas começou a utilizá-la.
• Uso casual (às vezes usa, as vezes não), qual é a principal motivação disso.
• Nunca usou, ou usou apenas 1 vez e parou de utilizar, o que causou esse comportamento?

Envolvendo os usuários desde o primeiro momento do processo garantimos que os problemas a serem solucionados são realmente aqueles que estão impactando no seu dia a dia.

Com essas análises em mão e entendendo quais são os problemas a serem atacados podemos partir para a segunda etapa do processo que é o benchmark.

E você, como tem feito para entender as necessidades de seus usuários? Quais são os critérios que tem utilizado? Deixe seu comentário…