Criando uma visualização da participação na Câmara: 5 lições dos testes à distância
Frequentemente, a Câmara dos Deputados recebe pedidos de informação sobre seus diferentes canais de participação. Em grande parte, tratam-se de pesquisas que buscam entender como os canais de participação são utilizados e qual o impacto destes no trabalho legislativo.
Nós mesmos aqui no LABHacker — pelo fato de ainda gerirmos tecnologicamente alguns destes canais de participação — precisamos muitas vezes parar o que estamos fazendo para gerar e apresentar os dados de modo inteligível. O procedimento, portanto, não é automático. E cada solicitação, com suas especificidades, demanda um (re)trabalho com dados atualizados.
Outros setores da Câmara também costumam ter o mesmo problema. Dentre eles, a Coordenação de Participação Popular (CPP), que nos propôs o desafio: prototipar uma solução que forneça automaticamente visualizações sobre métricas e indicadores da participação na Câmara.
Entendendo o desafio de visualizar a participação: as demandas de nossos usuários
Começamos com uma versão adaptada do Design Sprint de dois dias, onde reunimos basicamente a equipe do LAB e o definidor da Coordenação de Participação Popular.
No primeiro dia, tivemos palestras sobre alguns padrões nas informações solicitadas e exemplos de análises das teses acadêmicas. Também pudemos trocar experiência com o Senado, que enfrenta problema semelhante, com demandas de informações para o seu próprio portal de participação. Por fim, uma apresentação sobre bases de dados disponíveis da Câmara.
Depois, na hora de mapear o fluxo, identificamos diversos perfis de potenciais usuários. Decidimos focar os pesquisadores. Primeiro, porque são os que mais demandam os dados e tendem a ser os usuários mais frequentes. E, segundo, porque sendo mais detalhistas em suas demandas, oferecem um ponto de partida mais claro para o desenvolvimento de uma solução.
Decidindo fazer testes à distância: uma imposição da pandemia
Passados poucos dias do nosso Design Sprint, a pandemia do Coronavirus mostrou que era para valer no Brasil. Boa parte dos setores da Câmara começaram a trabalhar de maneira remota, incluindo o LABHacker.
Nas três semanas desenvolvendo o protótipo, várias dúvidas surgiram durante as nossas reuniões virtuais: Quais visualizações gerar? Tabelas? Gráficos? Coisas mais quantitativas ou qualitativas? Que informações serão de fato mais consumidas?
A solução para essas perguntas? Testes.
E como fazer no meio da pandemia? Testes à distância.
Cinco lições dos testes à distância com nosso protótipo
Mais do que aprender com o protótipo, aprendemos também com o próprio processo de fazer os testes. Quem nos acompanha nas redes sociais já pôde ler sobre a importância de nossos testes de usabilidade. Sempre os realizamos de maneira presencial. Em diversos lugares, mas, principalmente, no próprio ambiente do LABHacker.
Há um post nosso com as principais lições dos testes com usuários, que seguem válidas. Mas vamos agora revisitar e complementar essas lições com base no aprendizado usando o formato à distância:
1. Testar com o usuário à distância não é tão diferente de um teste presencial
Seguindo uma recomendação bastante difundida, o teste de uma página web deve acontecer em dois ambientes.
Em um ambiente, temos o teste propriamente dito com duas pessoas apenas: o usuário e o entrevistador. Assim, a experiência de navegação pode ser o mais confortável e natural possível
No segundo ambiente, será compartilhada a tela do usuário, bem como o diálogo ao vivo. Assim, o restante da equipe — os desenvolvedores e qualquer outra pessoa relacionada ou interessada no projeto — poderá observar como o usuário interagiu com o protótipo.
Na versão remota dos nossos testes, também tivemos os mesmos dois ambientes, porém em duas videoconferências simultâneas.
Para o ambiente do teste, passamos um link de videoconferência para o usuário. Depois de uma conversa rápida — apresentação e perguntas de contexto — instruímos o nosso usuário a compartilhar a sua tela. Durante a navegação, o entrevistador buscava fazer perguntas abertas, que não direcionassem a experiência, estimulando que o usuário pensasse em voz alta.
Em outra videoconferência — cujo link não era disponibilizado ao usuário — acontece o ambiente de observação. Os membros da equipe do projeto podiam observar a interação, e até mesmo conversar entre si, sem interferir no teste.
Se você reparou atentamente nas imagens anteriores, pode ter percebido que no ambiente do teste havia imagens de duas pessoas. Uma era do entrevistador. A outra era de um membro da equipe atuando como “observador”, que não interagia com o usuário.
Este “observador” acessava, simultaneamente, as duas videoconferências em duas janelas distintas do navegador. Utilizando a funcionalidade “compartilhar tela”, ele escolhia a janela do ambiente de teste para ser transmitida ao ambiente de observação. Também era marcada a opção para compartilhar o áudio da janela.
O compartilhamento também poderia ser feito pelo próprio entrevistador, mas é bom que este tenha a atenção total no usuário. Se aparecer algum problema com o compartilhamento no ambiente de observação, será a figura do “observador” quem deverá resolver sem atrapalhar o entrevistador.
2. O teste à distância pode ser o mais simples possível.
“Muitas pessoas supõem que testes precisam ser muito elaborados. Mas, se você torná-los muito elaborados, você não os fará frequentemente para tirar o maior proveito.”
Stephen Krug, Não me faça pensar
Não complique o teste, achando que é preciso muitos recursos tecnológicos e infraestrutura, senão a tendência é não fazer. Nossos testes presenciais nem sempre seguiram a recomendação de ambientes distintos. Mesmo sem uma infraestrutura ideal, não deixamos de obter alguns insights.
Seria um contrassenso, portanto, complicar os nossos testes à distância. Até porque dependemos da infraestrutura da casa do usuário. Quanto mais simplicidade, melhor. Usamos basicamente um aplicativo de videoconferência, computadores com microfone e webcam. Nada mais.
Uma pessoa muito rigorosa poderia argumentar: “Não há uma perda de informação neste teste remoto por não podermos ver as reações no rosto do usuário?”, “Não seria necessário uma outra câmera voltada para sua face?”, ou “Não é necessário um programa, uma forma de rastrear onde o usuário olha e no que presta atenção?”
Não. Informações acerca do olhar e da face do usuário não fazem muita falta.
Por mais que pareçam interessantes, os dados do rastreamento ocular (ou “Eye-tracking”) podem ser enganadores. Citando alguns estudos, a psicóloga Susan M. Weischench aponta alguns motivos: 1) as informações podem dizer algo que os usuários olharam, mas que não necessariamente prestaram atenção; 2) a visão periférica é tão importante quanto a visão central na apreensão do que o usuário vê; e 3) o que as pessoas olham tem mais relação com as perguntas feitas durante o teste.
Quanto à preocupação com alguma reação emocional no rosto, o programador Stephen Krug, em sua obra “Não me faça pensar”, nos assegura:
“Não se preocupe com uma câmera apontada para a cara do participante. O importante é o que acontece na tela e você quase sempre consegue dizer o que o usuário está sentindo pelo tom de voz”
3. O teste à distância facilita encontrar os usuários, nos mais diversos perfis.
Uma das melhores coisas dos testes à distância é a facilidade para encontrar os seus usuários. Podemos convidá-los de qualquer parte do país. É bem verdade que recebemos umas “esnobadas” e tomamos uns “bolos” algumas vezes. Entretanto, nada que impedisse reunir uma quantidade boa de testes.
Não houve critério rígido na hora de convidar os pesquisadores. Somente algum envolvimento acadêmico com participação política, sendo que a maioria tinha pesquisado canais de participação. De resto, bastava mesmo era atender ao nosso convite.
Foram seis pesquisadores. De maneira casual, estes acabaram distribuídos entre DF, MG, SP e RS. Eram três homens e três mulheres. Tivemos uma especialista, dois mestres, uma doutoranda e dois doutores.
À medida que conhecíamos melhor os nossos usuários, percebemos dois tipos de pesquisadores: uns qualitativos — mais interpretativos — e outros mais quantitativos, que trabalham com tabelas e números. Essa diferença de perfil permitiu colher feedbacks diversos quanto às visualizações apresentadas no protótipo.
Em todas as visualizações, notamos vários ajustes a serem feitos. Muito desenvolvimento realizado sem muita certeza. No entanto, os testes validaram muitas das nossas hipóteses, permitindo-nos saber que estamos em um bom caminho.
4. Os testes remotos podem ter problemas, mas ainda assim serão válidos.
“Testar sempre funciona e até mesmo o pior teste com o pior usuário servirá para mostrar coisas importantes que você pode melhorar no site”
Stephen Krug, Não me faça pensar
No formato à distância, pode haver problemas que impeçam o bom fluxo do teste. Há coisas que simplesmente vão fugir do seu controle. Algumas dificuldades podem ser:
- Instabilidade na internet da casa do usuário;
- Interrupção do teste por outras pessoas;
- Falta de intimidade do usuário com seus próprios recursos tecnológicos.
Para minimizar o impacto desses problemas, uma dica é dar um bom intervalo entre o início de um teste e o de outro, com uma hora e meia pelo menos. Por exemplo, se um teste foi agendado para iniciar às 14h, não agende o próximo antes das 15h30.
Assim, você terá tempo para alguma interrupção (como a chamada cair de repente) ou auxiliar o usuário com alguma dificuldade técnica (se está tendo problemas com sua webcam, por exemplo). Caso o teste flua sem problemas e sobre um tempo antes do início de outro, aproveite para avaliar rapidamente com a equipe como foi e se faltou alguma pergunta para explorar algo mais.
Para o tempo render, é bom confirmar antes com o usuário se ele sabe utilizar o aplicativo de videoconferência escolhido e compartilhar a tela (nem todo mundo sabia). Outra dica é enviar um material curto e com imagens, explicando o passo-a-passo de como o programa de videoconferência será utilizado. Caso ainda seja necessário, realizar um pequeno experimento do aplicativo antes do horário agendado para o teste.
É difícil de acontecer, mas se tudo — tudo mesmo — der errado na realização do teste, você, ao menos, vai saber o que fazer para melhorar em uma próxima tentativa. Com a simplicidade em mente, você vai se sentir encorajado a tentar de novo.
5. Mesmo sem rigor, testar com o usuário vai gerar muito conhecimento.
“Não se trata de provar algo, o que requer análises quantitativas. Os testes ‘faça você mesmo’ servem para apontar melhorias, sem rigor. Você oferece tarefas, observa e aprende. O resultado são insights e não provas para convencer alguém”
Stephen Krug, “Não me faça pensar”
Um teste de usuário simples — presencial ou à distância — pode ser feito com frequência. Por conta dessa facilidade, fizemos seis testes nas três semanas dedicadas ao protótipo. Em cada sexta-feira fizemos dois testes que orientaram o desenvolvimento para a próxima.
Na primeira semana, a despeito de alguns insights, a performance do teste foi afetada por uma inexperiência inicial do entrevistador e por problemas técnicos. Avaliamos, então, que seria bom testar com mais dois usuários. Com performances melhores, decidimos testar então com mais dois na última semana — como fechamento desta etapa — chegando-se, então, ao número de seis usuários.
Alguns autores advogam serem necessários poucos usuários. Jakob Nielsen diz que são necessários apenas cinco para achar 85% dos problemas. Já Stephen Krug, advogando que o importante é a frequência dos testes, afirma bastarem três usuários em um intervalo de um mês. O que a experiência mostra é não haver um número exato. Os testes precisam ser feitos na quantidade suficiente para você descobrir o que fazer a seguir no protótipo. Vai variar bastante, portanto, dependendo da etapa de cada projeto, do feedback proporcionado pelo usuário e do que a equipe entender.
Intencionamos fazer muitos outros testes em fases futuras do nosso projeto com a visualização da participação na Câmara dos Deputados. Por ora, podemos dizer que já encontramos trabalho para o desenvolvimento por um bom tempo. E como diz Krug:
“Você não precisa achar todos os problemas, porque em meio dia você acha mais problemas que você consegue corrigir em um mês”
Leituras para saber mais:
- Não me Faça Pensar (Atualizado), por Steven Krug (citações extraídas do cap. 9, que trata especificamente de testes)
- Sprint. O Método Usado no Google Para Testar e Aplicar Novas Ideias em Apenas Cinco Dias, por Jake Knapp, John Zeratsky e Braden Kowitz. (consulte os caps. 15 e, principalmente, 16 para dicas de como conduzir sua entrevista)
- 100 Coisas Que Todo Designer Deve Saber Sobre Pessoas por Susan M. Weinschenk (citação extraída do cap. 8)
