Como a UX Research melhora a qualidade do produto e reduz o tempo de desenvolvimento

Patrocinado

Benefícios da pesquisa de UX (com base em um projeto existente)

Na prática, os clientes não gostam da pesquisa de UX: leva muito tempo e o desenvolvimento não é realizado nesse período. No entanto, existem situações em que não se pode prescindir do UX. Foi exatamente isso que aconteceu com um projeto em que a equipe da Andersen estava trabalhando.

Um cliente nos pediu para redesenhar um sistema de call center e otimizar essa solução para as necessidades dos usuários. A empresa queria obter um protótipo imediatamente, mas insistimos em realizar um estudo completo, mostrando as vantagens dessa abordagem. Vamos contar o que aconteceu e como melhoramos o projeto graças à cooperação bem coordenada de um analista de negócios, um gerente de projeto e um designer de UX/UI.

Como tudo começou: um sistema complexo com um manual enorme, como nos anos 90

Assim, o cliente nos procurou com a ideia de uma atualização completa do seu sistema de call center. O programa era muito poderoso, mas não vendeu bem porque parecia desatualizado e levava muito tempo para ser dominado. O cliente queria torná-lo mais atrativo no mercado e otimizar sua funcionalidade.

A equipe da Andersen revisou a versão então atual do sistema e viu vários problemas importantes:

Um sistema extremamente complexo.

O desenvolvimento do sistema começou há mais de dez anos. Todos esses anos, ele continuou, e inúmeras atualizações surgiram à medida que o sistema considerava as necessidades de clientes completamente diferentes e oferecia opções de personalização excessivamente amplas.

Funcionalidade pouco clara.

O segundo problema tinha raízes no primeiro. A abundância de funcionalidades levou ao fato de que a navegação e a aparência geral do sistema estavam desatualizadas e completamente ilógicas e incompreensíveis, o que dificultava o trabalho com o programa.

Um enorme manual inútil.

Em teoria, era possível lidar com o sistema usando o manual, mas demorava cerca de trezentas páginas. Além disso, foi escrito como uma descrição da funcionalidade, não de cenários de usuário, portanto, não era fácil entender o que fazer em uma determinada situação. Como descobrimos mais tarde, ninguém usou o manual.

Um sistema sem orientação para o cliente.

Apesar de todos os problemas acima, o sistema deve ser centrado no usuário. Afinal, trabalhar em um call center implica em uma resposta instantânea, rápida interação com os clientes e realização de diversas operações.

Para resumir, temos um sistema complexo incompreensível com documentação excessiva e falta orientação para o cliente. A pesquisa de UX era uma obrigação nesse caso.

Fonte: andersenlab.com

Como a pesquisa de UX preparamos e conduzimos

Para mostrar ao cliente quais problemas o sistema apresentava, o Analista de Negócios e o Designer de UX/UI estudou o manual e a versão então atual do sistema e analisou sistemas similares e concorrentes. O primeiro contato com o programa revelou problemas de navegação e instruções de uso. A equipe percebeu que seria necessário se comunicar com diferentes stakeholders (donos de empresas, departamento de vendas) e fez um plano detalhado para trabalhos futuros com prazos e resultados específicos. A cada duas semanas, ligamos para os gerentes do cliente e o PM forneceu relatórios e métricas e discutiu possíveis riscos e melhorias. Como resultado, o cliente sabia exatamente o que receberia e por que precisava.

Demorou cerca de dois meses para estudar o domínio, instruções para o sistema, artigos sobre call centers e software para eles. Era preciso correlacionar o que estava dito no manual com o que estava realmente no sistema. Como resultado de um trabalho cuidadoso, o Analista de Negócios conseguiu criar um mapa mental, que apresentava a estrutura do sistema e as principais funcionalidades que cada uma das principais entidades desempenhava.

Durante a pesquisa de UX, encontramos alguns obstáculos. Vamos falar sobre eles em detalhes.

O teste do usuário não é permitido. Como esse problema foi resolvido?

