💨 🖐️ 👨🏽‍💼 Pesquisa UX da RBS: nossa experiência, erros e descobertas 👩🏿‍🤝‍👩🏼 👨🏽‍🌾 🐅

Ei. Sou Denis Elianovsky, diretor de design da JTC e líder do Opium Pro. Trabalhamos em segmentos muito restritos do mercado de TI relacionados a finanças e fluxo de trabalho. Você certamente nunca ouviu falar sobre essas empresas e hoje não saberá muito sobre elas, porque este artigo trata da pesquisa sobre UX.

Desenvolvo projetos nos últimos 12 anos (8 deles são precisamente o design de interfaces complexas) e quero contar como realizamos testes de usabilidade do aplicativo RBS. E também sobre quais erros foram cometidos e quais conclusões foram tiradas disso. No processo, recomendo alguns livros. Todas as imagens são clicáveis.

O que é o RBS?Significa Serviço de banca remota. Esses aplicativos também são chamados de bancos online. Certamente todos vocês já têm isso no seu telefone. Aqui somos um daqueles que projetam e desenvolvem tais aplicações.

Você provavelmente encontrará algo útil no artigo se já ouviu falar sobre a pesquisa de UX e gostaria de testar seu aplicativo, mas não sabe por onde começar. Se você já tem experiência em testes, será entediante e desinteressante, perdoe-me.

Quem é mais conveniente para assistir ao vídeo, aqui está uma gravação

Quais são os testes?

Se você pedir para colocar uma descrição da pesquisa de UX em 23 palavras usando três vírgulas, um hífen e um hífen, a pesquisa de UX é uma ação útil rápida que pode ser realizada nos estágios iniciais do desenvolvimento e, assim, evitar erros que possam surgir em produção. Mas o lançamento de um aplicativo bancário em produção não é apenas um grande estresse, mas também um enorme desperdício de dinheiro. A pesquisa UX permite que você teste seu aplicativo em usuários reais muito antes de começar a descarregar o KAMAZ com dinheiro nos bolsos de desenvolvedores e profissionais de marketing.

Obviamente, todo designer (todo bom designer) testa sua aplicação antes do lançamento. Mas geralmente isso é feito "em casa". Ou seja, é testado em seus entes próximos e queridos, e muito raramente é de alguma forma sistematizado. Neste artigo, quero mostrar que, em aplicativos grandes e complexos, o teste de design deve ser regulado e integrado ao próprio processo de design.

Primeiro, a pesquisa pode ser quantitativa e qualitativa. Quando falamos de pesquisa quantitativa, queremos dizer cobertura do público: nos esforçamos para aumentar o número de pessoas que testamos. Quando falamos de pesquisa de qualidade, testamos poucas pessoas, mas com cada uma delas realizamos uma entrevista mais detalhada e aprofundamos cada caso específico.

Plano de coordenadas. Certo - Quantitativo. Esquerda - Qualidade

O mesmo plano de coordenadas. Acima está o comportamento. Inferior - Atitude

Mais pesquisas podem ser divididas em comportamentais e relacionais. Quando realizamos testes comportamentais, monitoramos o que uma pessoa faz com nosso aplicativo. No relacional, é importante que a pessoa fale sobre nossa aplicação.

Neste artigo, focaremos nos testes de usabilidade. Eles se relacionam com testes de qualidade comportamental. Nesse caso, um pequeno número de pessoas está envolvido nos testes e basicamente o que eles estão fazendo com o aplicativo é cuidadosamente estudado.

O mesmo plano de coordenadas. Marca do círculo superior esquerdo

O processo de design está bem refletido na programação de Damien Newman. E como eu disse acima que o design e o teste devem ser um todo, o gráfico reflete o processo de criação de um design e seu teste. Duas conclusões podem ser tiradas deste gráfico. 1) Projeto e teste são um processo não linear. 2) E também é um processo iterativo. Isso é óbvio à primeira vista no gráfico, não é? O que quero dizer com não linearidade?

Um emaranhado emaranhado que se desenrola em uma linha plana

Inicialmente, temos tantas teorias diferentes que queremos testar através de protótipos. E somente no final do processo de design eles se acalmam. De tempos em tempos, de iteração para iteração, as sessões de teste se tornam mais parecidas entre si e as mudanças no design se tornam cada vez menos: elas são mais profundas, mais elaboradas, mas externamente é mais difícil percebê-las.

Ao chamar o processo de iterativo, quero dizer que você não pode testá-lo uma vez e parar por aí. Os testes devem ser realizados regularmente. É então que faz sentido. Especialmente considerando que o design também está mudando dramaticamente no processo.

