What is Human-Centered Design?

Vou falar sobre um
padrão internacional chamado *design centrado no ser humano*. As pessoas se referem a isso como "design centrado no usuário", mas há uma boa razão para o rótulo humano. E esse é o fato de que, quando usamos palavras que fazem as pessoas soarem como outro componente do sistema, como a palavra "usuário", na verdade as estamos desumanizando. Esse é um argumento que Simon Baron-Cohen faz em seu livro 'Zero Empathy', falando sobre o fato de que em muitas situações desumanizamos nossos inimigos para poder tirar proveito da falta de preocupação com eles. Agora, não estou falando de usuários como inimigos! Mas estamos fazendo isso *inadvertidamente* quando falamos de "usuários". E, até certo ponto, é inevitável. Sabe, precisamos colocar um rótulo nessas pessoas. Mas é um dos principais argumentos, por exemplo, no uso de personas, que substituamos funções ou usuários por nomes reais de pessoas porque isso nos dá uma chance muito maior de promover empatia, promovendo uma compreensão de sua situação e suas necessidades e comportamentos. Portanto, os principais recursos do design centrado no usuário:
*envolvimento direto com os usuários*.

Se alguém me perguntasse qual era a *principal característica* do design centrado no usuário, essa seria a minha resposta: que você realmente precisa sair e pesquisar, entender, interagir com usuários reais. E você precisa fazer *observação*
– então, isso é observá-los trabalhar. E acho que a observação é uma ferramenta fantástica
e realmente não fazemos o suficiente. Podemos fazer pesquisas de muitas, muitas maneiras,
incluindo questionários e entrevistas – talvez não tão eficazes quanto a observação, mas têm suas vantagens em muitos casos. E então, finalmente, *avaliação* – e isso é realmente fundamental. Se você não fez nenhuma dessas outras coisas,
avaliar com os usuários pelo menos lhe daria uma ideia se você tem problemas ou não.

Mas o argumento que vou apresentar é que a avaliação por si só é realmente uma solução bastante ruim para o problema geral de onde vem a usabilidade ruim. Então, vamos dar uma olhada em alguns desses outros pontos. Precisamos pesquisar e entender o contexto de uso. É um rótulo muito poderoso porque é bastante autodescritivo. Os contextos de uso são
tudo sobre como os sistemas são realmente empregados no mundo real. E eu vou te dar alguns exemplos. Uma delas são as diferenças de uso no contexto de uso entre um sistema de ponto de venda em algo como um pub ou um café versus um supermercado. O equipamento pode ser virtualmente idêntico. O software também pode ser muito semelhante. Mas o uso real desses sistemas não poderia ser mais diferente. Em um supermercado, você tem um cliente por vez – a pessoa para quem você está realmente fazendo o check-out. E *existe* um usuário por vez.
O usuário é o operador de checkout. E essa pessoa pode ter que passar por cem ou mais itens das compras semanais de alguém.

Mas existem fatores importantes que são apenas um cliente e muitos itens, e isso precisa ser feito com bastante eficiência. E normalmente não há nenhuma complicação de precisar mudar para um cliente diferente
no meio do processo. Por outro lado, a situação é totalmente invertida em um bar ou café ou algo semelhante. Você tem *muitas* pessoas compartilhando o
sistema de um ponto de venda e elas precisam ser capazes de alternar entre clientes muito rapidamente, e também precisam alternar entre usuários muito rapidamente.

E a coisa toda não poderia ser mais diferente. E se você tentasse impor o sistema de supermercado em um café ou o sistema de café em um supermercado, provavelmente não sairia impune. Seria apenas um fracasso horrível, horrível. Outras questões relacionadas com os contextos de utilização –
muitas vezes imaginamos que estamos a desenhar para pessoas numa situação semelhante à nossa onde – por exemplo – estamos num ambiente limpo, seco e quente
, tipicamente um ambiente de escritório. Mas assim que você começa a olhar mais longe, assim que você começa a olhar para armazéns ou fábricas, os contextos de uso são muito diferentes e você precisa projetar seus *sistemas* de maneira diferente. Às vezes, isso significa usar hardware diferente. Às vezes, significa *apenas estar ciente* dos contextos de uso em termos de como você escreve a interface do usuário ou como você projeta a interface do usuário. Assim, o foco principal do design centrado no usuário é a adequação de soluções para *usuários reais* em *contextos reais de uso*, não aqueles que estamos imaginando.

É um diagrama bastante direto, na verdade. Começamos identificando a necessidade de design centrado no usuário. Na verdade, deixei isso fora do gráfico porque, na minha opinião, se você está criando sistemas interativos,
precisa usar o design centrado no usuário. Assim, começamos no topo
com *contextos de pesquisa de uso*. Passamos a *especificar os requisitos do usuário*. Finalmente, na parte inferior, *produzimos algumas soluções de design*. E então, às nove horas aqui, avaliamos essas soluções em relação aos requisitos iniciais. E fazemos isso com várias ferramentas. Mas um deles, é claro, seria o *teste de usabilidade* – testar com usuários reais. E dependendo de como for, você pode ter que voltar e começar de novo com seus contextos de uso. E isso certamente já aconteceu comigo mais de uma vez, que um cliente para o qual desenvolvo software não me *falou* sobre um contexto de uso, e só descobrimos durante o teste, que é uma um pouco tarde no dia.

