Pode o design centrado no utilizador induzir em erro?

Não é fora do vulgar trabalharmos sob o pressuposto de que pessoas diferentes executam tarefas de forma... diferente. As pessoas que criamos para representar os nossos utilizadores ajudam-nos a ter em mente o nosso público — as suas preferências, perfis demográficos e conhecimentos técnicos. Mas e se as personas não forem a resposta para tudo?

A Comrade colaborou num estudo que analisou a taxa de adoção do depósito móvel de cheques, um recurso oferecido por vários bancos que permite aos seus clientes depositarem cheques bastando para isso tirar uma fotografia com o telemóvel. Analisamos vários fatores, incluindo diferentes pessoas, e chegamos a uma conclusão surpreendente: os resultados eram os mesmos, independentemente do utilizador. O uso das diferentes pessoas parecia irrelevante: utilizadores de diferentes faixas demográficas, com diferentes conhecimentos técnicos, rendimentos, etc. apresentavam os mesmos resultados. Aparentemente, o que interessa não é quem usa o recurso, mas sim a natureza da própria atividade.

A introdução do Design centrado no utilizador

O Design centrado no utilizador (ou UCD, User-Centered Design, em inglês) está entre nós há tanto tempo que já praticamente nos esquecemos como era o mundo antes da sua introdução. Nesses tempos, a tecnologia parecia algo mágico. Era difícil por ser tão poderosa, e o seu difícil processo de aprendizagem fazia parte da luta pelo direito de ter esse poder. Foi pedido aos utilizadores que adotassem as tecnologias e as ferramentas apresentadas pelos engenheiros, como se estas fossem entregues por uma entidade superior.
 
O termo Design centrado no utilizador foi criado em meados da década de 1980 por Donald Norman e, desde então, colocar o utilizador no centro do design tornou-se não só aceitável como também inquestionável. O uso de pessoas, testes de utilização, o desenvolvimento conjunto de aplicações e o co-design alteraram profundamente o processo de design. Foram os focus groups e não as equipas de engenharia que determinaram que funcionalidades deveriam estar presentes nos produtos. Após décadas de produtos tecnológicas que obrigavam os utilizadores a adaptarem-se aos mesmos, finalmente integramos empatia no nosso processo de design e, com isso, tornou-se possível executar o design colocando o utilizador em primeiro lugar.

Não é “quem”, é “o quê”

Em 2005, Don Norman publicou um artigo com o título “O design centrado nas pessoas é considerado prejudicial”. Neste artigo e noutro que lhe deu continuação, Don pôs em causa a noção de que a abordagem correta do design passava por perguntar aos utilizadores o que queriam e dar-lhes isso mesmo. A proposta de Norman consistia em expandir as possibilidades do UCD através do Design centrado na atividade (ou ACD, Activity-Centered Design, em inglês).
 
De acordo com esta proposta, o UCD, e principalmente a forma como era implementado, tinha-se tornado demasiado limitado e centrava-se nas diferenças e necessidades pessoais de tipos específicos de ecrãs e interfaces. Como consequência, perdeu-se o contexto mais alargado das interrupções, objetivos incorretamente estabelecidos, motivações contraditórias e condições ou necessidades inesperadas. O ACD não refuta o valor da empatia e dedicação para com o utilizador, valor central do UCD, mas aumenta este valor abordando temas esquecidos pelo UCD.
 
As prioridades do Design centrado na atividade, ou ACD, não são as diferentes faixas etárias, psicologia e competências tecnológicas de um determinado utilizador, mas sim o contexto e a composição das atividades, ou seja, o grupo de tarefas, objetivos, regras e ferramentas comuns. Não será isto um retrocesso que resulta em mais design baseado em tarefas? Não necessariamente, porque as atividades são mais do que meras tarefas. “Enviar um e-mail” pode ser uma tarefa, mas pode também ser apenas parte de uma atividade maior, como por exemplo “tratar da correspondência”, que inclui ler novos emails, perceber a quem se deve responder com prioridade e atualizar a lista de contactos.
 
O UCD estabelece que a tecnologia deve adaptar-se aos utilizadores e não o contrário. O ACD reconhece que as pessoas têm efetivamente que se adaptar à tecnologia. Senão vejamos o caso do relógio, por exemplo. A medição e monitorização mecânica do tempo mudou quase completamente a forma como passamos os nossos dias. Não há dúvidas de que nos adaptamos à tecnologia como qualquer outro elemento no nosso ambiente.
 
Enquanto que o UCD centra-se exclusivamente nos participantes (nomeadamente os utilizadores diretos) e nas tarefas individuais, o ACD vê estes elementos como pequenas partes de um todo cujo objetivo é satisfazer as necessidades das pessoas – necessidades muito mais complexas do que simplesmente concluir com sucesso uma situação de uso. Ferramentas, regras, outros participantes em tarefas relacionadas... tudo isto faz parte de um determinado contexto frequentemente esquecido pelo UCD.

Prestar atenção a um contexto mais vasto

Portanto, deveríamos nós, designers, abandonar as nossas práticas de UCD? Claro que não, mas temos que começar a colocá-las num contexto mais vasto. É algo que já se pode verificar na área de Design de serviços. Os mapas dos percursos de cliente levam em consideração diversas tarefas conjugadas de formas diferentes, com vários pontos de contacto, e muitas vezes durante um período alargado e com diversos contactos. Os modelos de ecossistema representam o contexto de vários sistemas, ferramentas, processos (controlados ou não), e regras que compõem o contexto de uma atividade . São prismas que nos permitem ver o contexto das atividades.
 
Para além do que já estamos a fazer, quem faz o design de Experiências de Utilizador (UX), Experiências de Cliente (CX) e de outras soluções, tem ainda mais algumas coisas por fazer. Antes de mais, temos que começar a pensar nas atividades e a representá-las tal como fazemos atualmente com as pessoas O modelo que aqui apresentamos é apenas uma das estruturas que pode ser utilizada, mas tal como existem várias maneiras de cristalizar uma pessoa, existem também várias maneiras de encapsular atividades. Vamos dar asas à criatividade (é nisso que somos bons): agora temos é que ficar bons a compreender a disponibilidade dos nossos clientes, dos clientes deles, dos seus setores para utilizarem o ACD e os produtos individuais que estamos a conceber.

Nem todos os projetos estão preparados para isto. O ACD é o passo seguinte numa curva de maturidade e é muito difícil ignorar passos de forma eficiente.

Vejamos o caso do iPhone. Em 2007, quando o conceito de “smartphone” era completamente novo, nem sequer éramos capazes de aplicar um Design centrado nas pessoas (quem seriam as pessoas? Para que querem este dispositivo?), muito menos um ACD (que atividades podem ser executadas neste dispositivo?) no design de um produto como o iPhone. Neste caso, o fator preponderante FORAM mesmo as capacidades, o que claramente não durou muito tempo.

Se olharmos para este exemplo e depois para o estudo sobre o depósito móvel de cheques, as conclusões tornam-se um pouco menos surpreendentes e muito mais fáceis de compreender. Houve algo mais importante do que os próprios utilizadores: a atividade. Se conseguirmos desenvolver as práticas de ACD tal como fizemos com as de UCD, iremos não só conseguir resolver os problemas dos utilizadores, como também abordar as necessidades reais das pessoas. E haverá algo mais humano do que isto?

---