Como se preparar para um estudo de experiência do usuário?

Usability- . ? , . . , , ( ), User Story Map. User Story Map .
. , . , . , 10–15 , 20 ( : , , ). , 5–7 -. , . , «» «», -, .
. (5–7 ). , . -. , « » .

Darei uma resposta imediata à pergunta mais popular de nossos clientes, que soa assim: "Você provavelmente testa tudo sozinho para garantir que os resultados sejam bons?" Não. Não apenas não incluímos nossos resultados nos testes, tentamos nem incluir pessoas com deformações profissionais nos testes, ou seja, aqueles que estão envolvidos profissionalmente em testes por dinheiro. E também excluímos designers, programadores e outros que também estão sujeitos a essa deformação profissional.

Vamos repetir o que precisamos de preparação para consolidar.

1. Hipótese

A figura abaixo mostra várias opções possíveis para visualizar esse processo. A tela mais à esquerda é como você pode criar o Mapa da história do usuário por meios improvisados. Para fazer isso, basta usar adesivos de papel. Ao conectá-los a strings, mostramos suposições sobre como o usuário percorrerá o aplicativo. A segunda opção é o Mapa da história do usuário, desenhado no Miro. De fato, os mesmos pedaços de papel, apenas transferidos para o formato eletrônico por conveniência. E a terceira tela é um protótipo clicável no Figma.

As ferramentas específicas acima são indicadas, mas, de fato, não há vinculação a elas, e hipóteses podem ser construídas no que for mais conveniente para você. Por exemplo, em nossa equipe, há entusiastas que realizaram todos os testes em pedaços de papel. Eles também tinham um protótipo clicável em pedaços de papel - e isso também pode ser iniciado.

2. Elaborar perguntas

Perguntas abertas. Ótimo se eles estiverem na forma de histórias. Ou seja, se supusermos que uma pessoa deve bloquear o cartão para resolver seu problema, não dizemos "Bloquear o cartão" na testa , contamos uma história. Idealmente, a história deve mergulhar uma pessoa em si mesma e provocá-la a responder com a história também.

Exemplo:

À esquerda está um exemplo de uma pergunta ruim. À direita é um exemplo de boa

3. Reunir respondentes

Essa programação foi elaborada por Jacob Nielsen nos anos 90. Mesmo assim, foram realizados estudos de UX. A linha horizontal mostra o número de pessoas que estamos testando e a linha vertical mostra o número de erros encontrados. Vale ressaltar que, após a 5ª pessoa sendo testada, o horário se torna mais suave, mas o que isso significa? Isso significa que, após cinco pessoas, diminui a eficiência de cada nova pessoa de teste e, com ela, encontramos cada vez menos erros. Jacob Nielsen chegou a essa conclusão e compartilhamos totalmente essa conclusão.

Outro gráfico no plano de coordenadas. Primeiro, crescimento acentuado e inibição suave do crescimento

É mais eficiente fazer pequenas amostras, mas com frequência.

No começo, eu queria aconselhar o livro de Jacob, mas, em geral, ele já é antigo. Há algo melhor. O autor continua envolvido na pesquisa de UX, e aqui está o site dele, há muitos artigos: nngroup.com

Processo de teste

Texto: O processo é gravado em vídeo; Expressando pensamentos; 5 porque; Você gerou

Porra, é importante gravar todos os testes em vídeo. O vídeo é o artefato mais importante dos testes. Se você não possui um vídeo, podemos dizer que você não testou.

O primeiro. Antes de iniciar os testes, como estamos testando um aplicativo móvel, entregamos o telefone a uma pessoa. Pedimos que ele relaxe e não deixe de expressar tudo o que está acontecendo. É importante entendermos a linha de pensamento do sujeito.

Em segundo lugar, e chamamos essa regra de "5 por quê?", no processo de transmissão do script, você precisa provocar uma pessoa a explicar qualquer parada ou dúvida em suas ações. Aqui, essas perguntas ajudam muito: “O que você esperava ver nesta tela?”, “Por que você clicou neste botão?”. Isso nem sempre é exatamente o porquê, mas o desejo de fazer o maior número possível de perguntas e mergulhar na cabeça da pessoa o máximo possível sempre ajuda.

E o terceiro. Com base nos resultados do teste, perguntamos: “Você acha que concluiu a tarefa? " Além disso, não apenas o respondente responde a essa pergunta, mas também a pessoa que está testando. Por que fazemos isso, vou contar abaixo.

