O Design Centrado no Usuário

Nos últimos anos, a concorrência na indústria de sistemas computacionais causou um aumento na preocupação em desenvolver software de qualidade. O foco nas características, habilidades e dificuldades dos usuários se tornou um fator determinante para o cliente na hora da aquisição de um software.

No entanto, identificar todas essas características humanas não é uma tarefa fácil, pois é preciso pensar e ficar bastante atento a elas desde o início do desenvolvimento.

Os Processos de Software

Na Engenharia de Software (ES), o uso de processos é uma tarefa muito comum, pois adicionam controle ao desenvolvimento, ajudando a fazer estimativas e pontos de decisão importantes para qualquer projeto, mas principalmente para os de médio e grande porte.

Existem diversos modelos de processo de software, onde cada um trata os desafios de desenvolvimento e relacionamento com o cliente de formas distintas, porém, visando os mesmos objetivos:

• Fazer software de qualidade;
• Concluir em tempo viável;
• Obter lucro.

Para saber mais sobre como funcionam esses processos, sugiro que leia uma série de artigos que fiz sobre esse assunto:

Os Processos de Software

Embora esses modelos, geralmente, se preocupem mais com as funcionalidades do que com o usuário e não estejam diretamente relacionados à Interface Humano-Computador (IHC), seu estudo é muito importante. Saber como o processo de desenvolvimento funciona auxilia na descoberta de como aplicar a IHC em cada uma das etapas.

A disciplina defende que não se deve começar a pensar em IHC no meio ou no final do desenvolvimento do sistema, mas sim em cada interação do processo.

Na maioria dos modelos de desenvolvimento, pouco se fala sobre a maneira de se conversar com o cliente, ou quais passos devem ser dados para facilitar a comunicação, com o objetivo de obter informações sobre os usuários e suas necessidades. Isso acontece porque a Engenharia de Software, onde se originaram esses modelos, foca no software e não as pessoas que irão utilizá-lo. A ênfase está nos requisitos do sistema e não nas características dos usuários.

A IHC tem como principal característica preocupar-se com os usuários, observando suas características físicas e cognitivas para utilizá-las na criação do sistema.

A principal meta de uma empresa moderna de desenvolvimento de software é produzir “cases” competitivos no mercado. Isso é feito estabelecendo uma união entre as duas áreas (ES e IHC), a fim de construir um sistema computacional com qualidade.

Muitas dúvidas estão relacionadas à ordem de aplicação de um modelo da ES e das técnicas de IHC. Qual deverá ser aplicado primeiro? Devemos nos preocupar primeiro com o sistema ou com o usuário? A resposta é que devemos aplicar os dois ao mesmo tempo, o modelo e as técnicas. As duas áreas devem ser contempladas em todo o desenvolvimento, pois assim, será possível testar o software de acordo com ES e IHC conjuntamente.

Design Centrado no Usuário

A principal característica da área de Design Centrado no Usuário (User Centered Design ou UCD) é colocar as necessidades do usuário como um todo no centro das decisões. Não importa se são necessidades de requisitos ou necessidades cognitivas, é preciso pensar no usuário final em todo o processo de desenvolvimento. Por isso vários modelos de desenvolvimento incluem a participação do usuário em todo o processo.

É importante não confundir a “participação do usuário” com “obrigação de saber todos os problemas e soluções”. Segundo NIELSEN (2019), “os usuários não são projetistas, e projetistas não são usuários”.

Outro fator importante a se considerar são as situações onde o usuário está envolvido com suas atividades há muito tempo. Por possuir uma prática imensa, realiza as tarefas de maneira “automática”, sem a necessidade de pensar muito. Estes usuários costumam não levar muito em consideração todas as atividades que realizam, e na hora de passar as informações, acabam usando frases muito genéricas como “gostaria de automatizar o controle de estoque” ou “estou com um problema no controle”. Informações genéricas são importantes mas tem pouco significado. É preciso entender mais profundamente a regra do negócio, ou seja:

• Como é feito o controle de estoque?
• Quais são as atividades mais importantes?
• Quais são as atividades menos importantes?
• Quais são as dificuldades?
• Qual processo é mais simples?
• Qual processo é mais complexo?

O que você quer?

