Paul Buchheit em
ouvindo os usuários:
Escrevi a primeira versão do Gmail em um dia. Não foi muito impressionante. Tudo o que fiz foi colocar meu próprio e-mail no mecanismo de indexação do Google Groups (Usenet). Enviei a versão para algumas pessoas para obter feedback, e elas disseram que era útil, mas que seria melhor se o mecanismo buscasse o e-mail delas em vez do meu. Essa foi a versão dois. Depois que lancei essa versão, as pessoas começaram a querer a possibilidade de responder a e-mails também. Essa foi a versão três. Esse processo durou alguns anos dentro do Google antes de ser lançado para o mundo.
As startups não têm centenas de usuários internos, por isso é importante lançar o produto para o mundo muito antes. Quando FriendFeed foi semi-lançado (beta privado) em outubro, o produto tinha apenas cerca de dois meses (e 99,9% foi escrito por duas pessoas, Bret e Jim). Fizemos muitas melhorias desde então, e o produto que temos hoje é muito melhor do que o que teríamos criado se não tivéssemos lançado. O motivo? Temos usuários, ouvimos o que eles têm a dizer e vemos o que funciona e o que não funciona.
Ouvir os usuários é uma coisa complicada. Os usuários geralmente não sabem o que querem e, mesmo que soubessem, o é provável que a comunicação fique confusa em algum ponto entre eles e o senhor. O senhor não deve, de forma alguma ignorar seus usuários. A maioria das pessoas se afastará silenciosamente e para sempre se o seu software ou site não atender às necessidades delas. Os usuários que se importam o suficiente para lhe dar feedback merecem sua atenção e respeito. Basicamente, eles estão assumindo a responsabilidade de projetar seu produto. Se o senhor não ouvir com atenção e responder educadamente a todos os comentários dos clientes, estará se preparando para um eventual fracasso.
É falta de educação não ouvir seus usuários. Então, como podemos conciliar isso com a primeira regra de usabilidade? Não ouça os usuários?
Para descobrir quais designs funcionam melhor, observe os usuários enquanto eles tentam realizar tarefas com a interface do usuário. Esse método é tão simples que muitas pessoas o ignoram, presumindo que deve haver algo mais nos testes de usabilidade. [It] resume-se às regras básicas de usabilidade:
- Observe o que as pessoas realmente fazem.
- Não acredite no que as pessoas dizem eles fazem.
- Definitivamente, não acredite no que as pessoas preveem. pode fazer no futuro.
Acho que Paul estava certo, mas é fácil não perceber. A frase relevante na postagem de Paul é vemos quais coisas funcionam, o que implica medição e correlação. Não há necessidade de observar diretamente os usuários (embora isso nunca seja demais) quando o senhor tem registros detalhados que mostram o que eles realmente fizeram. Colete o feedback dos usuários e, em seguida, correlacione-o com dados sobre o que esses usuários estão realmente fazendo:
Não implemente apenas solicitações de recursos de “representantes de usuários” ou “analistas de negócios”. A maneira mais comum de errar na usabilidade é ouvir o que os usuários dizem em vez de realmente observar o que eles fazem. As especificações de requisitos estão sempre erradas. O senhor deve criar um protótipo dos requisitos rapidamente e mostrar aos usuários algo concreto para descobrir o que eles realmente precisam.
Agir apenas com base no feedback do usuário é questionável. Por mais bem-intencionado que seja, o senhor está adivinhando. Por que adivinhar quando o senhor pode tomar medidas com base em dados frios e concretos? Agindo com base no feedback do usuário e métricas de uso detalhadas para seu aplicativo ou site – esse é o padrão ouro.
Considere o software da Valve pesquisa de hardware. Um grupo particularmente expressivo de jogadores pode exigir suporte para resoluções widescreen extremamente altas, como 1920 x 1200 ou 2560 x 1600. É compreensível, já que eles gastaram muito dinheiro em equipamentos de jogos de última geração. Mas em quais resoluções a maioria das pessoas realmente joga?
Com base nessa pesquisa com 1,3 milhão de usuários do Steam, cerca de 10% dos jogadores têm telas widescreen de alta resolução. Há outros motivos pelos quais o senhor pode querer atender a essa solicitação, é claro. Esses 10% tendem a ser os jogadores mais dedicados e influentes. Mas ter dados reais por trás do feedback do usuário permite que o senhor examine as ações que toma para garantir que o orçamento de desenvolvimento seja gasto com sabedoria. A última coisa que o senhor quer fazer é desperdiçar um tempo valioso de engenharia em recursos que quase ninguém está usando, e ter dados de uso é a forma de saber a diferença.
A Valve também coleta um conjunto exaustivo de estatísticas de jogabilidade para seus jogos, tais como Team Fortress 2.
Tradicionalmente, confiamos em coisas como o feedback por escrito dos jogadores para ajudar a decidir em quais melhorias devemos nos concentrar. Mais recentemente, o Steam nos permitiu coletar mais informações do que era possível anteriormente. O TF2 inclui um mecanismo de relatório que nos dá detalhes sobre como as pessoas estão jogando o jogo. Estamos compartilhando os dados que coletamos porque acreditamos que as pessoas acharão interessante e porque esperamos detectar problemas emergentes mais cedo e, como resultado, criar produtos e experiências melhores.
O primeiro gráfico, de tempo jogado por classeilustra um problema com o Team Fortress 2 de uma forma que eu acho que nenhuma quantidade de feedback dos jogadores jamais conseguiria.
| Scout | 17.5% |
| Engenheiro | 17.3% |
| Soldado | 15% |
| Demoman | 10.5% |
| Atirador | 10.1% |
| Pesado | 8.5% |
| Espião | 8% |
| Pyro | 7% |
| Médico | 5.5% |
A classe médica é muito pouco representada na jogabilidade real. Suponho que isso se deva ao fato de os Medics não se envolverem em muitos combates diretos, portanto, não são tão empolgantes de jogar como, por exemplo, um Demoman ou Soldier. Isso é lamentável, pois as habilidades de cura da classe médica são frequentemente essenciais para vencer uma rodada. Então, o que a Valve fez? Lançou um conjunto gigante de conquistas específicas para médicos para incentivar os jogadores a escolherem a classe Medic com mais frequência. Isso é um design de jogo iterativo baseado em dados reais de jogabilidade do mundo real.
O uso de métricas detalhadas de jogabilidade para refinar o design do jogo não é algo novo; A Bungie submeteu Halo 2 e 3 a testes abrangentes de laboratório de usabilidade.
Em abril, a Bungie encontrou um problema persistente em Valhalla, um dos níveis multijogador de Halo 3: As mortes de jogadores (representadas em vermelho escuro neste “mapa de calor” do nível) estavam se inclinando para a base à esquerda, indicando que as forças que invadiam pela direita tinham uma pequena vantagem. Depois de analisar essa imagem, os designers ajustaram o terreno para dar a ambos os exércitos uma chance igual.
Novamente… tente imaginar como o senhor descobriria esse desequilíbrio fundamental do mapa com base no feedback dos jogadores. Não tenho certeza se isso é possível.
Certifique-se de que seu aplicativo ou site esteja capturando a atividade do usuário de forma útil e significativa. O feedback do usuário é importante. Não me entenda mal. Mas nunca tome medidas exclusivamente com base no feedback do usuário. Tenha sempre algum tipo de dado de atividade do usuário para corroborar e apoiar o valioso feedback que está recebendo. Ignorar o feedback do usuário pode estar se preparando para um eventual fracasso, mas agir cegamente em relação a cada solicitação do usuário é certo fracasso.