Agora passamos diretamente para nossos testes.A tabela mostra como podem ser os resultados resumidos da pesquisa. Estes são os resultados reais do nosso primeiro teste. À esquerda, há uma lista de perguntas e histórias, seguidas de colunas para cada um dos entrevistados. Se custar 1, significa que o sujeito e o testador consideraram a tarefa concluída. Se 0,5 - significa que alguém sozinho acredita que a tarefa não foi concluída. Se 0 - ambos concordam que a tarefa não foi concluída. A partir desses dados, podemos entender quais cenários temos fortes e quais são fracos. A partir dos dados da tabela, podemos concluir que, por exemplo, estamos bem com o bloqueio do cartão, todos enfrentaram. E com a transferência de dinheiro - não muito bom, é nisso que devemos trabalhar.

Mesa. A primeira coluna é o texto das perguntas. As colunas restantes são números

Testamos nosso aplicativo RBS móvel para indivíduos. No total, no momento da criação deste relatório, duas iterações de testes foram aprovadas, em cada uma das quais 6 pessoas foram testadas. Apenas 7 mulheres, 5 homens com idades entre 20 e 50 anos. Inicialmente, não tentamos fazer uma seleção muito ampla de profissões, mas acabou sendo bastante diversificada: professores, médicos, administradores de restaurantes etc. Devido à solicitação do nosso cliente, na segunda sessão, mais pessoas com mais de 40 anos foram incluídas na amostra. E foi nessa audiência que mais erros foram identificados. Na maioria das vezes eles tropeçavam em algum lugar, paravam em algum lugar e tinham que fazer mais perguntas.

O texto acima foi escrito sobre os parâmetros de audiência

Resultado dos testes

Os resultados do teste do ponto de vista de "enfrentaram / falharam": verificou-se que os testados lidaram com 93% das tarefas. Além disso, eles próprios acreditavam ter conseguido apenas 83%. Essa diferença de 10% - nos momentos em que uma pessoa foi de acordo com o cenário desejado, nosso testador vê que lidou com a tarefa, mas o entrevistado não tem certeza dos resultados. E esses também são problemas que precisam ser trabalhados. Afinal, entendemos que em tais momentos o aplicativo não dá à pessoa o feedback desejado e isso precisa ser corrigido. Em média, uma sessão levou 12 minutos. Um bom resultado, levando em consideração o fato de nos concentrarmos em 10 a 15 minutos. Abaixo está o design do aplicativo que foi usado na primeira iteração dos testes. Deixe-me explicar o que decidimos mudar de acordo com os resultados do teste.

Paychart, dividido em 3 partes. 83%, 93% e a parte branca vazia

Três telefones celulares com um aplicativo aberto. A primeira tela é destacada.

Vou dizer em nome do usuário que apontou o dedo para este aplicativo.

Suponha que eu precise pagar por um telefone celular. Provavelmente, deve haver um botão "pagar" em algum lugar. Não encontro o botão e estou saindo para procurá-lo no menu de hambúrgueres no canto superior esquerdo.

Qual é o problema? Existem dois botões de "pagamento" na tela, ninguém notou nenhum deles. Isso foi em 3 casos em 6.

Outro problema. A seção de análise, que achamos muito útil, infelizmente, os usuários não encontraram como tal. Ele apenas confundiu as pessoas.

Em geral, se você olha globalmente, essa tela está sobrecarregada, é difícil para o usuário classificar em suas cabeças o que e onde está localizado nela.

A segunda tela é a tela de pagamento / transferência: durante o teste, descobrimos que as pessoas estão interessadas em ver seus pagamentos regulares e as procuram na tela de pagamento. Na primeira versão do design, eles estavam na borda e parcialmente ocultados por um pergaminho horizontal. Bem, em princípio, eles estavam em uma guia separada, o que também dificultava encontrá-los. A terceira tela é uma tela com produtos bancários:

Três telefones celulares com um aplicativo aberto. Segunda tela destacada

Três telefones celulares com um aplicativo aberto. A terceira tela é destacada.

Todas as pessoas que testamos (ok, quase todas) notaram que essa tela é útil. Eles sabiam para onde ligar, costumavam usá-lo. Aqui, criamos um problema para nós mesmos, fazendo uma chamada para essa tela no menu de hambúrguer superior esquerdo. No vídeo, percebemos que quando uma pessoa tenta pressionar esse botão, muitos interceptam o telefone, e isso não é conveniente para todos.

Agora, os telefones se tornaram grandes, podem cair e decidimos que isso é um problema para nós, vamos trabalhar com ele. A propósito, adivinhe por que o autor do artigo anda com um telefone quebrado?