Outro erro é perguntar diretamente aos usuários “o que eles querem”, pois embora eles saibam que a tecnologia pode ajudar a amenizar ou resolver seus problemas, eles não são projetistas.

Duas frases se encaixam perfeitamente nessa realidade. A primeira é de Henry Ford, o homem que revolucionou a fabricação de automóveis:

“Se eu perguntasse aos consumidores o que queriam, eles teriam dito: um cavalo mais rápido!”

A segunda frase relevante é de Steve Jobs:

“As pessoas não sabem o que elas querem até que você mostre para elas.”

Evitar a pergunta “o que você quer” é importante, porque os usuários não conhecem a tecnologia e todo o seu potencial. Esse papel pertence aos projetistas de software, que tem o conhecimento necessário da tecnologia. Todavia, para descobrir a melhor maneira de usar a tecnologia, é preciso entender o usuário, suas necessidades e problemas.

O UCD se preocupa em promover a colaboração entre o projetista e o usuário (que pode ser o próprio cliente ou um funcionário que usará o sistema). Tanto o projetista como o usuário possuem conhecimentos que devem ser compartilhados. Claro que no seu devido contexto, pois o projetista não precisa explicar ao cliente sobre linguagem de programação.

A comunicação com o usuário tem a finalidade de ser uma ferramenta de extração de conhecimento, para que seja possível entender como ele executa suas atividades. As informações sobre como o fluxo de trabalho acontece na empresa do cliente é muito importante para planejar o sistema, mesmo que várias dessas informações nunca se tornem funcionalidades. Entender a regra de negócio é primordial!

Segundo WILLIAMS (2009), o UCD abrange várias áreas, dentre elas:

• IHC: com sua preocupação em entender as características físicas e psicocognitivas dos usuários, os fatores humanos etc;
• Engenharia de Usabilidade: que se preocupa em entender os objetivos dos usuários, desenvolver interfaces para eles etc.

Assim como nos Modelos de Processos de Software, o UCD também possui algumas etapas para auxiliar o projetista nesse contato com o usuário, permitindo um melhor entrosamento, compreensão e colaboração.

1. Pesquisa de Design

Esta primeira etapa é subdividida em alguns passos:

a) Planejamento

Neste passo é onde identifica-se o objetivo, as restrições e as suposições do projeto. Essas informações são obtidas com os usuários, por isso há necessidade de se definir quem são os stakeholders, ou seja, as pessoas envolvidas nas regras o negócio que se deseja entender.

Os stakeholders não são apenas os usuários finais dos sistemas (empregados), mas também os donos da empresa ou outras pessoas que estejam ligadas com o problema a ser resolvido, mesmo que nunca precisem usar diretamente o sistema.

Definir os stakeholders é muito importante para conduzir o projeto até o final pois, conhecendo as pessoas envolvidas, será possível conversar e mostrar resultados de acordo com a característica e necessidade de cada um. Enquanto uma pessoa do departamento de Marketing está preocupada em apresentar e vender o produto, uma pessoa do departamento Financeiro está preocupada em contabilizar tudo o que está acontecendo, sendo assim, a conversa e a forma de exibir os resultados para cada uma será completamente diferente.

b) Condução

Este passo objetiva conduzir a investigação na empresa, onde um projetista irá conhecer as atividades das pessoas e como elas realizam suas tarefas.

Antes de conversar diretamente com o usuário, é preciso conhecer um pouco da empresa e da linguagem que é utilizada entre as pessoas. Também é muito importante permitir que as pessoas conheçam o projetista, pois isso permitirá um entrosamento. As pessoas precisam sentir liberdade para falar dos problemas e das coisas que gostam ou não, sem a preocupação de serem avaliadas.

No geral as pessoas sentem medo de serem avaliadas, pensando que se “falarem mal” de algum processo ou atividade da empresa, o chefe ficará sabendo e elas poderão ser demitidas. Em contrapartida, se a pessoas passam a conhecer o projetista e a confiar nele, elas perceberão que ele está na empresa para ajudá-las. Dessa forma, saberão que ele precisa entender o que está acontecendo, quais são as dificuldades e as facilidades do processo, e que todas essas informações são importantes para aprimorar e facilitar as tarefas que elas estão realizando.

