Quando um produto ou serviço chega a uma fase em que precisa de mudar, seja porque a tecnologia na qual se baseia está obsoleta ou simplesmente porque o mercado mudou, é uma tentação avançar diretamente para a fase de desenho. No entanto, quando se cumpre esse desejo, há sérios riscos que se assumem, especialmente quando se trata de algo complexo, como um site ou uma aplicação.
Não que haja algum mal nessa vontade de ver as coisas a acontecer, pelo contrário: é estimulante e implica alguma abertura de espírito para aceitar coisas novas, ou até mesmo pelo simples facto que é preciso mudar.
Mas mudar o quê?
Mudar o visual? Mudar o menu? Criar novas funcionalidades? Mudar o tom de voz? Afinal, é mais complicado do que parece à primeira vista. É aqui que as opiniões das pessoas envolvidas começam a moldar o projeto, e essas opiniões ou ideias dos stakeholders podem ser um pouco enviesadas. Afinal de contas, eles lidam todos os dias com o produto ou serviço. Serão eles uma representação dos utilizadores reais? Não me interpretem mal, o contributo dos stakeholders é valioso quando é usado no contexto certo e até é aconselhável envolvê-los nesse processo de transformação, mas vamos separar as águas. Uma coisa é a visão do negócio de quem o gere no dia-a-dia, e outra coisa é a visão de quem realmente usa o produto ou serviço que resulta desse negócio.
Assim, graças à ânsia de mudar, o que acontece, na maior parte dos casos, é que se saltam etapas demasiado importantes para serem descartadas.
Primeiro, user research, por favor
Para conseguirmos compreender o ponto de vista dos utilizadores e quais as suas necessidades, é preciso distanciarmo-nos de ideias pré-concebidas dos colaboradores sobre os produtos ou serviços da sua empresa – eles não são os utilizadores.
Para tal acontecer, fazemos user research para descobrir o que os utilizadores fazem num determinado contexto, porque o fazem e o que sentem nessas ocasiões.
Vejamos agora o exemplo do Nuno, que gere uma empresa municipal de transportes coletivos. Apesar de estar orgulhoso da app da sua empresa, quer renová-la – diz que, para além de ter um ar ultrapassado, recebe muitas reclamações do seu mau funcionamento.
De que forma podemos ajudar a melhorar o desempenho da empresa e a forma como é vista pelos seus clientes?
O Nuno fez algum trabalho de casa e até já tem uma lista de funcionalidades que anseia ver na sua app. Até disse que já nos poupou trabalho!
Como é que podemos responder ao Nuno?
Opção A: Ouvimos com muita atenção quais são as ideias e sugestões do Nuno e dos seus colaboradores mais próximos – afinal de contas, eles conhecem a empresa melhor do que ninguém. Como temos muita experiência a desenhar interfaces, apresentamos-lhe uma app com um visual “moderno”, cheia de funcionalidades e um manual de instruções.
Opção B: Para além de ouvirmos as ideias e sugestões do Nuno e dos seus colaboradores, vamos:
- Pedir-lhes alguns dados analíticos sobre a utilização da app para saber que funcionalidades estão a ser mais e menos usadas;
- Analisar e categorizar as reclamações que receberam;
- Observar os utilizadores dos seus autocarros;
- Entrevistar alguns utilizadores para tentar saber o que eles sentem antes, durante e depois de usar o meio de transporte no dia-a-dia.
A ideia é perceber todo o contexto envolvente, necessidades específicas das pessoas, encontrar padrões e, no final, apresentar uma app que responda às reais necessidades dos utilizadores.
Os riscos de não fazer user research
Ilustração: Gualter Amaro.
Quais os riscos de escolher a opção A?
- Perder tempo e dinheiro a desenvolver funcionalidades que ninguém vai usar, porque simplesmente não ajuda os utilizadores a resolver nenhum problema.
- Ter uma app difícil de usar, porque o desenho que ditou o seu funcionamento passou diretamente do computador do designer para o do programador e não foi testado com utilizadores – nunca é demais repetir que nós, designers, developers, product owners, product specialists, não somos os utilizadores.
Por outro lado, se escolhermos a opção B, facilmente percebemos que, a longo prazo, vamos poupar dinheiro e esforço, porque desenhámos uma solução que responde quer aos objetivos de negócio, quer às reais necessidades dos utilizadores.
E como explicar ao cliente que deve deixar cair as suas ideias?
Se conseguirmos explicar antecipadamente o valor de fazer user research e se houver aceitação, já é um bom princípio. Mas existem algumas técnicas para aumentar o buy-in dos stakeholders – a chave é envolvê-los no processo. Podemos, por exemplo:
- Organizar um workshop para que ajudem a identificar os utilizadores dos seus produtos ou serviços, e como satisfazem atualmente as necessidades de cada uma das personas ou proto-personas que emergem deste workshop;
- Convidar alguns stakeholders a assistir a determinadas atividades de user research – por exemplo, um artigo do Nielsen Norman Group refere que fazer testes de usabilidade é, por si só, uma forte ferramenta de persuasão e ajuda a colocar toda equipa no caminho certo;
- No final, vamos confrontar a visão dos stakeholders com as necessidades dos utilizadores – é muito provável que existam ideias que simplesmente não coincidem com as necessidades dos utilizadores e outras ideias novas que surgem nesta fase de descoberta. Se houver participação dos stakeholders e se houver uma comunicação eficaz dos insights obtidos, a aceitação será muito mais natural. Podem saber mais sobre como envolver os clientes neste artigo do nosso blog.
Contudo, as atividades de user research não terminam quando começa o desenho da aplicação. Por exemplo, na fase de arquitetura de informação é frequente fazerem-se atividades de card sorting com os utilizadores para nos ajudar a estruturar os conteúdos segundo o mapa mental de quem vai realmente usar a aplicação.
Também devemos envolver os utilizadores durante a fase de design de interação, não no seu desenho, mas sim a testá-lo usando um protótipo. Quem é que nunca clicou num botão e teve um resultado completamente inesperado? Quem é que nunca teve dificuldade em preencher um formulário online porque os erros não paravam de surgir? Ou quem teve dificuldade em encontrar um determinado conteúdo, simplesmente, porque não está onde esperava? São questões como estas que podem ser evitadas se contemplarmos algumas sessões de testes de usabilidade durante o desenvolvimento do projeto, minimizando problemas inesperados na utilização da aplicação.
Por estas e mais algumas razões, devemos parar e pensar se não estaremos a mudar depressa demais, e começarmos a incluir atividades de user research e UX em geral, porque nos ajudam a colocar no mercado produtos e serviços mais robustos, apetecíveis e fáceis de usar. No fim, ganham os clientes e ganham as empresas.
Se este artigo lhe fez soar alguns alarmes, venha saber como orquestrar as atividades de UX e tirar partido da metodologia User-Centered Design com a Certificação Internacional UX-PM.