As figuras a seguir mostram o design significativamente alterado da segunda iteração.

Três novos telefones celulares com um aplicativo aberto. A primeira tela é destacada.

Como você pode ver, a tela ficou muito mais fácil. Agora, quando pedimos aos usuários que nos dissessem o que viram, eles nos disseram isso da mesma maneira que imaginávamos. A seção de análise foi removida sob um botão adicional, agora não carrega espaço. Na tela de pagamento, os pagamentos regulares são feitos de forma a serem perceptíveis. Mas as pessoas ainda estão presas aqui, o que implica que definitivamente iremos melhorar e facilitar. A terceira tela é uma tela com uma lista de produtos bancários que uma pessoa possui. E aqui acessamos a partir da parte inferior do telefone, em vez de chamá-lo no menu superior esquerdo do hambúrguer.

Os mesmos três novos telefones. Segunda tela destacada

Os mesmos três novos telefones. A terceira tela é destacada.

Agora, esse objeto está localizado diretamente sob o dedo do usuário e ele não precisa alcançá-lo, basta deslizar para cima ou clicar nele para abrir a lista de produtos.

Mais algumas observações e conclusões que fizemos durante o teste. Quem diria que existem canhotos e pessoas no mundo que estão simplesmente acostumadas a segurar o telefone na mão esquerda. E eles têm suas próprias características de uso. Se uma pessoa comum intercepta o telefone, o canhoto não intercepta para pressionar o botão de menu do hambúrguer. Observamos que os canhotos apenas usam os dispositivos de maneira diferente e continuaremos testando e descobrindo se podemos melhorar a experiência deles. Ainda há pessoas com baixa visão.

Gráfico de barras. 3 barras: 10%, 13%, 50%

Todo mundo sabe disso, e todo mundo esquece (quero dizer designers). Como posso ajudar pessoas com baixa visão? Em primeiro lugar, você pode aumentar os objetos no design. Em segundo lugar, você pode aumentar o contraste no design. E há outro ponto menos óbvio: você pode separar informações, aumentar a distância entre blocos, o que também ajudará as pessoas a ler melhor as interfaces.

De acordo com as estimativas mais conservadoras que podem ser encontradas na Wikipedia, temos 10% de canhotos e 13% de pessoas com baixa visão. Segundo os indecentes - as pessoas canhotas estão em torno de 15% e as pessoas com baixa visão - 30%.

E algumas garotas têm unhas compridas.Essas garotas também usam o telefone de maneira diferente. É difícil para eles pressionar algo no canto inferior direito, porque, em vez de pressionar com a ponta do dedo, eles descansam com a unha e, portanto, também precisam interceptar. Não há estatísticas oficiais aqui, mas posso assumir que, de tempos em tempos, até 50% da população adulta do planeta pode estar nessa situação.

Além dos testes de usabilidade destacados acima, existem muitas maneiras diferentes de testar o UX. Entre eles:

Eyetracking
Testes A / B
Pesquisas on-line
Entrevistas detalhadas

No primeiro plano de coordenadas, existem círculos com os métodos de teste mencionados acima

Quanto mais tempo gastamos testes, mais claramente entendemos que o teste UX está muito próximo de uma ciência como a psicologia cognitiva. E especialmente para um conceito como "distorção cognitiva".

Para quem quer se aprofundar nisso, aconselho o livro de Daniel Caniman, “Pensando, Rápido e Lento” (pense devagar, decida rapidamente). Ela não falará nada sobre os testes, mas fornecerá um bom terreno para reflexão, mostrando como as mesmas pessoas podem responder a perguntas diferentes da mesma maneira.

Este artigo ajudou você a se aproximar de começar a testar as interfaces? O que acabou por ser útil (se algo ainda acabou por ser) e o que é inapropriado?

Obrigado a todos que ajudaram a conduzir o estudo e a preparar o relatório.

Pesquisa UX:
equipe JTC - análise de negócios, design, pesquisa UX
Denis Krasilnikov - design
Anton Kazakov - pesquisa UX
Ekaterina Kashkovskaya - pesquisa UX
Dmitry Dobrodeev - pesquisa UX
Irina Ponomareva - filmagem e edição

Preparação do relatório:
equipe JTC - geração de relatórios
Maxim Blokhin - design de
Irina Ponomareva - filmagem e edição de
Nadezhda Molodtsova - filmagem de
Tatyana Kitaeva - edição

Pesquisa UX da RBS: nossa experiência, erros e descobertas