A equipe precisava de respostas para as seguintes perguntas: “Quem são nossos usuários?” e “Como eles usam o sistema?” As funções do usuário foram mal descritas no manual e, portanto, precisávamos esclarecer se as entendíamos corretamente.

Infelizmente, os especialistas da Andersen não conseguiram realizar testes com usuários porque o call center trabalhava com bancos, seguradoras e outras organizações. De acordo com as regras de segurança, os dados de terceiros não podem ser transferidos para ninguém. Além disso, devido às fronteiras fechadas, não pudemos visitar os clientes pessoalmente.

Mas esses obstáculos não nos impediram, pois nossa equipe tinha um plano. Era necessário entender o que os usuários do call center esperavam, quais ofertas estavam no mercado e como as empresas atraíam novos clientes. Durante a primeira ligação com as partes interessadas, o Analista de Negócios, o GP e o designer foram solicitados a organizar a comunicação online com os usuários finais do produto. O cliente concordou e os funcionários da Andersen puderam realizar uma pesquisa geral e marcar entrevistas.

Entrevistas com usuários: o inglês não é a primeira língua dos entrevistados

Essa foi a parte mais interessante do trabalho. O analista de negócios e o designer de UX/UI criaram um questionário do Google doc para explorar alguns dos pontos. Como parte da pesquisa, duas abordagens foram combinadas. Graças a uma abordagem quantitativa, foi possível coletar dados estatísticos sobre o uso do sistema de acordo com as funções dos usuários. Um método qualitativo nos ajudou a aprofundar os detalhes e trazer insights importantes.

Primeiro, foi necessário verificar as funções dos usuários. O designer, com o consentimento do cliente, enviou um questionário para 21 empresas clientes de call center: bancos, seguradoras, empresas, etc. Descobrimos como 139 funcionários de diferentes estruturas trabalhavam com o programa e quais eram suas responsabilidades. O especialista em UX aprendeu quais módulos do sistema os clientes usavam com mais frequência. Um dos itens da pesquisa esclareceu se os entrevistados queriam falar com especialistas da Andersen. Se sim, eles deixaram o e-mail no formulário e marcamos uma entrevista com eles.

As entrevistas foram limitadas a 30 minutos por entrevistado. Uma lista de perguntas foi preparada para cada função de usuário. As respostas dos participantes foram gravadas, o que foi útil para a transcrição. A entrevista foi realizada em inglês, o que foi um pouco difícil porque esse idioma não era nativo de nossos entrevistados. No entanto, a equipe da Andersen conseguiu coletar bons insights, que foram apresentados ao cliente na forma de um relatório.

Fonte: andersenlab.com

Ferramentas de pesquisa de UX e processamento de dados

Muitos artigos contam como fazer pesquisa de UX. Mas carecem de informações sobre o que fazer com a grande quantidade de dados acumulados desde a etapa de entrevista. Assim, a equipe usou um diagrama de afinidade para interpretar os resultados.

Para este projeto, o diagrama de afinidades foi utilizado como metodologia para auxiliar na estruturação das informações. Para isso, identificamos os principais temas abordados na entrevista. Por exemplo, destacamos a categoria “deficiências do sistema”, onde registramos os pensamentos dos entrevistados sobre as deficiências. Além disso, consideramos comentários independentemente de funções, experiência etc.

Opiniões de usuários comuns (“há muita funcionalidade no sistema o que o torna desconfortável”) e a observação do administrador de que não podem personalizar o sistema para as necessidades de sua empresa bancária – todas essas questões foram inseridas na categoria de falhas do sistema em o diagrama de afinidade. Assim, as conversas com os entrevistados nos ajudaram a descobrir os principais problemas. Com base nesses resultados, criamos personas e entendemos quais problemas do usuário precisávamos resolver em primeiro lugar.