Antes de tudo, o projetista deve se esforçar para conhecer as pessoas e conversar com elas. Tomar um cafezinho ajuda bastante, afinal, um ambiente descontraído pode ser de grande valia nesse momento. Essa estratégia, chamada de Background Research, afirma que uma pesquisa, com o objetivo de conhecer as pessoas, não precisa ser formal, podendo ter uma ambientação descontraída, porém profissional e com um objetivo definido.

Existem várias maneiras de fazer as pesquisas, cada uma com uma abordagem diferente:

• Entrevistas face-a-face: com essa abordagem você pode conversar com a pessoa pessoalmente, fazendo perguntas e ouvindo suas respostas “face a face”, sem a necessidade de outros recursos, como formulários de papel, por exemplo. É importante planejar antecipadamente a entrevista, elaborando perguntas interessantes. Ao contrário do que acontece quando respondem no papel, as perguntas podem sofrer alterações dependendo das respostas, pois através delas você pode ter interesse em conhecer mais detalhes de um determinado assunto. Nesta modalidade existe a possibilidade de gravar a entrevista, desde que você tenha a permissão da pessoa para isso, para não constrangê-la;
• Perguntas abertas e fechadas: é uma entrevista, que acontece com o auxílio do papel, por meio de um questionário. Você define algumas perguntas, que podem ser objetivas (fechadas) ou dissertativas (abertas), para que as pessoas respondam. Exemplos de perguntas fechadas são: “Quantos anos você tem?” ou “Qual seu cargo na empresa?” fazendo que a resposta seja muito objetiva. Já as perguntas abertas são mais livres, fazendo que a pessoa formule respostas mais longas. Essa estratégia é muito utilizada quando existe a necessidade de entrevistar uma quantidade grande de pessoas. Se fosse entrevistar pessoalmente uma por uma, precisaria de tempo e dinheiro. Por isso, quando é necessário entrevistar várias pessoas, alguns projetistas costumam aplicar esse questionário para obter uma média com base nas respostas. Com as médias estabelecidas, o projetista pode fazer uma entrevista Face-a-face com algumas pessoas, para saber mais detalhes ou esclarecer algo que ficou pendente;
• Entrevistas remotas: ocorre quando você não tem a possibilidade de um encontro presencial com a pessoa, então, a entrevista pode ser feita utilizando o telefone, a internet ou qualquer outro meio que lhe permita ter contato com ela. Essa técnica é utilizada, por exemplo, quando a pessoa que se deseja entrevistar está viajando para participar de uma reunião de negócios;
• Entrevista pessoal: nesta modalidade, o projetista faz uma pergunta para a pessoa e ela responde fazendo uma determinada atividade, ao invés de responder com palavras (falando ou escrevendo). Ou seja, se você pergunta como é feito um determinado processo, ela explicará realizando esse processo. Por meio dessa entrevista pode-se acompanhar todos os detalhes, desde o comportamento do indivíduo até os objetos que ele utiliza para a atividade.

Todas as perguntas elaboradas devem levar em consideração a função e especialidade de cada stakeholder, podendo-se agrupar pessoas de acordo com sua especialidade na empresa.

Após a utilização das técnicas explicadas aqui, o projetista terá conhecimento sobre as pessoas, suas atividades, a maneira que elas pensam, entre outras características. Porém, um cuidado importante é necessário na hora de projetar o software, pois é comum entre os projetistas tentar aproveitar todo o processo manual e aplicar no computacional, tornando o sistema meramente uma reprodução das atividades que as pessoas realizam manualmente. Embora, através da técnica, se saiba como as pessoas desempenham as atividades, é preciso entender que o computador tem um potencial muito grande e o objetivo de um sistema não é somente reproduzir a vida das pessoas, mas sim facilitá-la (KEINONEN, 2008).

c) Análise

O terceiro passo consiste em analisar todos os dados coletados nos passos anteriores, com a utilização de várias técnicas descritas na literatura como Análise Quantitativa e/ou Qualitativa (WILLIAMS, 2009). O projetista deverá organizar todas as informações, decidir quais são as prioridades, o que deve ser feito, o que precisa ser mudado, suas propostas, enfim, todas as informações necessárias para, depois, conversar com as pessoas.

d) Reporte

Esse passo é justamente a conversa com as pessoas sobre tudo o que foi coletado e analisado sobre essas informações. Você pode fazer uma apresentação e/ou escrever um relatório com os principais dados.