Ou você pode ter que voltar a apenas ajustar os requisitos do usuário. Esperançosamente, você só precisa voltar até ajustar a solução de design. Então, você contorna esse loop até poder sair do lado esquerdo aqui com a caixa Atende aos requisitos naquele design específico. O ponto principal que estou fazendo sobre isso é que, se você se concentrar apenas na
atividade de avaliação que marquei aqui, geralmente com testes de usabilidade, na verdade não estará fazendo nada para melhorar a usabilidade do seu processo.

Você ainda está criando designs ruins. E apenas filtrá-los será um
desperdício fantástico em termos de quantidade de esforço. Então, se você pensar nisso como uma linha de produção, temos essa analogia de fabricação e falamos sobre parafusos. Se você decidir que seus produtos não são realmente bons o suficiente por qualquer motivo – eles não são consistentes ou quebram facilmente ou qualquer número de problemas potenciais – e tudo o que você faz para melhorar a qualidade de seu produto é aumentar a verificação de qualidade em no final da linha de montagem, então adivinhem? Você acaba com muito desperdício porque ainda está produzindo um grande número de parafusos defeituosos. E se você não fizer nada para melhorar o processo real de fabricação dos parafusos, então apenas apertar o processo de avaliação – levantando o obstáculo, efetivamente – realmente não é o caminho a percorrer.

As avaliações de usabilidade são uma ferramenta muito importante. O teste de usabilidade, em particular, é uma ferramenta muito importante em nossa caixa de ferramentas. Mas realmente não pode ser o único. E isso é algo que precisamos levar em consideração desde o início. A outra questão que devo mencionar é que muitas vezes perdemos coisas que não percebemos quando projetamos isso – que haveria usuários ou clientes em contextos de uso específicos que precisavam de requisitos ligeiramente diferentes.

Lembro-me de um projeto em que fui desencorajado a falar com um determinado usuário porque a empresa o considerava problemático. Na verdade, ele era um usuário interno.
Não era um cliente externo. E a razão pela qual ele era
problemático é que suas *necessidades* eram diferentes da maioria das outras necessidades de
seus colegas na organização. Mas foi por um bom motivo – ele era
responsável por um determinado mercado e esse mercado era apenas diferente do
resto dos mercados daquela organização. Então, não pensamos em construir uma solução que atendesse às suas necessidades. E, claro, quando ele começou a
usar, ele disse: "Mas como eu…?" ou "Onde está…?" e todos os tipos de boas perguntas como essa.

E foi apenas ausente. E, claro, você não pode fazer testes ou avaliações de usabilidade em coisas que você realmente não construiu. Portanto, há outro bom motivo para garantir que seu processo seja focado nos usuários e não apenas na sua avaliação. Um resumo dos passos a serem seguidos no design centrado no usuário – e é disso que se fala no padrão internacional. *Equipes multidisciplinares* – você vai conseguir pessoas que não estão focadas estritamente em tecnologia.

Então, você pode melhorar a empatia dessa maneira. Você certamente pode obter uma melhor resolução de problemas porque ter pessoas com diferentes
tipos de experiências ou conhecimentos é uma maneira muito melhor de resolver problemas do que muitas pessoas que estão acostumadas a pensar sobre questões , digamos, de uma forma orientada para o computador. Precisamos pesquisar as necessidades dos usuários e seu contexto de uso. Precisamos produzir protótipos *o mais cedo possível*. Mas precisamos produzir protótipos, talvez protótipos de baixa fidelidade, até mesmo protótipos de papel, e apenas garantir que nossas ideias sejam sólidas. E precisamos testá-los
de forma realista com usuários em potencial. Por último, mas certamente não menos importante, precisamos de
*prazos para permitir feedback e alterações de design*. O que precisamos fazer? Bem, conscientize todos os membros da equipe sobre os fundamentos do design para usuários. E acho que isso é fundamental. Acho que não ajuda muito ter pessoas que não entendem por que precisamos ter personas, para entender por que precisamos considerar a solução desse problema para outras pessoas – essas pessoas que talvez não sejam tão boas em sistematizar ou entender sistemas.

Precisamos melhorar a conscientização sobre ferramentas e técnicas de design focadas no usuário para que as pessoas saibam que "Ei, isso parece ser um problema. Talvez devêssemos chamar alguém para examinar isso. Ou devemos realizar um estudo para ver qual é a melhor solução neste caso particular." E então, finalmente, precisamos integrar melhor o design de interação no ciclo do projeto..

Texto inspirado em publicação no YouTube.

Quer Saber Muito Mais? Venha para a MIND21 Educação