A segunda etapa importante do estudo do sistema, na qual o Analista de Negócios trabalhou, foi a criação de diagramas BPMN dos principais processos, diagramas de classes que ilustravam os relacionamentos entre entidades e diagramas de status mostrando o desenvolvimento de elementos individuais do sistema. Assim, descrevemos todos os processos de negócios em uma linguagem simples e padronizada. Ao olhar para o diagrama, gerentes, desenvolvedores, consultores e outros especialistas envolvidos no processo puderam entender a essência do sistema sem ler instruções volumosas.

Como a pesquisa ajudou a moldar novos trabalhos

Durante a pesquisa, o Analista de Negócios e o designer de UX/UI receberam informações suficientes, com base nas quais tiraram as seguintes conclusões:

• Os principais clientes são bancos e seguradoras

O estudo nos ajudou a constatar que o sistema era utilizado principalmente por funcionários de bancos (13.7%) e seguradoras (12.9%), e outras instituições o utilizavam em menor proporção. Portanto, ao criar o design, a equipe da Andersen decidiu focar principalmente nas necessidades desses clientes.

• Funcionários internos são os principais usuários

Como os agentes (51.1%) têm o papel principal no sistema, a equipe percebeu que deveria levá-los em consideração ao desenvolver o produto. Outros participantes (administradores – 10.8%, usuários de back-office – 10.8%, usuários – 15.1% e assim por diante) também precisavam de atenção. No entanto, você precisa se concentrar em usuários avançados familiarizados com as melhores práticas de UX (por exemplo, Google, Apple, etc.).

• O sistema é usado principalmente por jovens

Com base na pesquisa, ficou claro que o público-alvo do programa são funcionários de 18 a 30 anos (67.4%). Portanto, a equipe não precisou adaptar o design para pessoas mais velhas (fontes maiores, contraste aprimorado e assim por diante) e pode optar pelo comportamento moderno da web (pesquisa, posicionamento de botões e similares). Afinal, seguindo o últimas tendências de design chama mais atenção para o produto no mercado e também o torna mais intuitivo para usuários jovens.

• A maioria dos usuários trabalha com o sistema há mais de um ano

De acordo com os resultados da pesquisa, descobriu-se que os clientes podem ser divididos grosseiramente em usuários “júnior” (um a três meses), “médio” (três a doze meses) e usuários “sênior” (mais de um ano). Esses dados ajudaram a entender que a maioria dos usuários (32.4%) eram veteranos com mais de dois anos de experiência. Uma porcentagem um pouco menor de funcionários (25.2%) trabalhava com o sistema há um ou dois anos e 30.2% estavam familiarizados com ele há 3-10 meses. Assim, era melhor deixar a lógica principal do sistema para que fosse mais fácil para o consumidor aceitar qualquer atualização do programa.

• Os canais de comunicação mais utilizados são e-mail, chamadas e mensagens

A análise dos questionários mostrou o seguinte: para trabalhar de forma eficaz, os usuários precisavam principalmente de e-mail, telefonemas e mensagens, uma agenda de endereços, busca, relatórios e um painel de controle. Esses foram os módulos mais usados, que deveriam ter sido exibidos automaticamente no menu e desenvolvidos em primeiro lugar para um trabalho confortável.

Quais problemas os usuários relataram?

O estudo mostrou o que os usuários não gostaram no sistema:

1. Acontece que eles não ficaram totalmente satisfeitos com o design: acharam inconveniente. Os funcionários não gostavam de alternar frequentemente entre os módulos.
2. Os agentes precisavam ver todas as informações sobre o cliente com quem se comunicavam. Ao mesmo tempo, havia algumas dificuldades no registro de informações durante as ligações com os clientes.
3. A maioria dos trabalhadores de call center achava difícil entender o que cada função no sistema significava e o que precisava ser feito para prosseguir.
4. A abundância de informações confundiu os usuários.
5. Alguns entrevistados queriam implementar recursos adicionais, como canais de comunicação (Viber, WhatsApp e outras redes sociais).
6. O processo de configuração do usuário precisava ser simplificado.