Como já são conhecidas as necessidades e a linguagem da empresa, é importante utilizar essas informações na apresentação para que as pessoas compreendam e se interessem pelo que vai ser falado. Também é importante considerar o stakeholder, ou seja, se a conversa envolver alguém da administração, planeje algo utilizando uma linguagem própria e assuntos que vão interessar às pessoas dessa área.

2. Desenho

É a segunda etapa do UCD, onde ocorre a consolidação de todas as informações obtidas até esse momento. Pode ser realizada por meio dos primeiros desenhos da interface. Esses desenhos são feitos de acordo com as informações obtidas e pelas conversas feitas durante esta etapa.

Há várias formas de fazer esse primeiro esboço, uma delas é chamada de Prototipagem, que será abordada em outro artigo. Nela a interface é desenhada pensando em como será a interação entre o sistema e o usuário, definindo a navegação que acontecerá, além de outras características.

3. Avaliação do Desenho

Terceira e última etapa do UCD, essa etapa avalia tudo o que foi investigado, desenvolvido e representado por meio do Desenho.

A avaliação pode ser feita com auxílio do usuário, certificando que tudo o que foi planejado e realizado está de acordo com as necessidades e as características do usuário. Se o indivíduo entender o Desenho e conseguir trabalhar com ele, mesmo por intermédio de protótipos, a possibilidade de interagir com a ferramenta computacional será bem maior, ou seja, a certeza de construir um sistema com qualidade é elevada.

A Avaliação do Desenho também pode ser feita sem a ajuda do usuário, aplicando estratégias que indicam se o usuário conseguirá utilizar o sistema de modo eficaz ou não. Algumas estratégias para realizar a avaliação são:

• Heurística;
• Questionário de satisfação;
• Percurso cognitivo;
• Revisão pelos usuários;
• etc.

Apesar de parecer simples conversar com uma pessoa para explicar o que se pretende fazer no software, quais serão as atividades e tudo mais, não é uma tarefa fácil, pois ambos (projetista e cliente) possuem conhecimentos e experiências diferentes.

Entregando valor para o cliente

Os usuários tendem a valorizar mais os sistemas que possuem uma interface boa e utilizável. A forma de utilizar o sistema, quase sempre, é mais importante do que a quantidade de funcionalidades e recursos existentes. Em outras palavras, existe uma clara vantagem competitiva entre sistemas que se preocupam com o usuário e os que se preocupam apenas com as funcionalidades.

Outra vantagem, que só é percebida após a entrega do sistema, é a minimização dos custos posteriores. Geralmente há uma preocupação com os custos que envolvem o desenvolvimento do software, porém, é necessário colocar este quesito na balança para medir o que será, de fato, mais caro:

Um custo único para investir no desenvolvimento do software contemplando as técnicas de IHC, focando sempre no usuário para gerar um software fácil e compreensível;

ou

Um custo periódico para treinar cada novo usuário que entre na empresa, pois sem a preocupação com IHC, o software não pode ser facilmente compreendido, e o usuário não consegue usar o sistema sem orientação prévia.

Pensar no usuário em todo o processo e testar exaustivamente o software para garantir a qualidade é uma tarefa aparentemente árdua, mas é uma estratégia comprovadamente eficaz para garantir um sistema aceitável e usável.

Nos próximos artigos, abordarei mais informações sobre como trabalhar para produção de um software que satisfaça as necessidades do cliente. Espero que o conteúdo seja útil. Um grande abraço e até a próxima!

Leia também o próximo artigo sobre o assunto:

Prototipagem de Software

Leia todos os artigos desta série:

• Interface Humano-Computador
• A História da Interface
• Usabilidade e Qualidade
• Design Centrado no Usuário
• Prototipagem de Software

Referências para Aprofundamento:

KEINONENM, T. User-centered design and fundamental need. Lund — Suécia. The 5th Nordi conference on Human-computer
interaction: building bridges, 2008.

NIELSEN, J. Bridging the Designer–User Gap. Disponível em: <http://www.useit.com/alertbox/designer-user-differences.html>.
Acesso em: 22 jun. 2019.

WILLIAMS, A. User-centered design, activity-centered design, and goal-directed design: A review of three methods for designing
web applications. Bloomington — EUA In: Special Interest Group on Design of Communication (SIGDOC), 2009.