No entanto, a pesquisa de público ainda nem sempre é feita - às vezes é economizada ou considerada sem importância. Oleg Rudakov, Diretor de Desenvolvimento Analítico da AGIMA , compartilhou sua experiência e disse por que é importante conduzir pesquisas e o que acontece se você negligenciar isso. Oleg é professor do curso de Design de Interface .
Pequeno aviso
Primeiro, "todos os personagens são fictícios e qualquer coincidência com a vida real ou com pessoas vivas é acidental". Além disso, eles nunca foram associados ao trabalho do autor deste artigo.
Em segundo lugar, nem todos os produtos precisam de pesquisa, e não 100% do tempo. Por exemplo, se o projeto se depara com a tarefa de "fazer lindamente" e não há critérios para a eficácia do produto, então não há necessidade de gastar tempo em pesquisa, é melhor gastá-lo discutindo o problema e descobrindo o que é "bonito".
O que quero dizer com pesquisa de público
Métodos qualitativos e quantitativos de obtenção de informações sobre usuários e seu comportamento ou interação com os produtos.
Exemplos de métodos quantitativos:
- Análise de dados de sistemas analíticos web e móveis.
- Pesquisas online e offline de usuários de produtos ou participantes do painel.
- Classificação de cartões.
Exemplos de métodos qualitativos:
- Entrevistas detalhadas com usuários.
- Teste de usabilidade moderado ou não moderado dos entrevistados.
- Pesquisa de diário.
O valor da pesquisa está em identificar os reais motivos e dificuldades dos usuários em interagir com o produto. Ao corrigir as deficiências encontradas, é possível melhorar a eficiência do produto de forma controlada e significativa.
Também oferece uma oportunidade de priorizar o backlog do produto para se concentrar na conclusão de tarefas que terão um impacto maior no desempenho do produto final.
Por que o usuário nem sempre é pesquisado antes do design
Designers e designers têm técnicas próprias e muitas vezes o seu trabalho não se baseia em resultados de investigação, mas sim na sua experiência, observação ou sentido de beleza. No entanto, todos os membros da equipe têm sua própria experiência, sua própria observação e seu próprio senso de beleza. Portanto, sem pesquisa, em qualquer debate de equipe sobre como uma funcionalidade específica deve ser, o vencedor será aquele com mais peso. Nenhum participante da disputa possui dados objetivos e, portanto, nenhum argumento.
Outro padrão de comportamento comum no desenvolvimento de produtos é a cópia de produtos existentes e conhecidos. Por um lado, é lógico reutilizar padrões comuns de comportamento do usuário. Por exemplo, coloque o carrinho de compras de uma loja online no canto superior direito da página ou mova as seções principais para as guias do aplicativo móvel e coloque-as na parte inferior da tela. Por outro lado, não há necessidade de copiar todas as soluções sem pensar - nem todas funcionam.
Por causa disso, situações ocorrem quando projetos com soluções ambíguas são lançados - não funcionando, inconveniente. Isso geralmente é descoberto na fase de coleta de dados de sistemas analíticos da web ou móveis em um produto já acabado, quando não há motivo para desligá-lo ou excluí-lo, porque dinheiro e esforço foram investidos nele.
Portanto, permanece no produto uma espécie de mala sem alça, que vagueia de versão em versão do produto porque "os usuários estão acostumados".
Vou falar sobre alguns exemplos fictícios em que uma solução pronta acabou se mostrando inconveniente ou desnecessária para o usuário. Meu objetivo é ajudá-lo a pensar sobre o fato de que um designer ou designer geralmente precisa de pesquisas para criar um produto de qualidade verdadeiramente.
Funcionalidade desnecessária
Anti-caso nº 1 - a capacidade de comparar produtos na mesma categoria e filtros avançados para uma loja online
Vamos imaginar um site classificado. O usuário inicia seus anúncios, insere informações básicas sobre o produto e adiciona uma foto. Certamente, você mesmo usou sites semelhantes ou apenas foi ver se há algo interessante nos produtos.
Um desses sites decidiu melhorar e dar aos usuários mais opções para simplificar a seleção de produtos. Para isso, a equipe desenvolveu e adicionou dois recursos ao site: a capacidade de comparar produtos na mesma categoria e filtros avançados, nos quais os usuários podem selecionar uma dezena de critérios adicionais para selecionar produtos, além dos padrões (cor, tamanho, preço, ano de produção e outros).
A decisão parece bastante lógica, uma vez que todas as grandes lojas online oferecem as mesmas oportunidades. E as mesmas mercadorias são vendidas lá e lá. Além disso, parece que produtos tecnicamente complexos são convenientes de selecionar usando uma lista de comparação.
Após o lançamento dos recursos, eles foram marcados com sistemas analíticos e, de acordo com os eventos de aplicação de filtros e listas de produtos no e-commerce avançado, o Google Analytics percebeu que quase ninguém estava utilizando a nova funcionalidade.
Decidimos então realizar um estudo - uma pesquisa online com o público do site sobre suas metas e objetivos de trabalhar com a loja, a experiência de comprar categorias de produtos e, de maneira geral, usar o site.
A pesquisa apresentou resultados interessantes: o segmento-chave do site são aqueles que já sabem o que querem comprar e de que produto precisam. Portanto, de todos os produtos apresentados, eles escolhem por preço e condição, considerando literalmente alguns modelos. Eles não precisam de filtros complexos para selecionar esses produtos e não usam a função de comparação.
Claro, nada de ruim aconteceu. As opções adicionadas foram deixadas no site, pois não traziam prejuízos. Só agora as equipes gastaram tempo no desenvolvimento e os indicadores de negócios da loja não melhoraram.
O que poderia ter sido melhor
A equipe pôde descobrir a atitude dos usuários em relação às mudanças na fase de tomada de decisão sobre o desenvolvimento. Esta pode ser a mesma pesquisa online no site. Ele forneceria uma visão sobre a experiência de compras anteriores e as necessidades do usuário para novas funcionalidades.
O formato de entrevistas em profundidade com os usuários do site também seria adequado, mas, em comparação com uma pesquisa, permitiria descobrir os motivos e as solicitações dos usuários com mais detalhes. Mas eu gosto mais da opção de pesquisa, porque é um método de pesquisa quantitativa que permite dados mais amplos.
Anti-case # 2 - um aplicativo móvel para clientes de bancos
Na esteira da transformação digital, uma empresa de investimentos (o nome não está afinado com nenhum banco e não consiste em três letras) decidiu desenvolver um aplicativo mobile para clientes. Nele, eles puderam visualizar informações sobre seu portfólio, realizar transações e estudar notícias sobre um tema de interesse da própria empresa.
Os concorrentes da empresa já tinham aplicativos móveis, mas a diferença é que os concorrentes sempre trabalharam com um público menos solvente, que é a maioria. Esses públicos são novos em investir e encontram conteúdo adicional sobre o tópico importante.
Após a transferência da aplicação para a operação industrial, foi lançada uma campanha publicitária de divulgação junto dos clientes atuais e potenciais. Com base nos resultados da pesquisa e análise do retorno do investimento em publicidade, determinou-se que atrair novos clientes não é lucrativo. O custo de aquisição é alto devido à concorrência, e a receita dos clientes é pequena, pois eles realizam poucas transações e a comissão deles não compensa a aquisição.
Como resultado, a publicidade foi rapidamente interrompida e o fluxo de usuários para o aplicativo tornou-se igual ao fluxo de novos clientes para a empresa. Os atuais clientes passaram a enviar mailings e a contar sobre a aplicação nos escritórios e no site. Assim, ao invés de um recurso conveniente e interessante para atrair, o aplicativo tornou-se apenas uma ferramenta para trabalhar com os clientes atuais.
Seria possível prever tal resultado - sim. 5% dos clientes da empresa fornecem 95% da receita. Além disso, esses clientes nunca realizavam operações sozinhos e interagiam apenas com seus gestores pelo lado da empresa. Todos os relatórios para eles foram trazidos pelos gerentes e apresentados em formato impresso. É lógico que, com este modelo, o novo aplicativo não afetou de forma alguma os principais clientes lucrativos. Além disso, não atrairia os mesmos novos clientes.
O que poderia ter sido melhor
Nesse caso, não há necessidade de pesquisa de público das formas convencionais. Para começar, eu não dividiria o público em clientes novos e atuais como parte da criação de um aplicativo. Qualquer produto tem clientes novos e atuais. E vejo o objetivo de desenvolver um aplicativo, em vez de criar uma ferramenta conveniente para reter os clientes atuais, para que eles não tentem o que os concorrentes têm.
Antes de desenvolver o aplicativo, a empresa precisava analisar a estrutura de recebimento de recursos por tipo de cliente.
Então, a equipe veria que o aplicativo não afeta a lealdade dos usuários atuais que ganham dinheiro.
Além disso, o cálculo da economia unitária de atração de novos usuários ajudaria a ver a convergência da economia levando em conta o plano de mídia.
Funcionalidade inconveniente
Anti-caso nº 1 - estrutura da página de destino malsucedida
Vamos imaginar uma página de destino de conferência. Estrutura da página de destino de cima para baixo:
- banner grande com logomarca, título e datas do evento;
- 10 principais palestrantes com fotos (conhecidos por todos no assunto);
- bandeira;
- Mais 30 alto-falantes com fotos;
- formulário de pedido de compra de ingressos;
- programa completo do evento;
- roteiro;
- formulário de pedido de compra de ingressos;
- logotipos dos parceiros.
A disposição dos blocos na página parece lógica: primeiro, os usuários devem estudar as informações importantes e só depois se inscrever na conferência. Na verdade, descobriu-se que a estrutura do site é categoricamente inconveniente. Com tal disposição de blocos, após o lançamento da página de destino, descobriu-se que a conversão para um aplicativo era muito baixa para ter tempo de coletar uma sala cheia no tempo restante antes do evento.
O trabalho no projeto foi dividido em duas partes. Uma equipe analisou o tráfego do site e a outra analisou a própria interface. Olhamos os dados no Yandex.Metrica, o que levantou dúvidas sobre a eficácia da estrutura da página, e o mapa de rolagem chamou minha atenção.
Então, decidimos realizar um teste A / B / N, no qual o formulário de inscrição foi trocado por outros blocos de conteúdo na página. Por que você começou com o formulário? A landing page era fácil de navegar e não causou nenhuma dificuldade. Era tarde demais para mudar os próprios palestrantes e seus tópicos. Das opções possíveis, restaram apenas a estrutura da própria página e a localização do formulário de candidatura.
No estudo, examinamos o formulário a partir do qual os usuários enviam um pedido de registro. Como resultado, a página de destino com a estrutura a seguir teve a maior taxa de conversão:
- banner grande com logomarca, título e datas do evento;
- 10 principais alto-falantes com fotos;
- formulário de pedido de compra de ingressos;
- todo o resto.
O público estava interessado em ouvir os principais palestrantes e não importava quem mais falaria e quais seriam os tópicos dos relatórios. Portanto, na página de destino da conferência, o formulário de inscrição foi elevado, após o que a conversão aumentou muito.
O que poderia ser feito melhor
? Os organizadores da conferência poderiam fazer pesquisas sobre os resultados do último evento. Por exemplo, junto com materiais úteis, envie uma pesquisa entre os participantes na qual eles perguntariam sobre as razões para tomar a decisão de comprar ingressos.
Além disso, no início da venda de ingressos, tal pesquisa poderia ser conduzida com clientes anteriores por telefone para fazer perguntas mais detalhadas. O estudo é simples, mas traria bons resultados para a compreensão da estrutura de futuras conferências.
Anti-case número 2 - calculadora para calcular o valor do seguro
Imagine um site de uma pequena seguradora (não entre as 10 primeiras em vendas). Mais precisamente, apresentaremos uma calculadora para calcular o valor do seguro para quem viaja ao exterior. Depois de elaborada a lógica e o design da calculadora, entendemos que é necessário escrever dicas para os campos e resolver os erros dos campos de entrada. Isso ajudará os usuários a entender e aumentar a conversão para a qual tudo foi feito.
Como alguns detalhes do processo de seguro são claros apenas para um profissional, os textos das dicas serão escritos pelo gerente de produto desta calculadora - ele é quem melhor entende o produto. Por conta disso, as palavras aparecem nos textos "trabalho com risco aumentado", "retorno antecipado do segurado ao país de residência permanente", "esporte" ou "seguro de acidentes".
E para alguns dos pontos, não há dicas, porque quem os escreve entende imediatamente o que se entende por idade do viajante, e separa precisamente a “idade” pela data da contratação do seguro e pela data da viagem. Infelizmente, os usuários comuns não entendem essas formulações ou se enganam em sua interpretação.
Depois que as dicas foram publicadas, alguns clientes escreveram para o suporte técnico e alguém xingou pesadamente quando ocorreu um evento segurado. E houve erros na apólice por falta de informação no preenchimento.
Realizamos testes A / B e, após analisar as solicitações dos usuários ao suporte técnico, adicionamos dicas para campos complexos. Com isso, devido ao estudo cuidadoso das dicas do texto, foi possível aumentar a conversão em 10%.
Nesse caso, não foi necessário um estudo abrangente. Ficou imediatamente claro para a equipe de design que pontos complexos precisavam ser explicados em detalhes. Portanto, executamos testes A / B para ver a melhor forma de descrever as pistas.
O que poderia ser feito melhor
? Os criadores devem pensar imediatamente em como fornecer aos usuários solicitações claras em todos os lugares. O problema é que os desenvolvedores geralmente estão profundamente imersos no tópico do produto e parece que todos ao seu redor também entendem tudo. Mas eles não são o público-alvo do produto - foi necessário realizar testes de usabilidade de protótipos. Ou, pelo menos, recupere a razão quando essas perguntas começarem a servir de apoio.
Vamos resumir
A pesquisa feita antes do design e do desenvolvimento pode ajudá-lo a obter o resultado desejado ou descobrir o que precisa ser desenvolvido ou não e como tornar a funcionalidade mais amigável.
Há momentos em que a pesquisa é desnecessária: não há recursos, nem tempo, ou a tarefa não afeta os indicadores críticos de negócios. No entanto, mesmo nesses casos, é melhor realizar pelo menos um estudo mínimo, mesmo uma pesquisa de corredor, para verificar o resultado. Quando a usabilidade do produto depende do design, é melhor confiar nos dados objetivos que foram coletados antes de iniciar o trabalho.
Espero que esses exemplos o incentivem a aprender mais sobre a pesquisa de experiência do usuário para problemas de design e a usá-los com mais frequência em seu trabalho. Boa sorte!