Ficou claro que era necessário criar um novo sistema de design. Lá, as funções seriam agrupadas e botões, ícones e outros elementos complexos seriam exibidos com dicas ao passar o mouse.

Por que precisamos de personas?

O próximo passo da equipe foi criar personas com base em dados reais de usuários. Como resultado, conseguimos duas personas que nos ajudaram a discutir o fluxo com os clientes.

Em seguida, foi criado um mapa de jornada do cliente. Ajudou-nos a definir requisitos, fazer cenários positivos e negativos e delinear o conceito. Mais tarde, quando surgiram disputas de design, a equipe retornou a esse mapa para coordenar as mudanças com as solicitações e necessidades dos usuários.

O mais importante foi que todos os documentos estivessem interligados e que fossem discutidos e acordados com o cliente. Assim, o cliente entendeu o que a equipe estava fazendo e por quê.

O que aconteceu no final?

No decorrer do trabalho, o PM configurou os processos do projeto de forma que o cliente tivesse a máxima transparência em todos os sistemas, acesso a todos os materiais, relatórios regulares de progresso acumulados e análise SWOT.

O Analista de Negócios e o designer de UX/UI fizeram um excelente trabalho, prepararam os resultados do estudo e reportaram o trabalho realizado. O Analista de Negócios usou personas, CJM e User Story Map para escrever histórias de usuários e definir critérios de aceitação. Com foco no questionário, eles descreveram os requisitos para o projeto do sistema. Além disso, com base nessa documentação, eles verificaram a integridade e confiabilidade dos requisitos e estabeleceram o status e a prioridade de partes individuais do projeto.

Depois disso, a equipe criou o design UX/UI. Foi tudo muito rápido porque toda a documentação do estudo estava estruturada e disponível. Para a IU, foram utilizados dados analíticos. Por exemplo, como a maioria dos usuários trabalha em um monitor com resolução de 1200 pixels, o design foi desenhado para essas dimensões de tela. Além disso, como os monitores dos clientes eram em sua maioria bastante antigos, a equipe prestou mais atenção ao contraste de cores.

Como resultado, obtivemos um sistema grande e funcional. Uma das partes interessadas comentou sobre nosso trabalho da seguinte forma: “Estamos satisfeitos com a cooperação com a Andersen. O design que eles nos apresentaram é claro, fresco e moderno, e o design UX é perfeito. Os especialistas acabaram por ser profissionais de alto nível.”

No momento, não podemos dar estatísticas sobre como a pesquisa de UX nos ajudou a melhorar o sistema, porque o programa está em desenvolvimento. Será possível testá-lo em usuários após a conclusão da Fase de Programação.

Mas o analista de negócios e o designer de UX/UI podem concluir que requisitos detalhados e um design claro surgiram após quatro meses de extensa pesquisa. Por outro lado, a equipe deixou muitos caminhos abertos para que o sistema evoluísse de forma lógica e consistente além do MVP.

Os resultados da pesquisa de UX nos permitiram trabalhar os principais padrões de comportamento do usuário no sistema e criar telas-chave e formas de trabalhar com o aplicativo. Com base neles, a equipe conseguiu criar rapidamente novos módulos para permitir que o produto se desenvolvesse logicamente sem entrar em conflito com a navegação existente. Como resultado, os desenvolvedores podem acessar descrições detalhadas de qualquer cenário e os usuários têm um sistema que atende às suas necessidades e preferências.

Do ponto de vista do usuário, desenvolvimento, teste e design são bastante promissores. Ninguém está interessado em fotos bonitas, mas inúteis. É importante que todos os recursos do aplicativo funcionem e ajudem a obter lucro. E para ter ainda mais sucesso, você deve considerar a opinião dos usuários, com base nos resultados de pesquisas preliminares Teste de experiência do usuário. Afinal, investir em UX design na fase de criação de um conceito de projeto reduz o ciclo de vida do desenvolvimento de software em 33-50%. Esses são apenas alguns dos benefícios de uma pesquisa de UX bem-sucedida.