• 14 de julho de 2020
• Blog

Design centrado nas pessoas

Contextualizando

O mundo, como a maioria já deve saber, está em constante evolução. Nosso planeta, nossa sociedade, nossas comunidades mais próximas e até mesmo nossa própria mentalidade mudam da noite para o dia.

Além disso, vivemos em um momento em que as pessoas não querem mais utilizar algo que não atenda às suas necessidades ou algo que elas se sentem obrigadas a utilizar por falta de opção. Esse tempo já passou! Na verdade, dificilmente nos deparamos com algo insubstituível, especialmente quando falamos de produtos digitais (apps, sites, sistemas desktop, sistemas web, totens eletrônicos, redes sociais etc.).

Agora, vamos juntar essa exigência cada vez maior do mercado à necessidade de produtos que realmente olhem para os problemas reais das pessoas. Já deu para perceber por que entender quem vai usar nossos produtos importa?

Ok, mas, o que isso tem a ver com design? Tudo! Como designers, projetamos produtos e/ou serviços para alguém, com intuito de que esse usuário tenha a melhor experiência possível.

Como podemos esperar fazer isso sem entender com o que e, pior, com quem estamos lidando? Que bom que o HCD (Human-Centered Design ou Design Centrado no Humano, ou nas Pessoas, como eu gosto de chamar) está aqui para nos ajudar a construir soluções viáveis, desejáveis e que agregam ao negócio.

Definindo o que é HCD

Beleza, mas, afinal de contas, o que é esse tal de Design Centrado no Humano (HCD) ou, como também é conhecido, UCD Design Centrado no Usuário? Bom, o UCD é uma metodologia de design aplicada nos processos de desenvolvimento de produtos.

Essencialmente, ele nos ajuda a criar soluções que atendam às necessidades de nossos usuários. Ou, nas palavras de um autor muito bacana da área de UCD, Travis Lowdermilk, em seu livro “Design Centrado no Usuário”: “Ao colocar os usuários no centro do processo, estamos eliminando a ambiguidade e chegaremos ao ponto central dos problemas dos usuários”.

Assim, podemos entender o HCD como uma visão focada em resolver problemas das pessoas, colocando quem, de fato, vai utilizar nossa solução no centro de nossos processos e pensamentos.

Ou seja, o HCD é sobre pessoas, não tecnologias. Esse ponto é tão relevante que a própria ISO 13407:1999, que define o processo de design centrado no usuário, traz agora o nome “HUMAN-centered design”, e não mais “USER-centered design”.

Embora essencialmente seja o mesmo processo, esta troca de termo foi feita justamente para enfatizar que devemos pensar em pessoas além das que normalmente pensaríamos como usuários. Por exemplo, quando falamos em lanchas nas praias, qual o usuário vem à sua mente? Se você pensou em quem está conduzindo a lancha, você acertou! Mas esse é apenas o usuário primário da lancha.

Os passageiros dessa lancha são usuários secundários. Podemos ir mais além, pensando nos banhistas que estão na praia e até mesmo nas outras pessoas que estão em outras lanchas — eles podem ser considerados usuários terciários.

Precisamos pensar em tudo o que pode impactar negativamente na percepção das pessoas, até mesmo quando elas não estão utilizando nosso produto. E o HCD nos permite fazer exatamente isso.

Talvez você esteja se perguntando como de fato conseguir colocar as pessoas no centro do processo. Bom, no HCD (ou UCD), existem 4 princípios, que nos ajudam a atingir esse objetivo.

Esses princípios podem ser considerados atividades, mas não necessariamente lineares. Elas se adaptam ao projeto ou produto ou serviço etc. Muitas vezes podemos ir e vir entre elas. Essas atividades são:

• Entender e especificar o contexto de uso;
• Entender e especificar os requisitos de negócio e de usuários;
• Projetar para solucionar os pontos levantados;
• Testar as soluções e avaliar se elas atendem aos requisitos e contextos levantados.

Ao estabelecer essas atividades no processo de desenvolvimento de produtos e serviços, estamos garantimos que estamos produzindo uma solução que agrega valor ao negócio e às pessoas que serão impactadas por ela.

Agora que tal entendermos um pouquinho mais sobre cada uma dessas atividades? Acho que isso vai facilitar o entendimento do HCD.

Entender e especificar o contexto de uso

Nesta atividade, levantamos as características de nossos usuários através de pesquisas, para que possamos entender quem eles são, onde estão e o que estão buscando resolver em seu dia-a-dia.

Além disso, vamos entender quando eles utilizam nossa solução: se estão em casa, se estão na rua e o que estão fazendo. Isso nos permite construir personas para nossos produtos, mapas de empatia e jornadas de usuário, para que possamos nos orientar no momento de concepção da nossa solução.

Quando pensamos em quem vai utilizar nossa solução e, mais do que isto, ouvimos essa pessoa, podemos evitar erros e encontrar falhas e inconsistências de maneira mais rápida e eficaz. Isto diminui o tempo de retrabalho e o investimento em desenvolvimento que possivelmente não traria resultados, já que os desenvolvedores, designers, PMs, POs e demais stakeholders tem um direcionamento mais claro sobre quem vai utilizar a solução.

Entender e especificar os requisitos de negócios e de usuários

Muitas vezes, ao falar de desenvolvimento de produtos, tendemos a especificar listas e mais listas de funcionalidades técnicas e acabamos deixando de observar os objetivos e necessidades do negócio e do usuário.

Quando listamos requisitos funcionais antes de levantar requisitos de negócio ou usuário, estamos dando uma solução antes de entender o real problema das pessoas e como a solução dele pode trazer valor à nossa empresa.

Ao entender os requisitos de negócios, olhamos para os objetivos estratégicos que nossa empresa deseja atingir com determinado produto ou serviço. E, ao olhar para os requisitos dos usuários, entendemos quais as atividades eles esperam concluir com sucesso ao utilizar nossa solução.

Ouvindo as pessoas, podemos pensar em como ajudar o usuário a interagir mais e melhor com o que estamos propondo. Dessa forma, podemos encontrar caminhos para diminuir as chances de que ele fique frustrado por não conseguir utilizar a solução ou não encontrar o que estava buscando.

Projetar para solucionar os pontos levantados

Depois de entendermos para quem estamos projetando — quando e de que forma essas pessoas utilizam nosso produto, quais são os seus problemas reais etc — e quais são os objetivos do negócio, precisamos levantar hipóteses de como atingir esses objetivos e de fato criar a solução.

Desenvolver algo que não agrega valor pode sair muito caro e, para evitar isso, construímos protótipos de baixa, média e alta fidelidade. Com eles, podemos sair de um conceito mais amplo e passar a uma visão mais realista do produto final, permitindo que a ideia seja testada em partes com o usuário final.

Nesse momento, analisamos tudo o que temos para construir o melhor produto possível, olhando também para as variáveis técnicas. Aqui, devemos pensar em quais recursos estão disponíveis para nos ajudar a implementar nossa solução, qual o seu impacto (em tempo e dinheiro) no negócio e quais opções técnicas podem nos ajudar a fazer com que o usuário chegue ao seu mesmo objetivo final.

Não simplesmente chegar ao seu objetivo final, mas chegar ao seu objetivo final da maneira mais intuitiva possível. Como diria um dos grandes nomes da área de UX (User Experience ou Experiência do Usuário, caso você não esteja familiarizado com o termo), Don Norman, em seu livro “Design do dia-a-dia”:

“[…] quando um dispositivo tão simples quanto uma porta precisa de um manual de instruções, mesmo que seja um manual de apenas uma palavra, é um projeto ruim, uma falha”.

Testar as soluções e avaliar se elas atendem aos requisitos e contextos levantados

Agora que definimos como deve ser nosso produto, é hora de levarmos nosso protótipo aos nossos stakeholders. Nessa atividade, avaliamos se a solução que projetamos de fato atende aos objetivos do negócio e procuramos entender se esse produto resolve o problema do usuário no contexto em que ele será utilizando.

Nessa fase, colhemos feedback sobre as hipóteses que levantamos e as validamos (ou invalidamos, o que também é algo positivo). Assim, podemos avaliar se a solução atinge seu objetivo e, principalmente, descobrir o que não funciona antes de implementa-la, evitando, assim, desperdiçar recursos.

Aqui, elaboramos testes de usabilidade para avaliar se as tarefas estão sendo concluídas com sucesso, se o usuário consegue encontrar o que está buscando e se a experiência que ele está tendo é a esperada.

Se descobrirmos que algo não funciona ou que funciona apenas parcialmente, temos a oportunidade de corrigir o percurso do desenvolvimento do nosso produto (ou funcionalidade) antes que ele chegue ao mercado.

No mesmo pensamento, ao validarmos soluções que funcionam, podemos prosseguir com uma segurança maior de que estamos no caminho correto para oferecer uma solução que, de fato, vai ajudar as pessoas e, ao mesmo tempo, melhorar o nosso negócio.

Além disso, segundo a Dr. Susan Weinschenk, da Human Factors International, uma empresa conhecida por implementar CXI (Customer Experience Integration ou Integração de Experiência de Clientes), o retrabalho pode ser evitado 50% das vezes com HCD.

Projetar para necessidades reais de nossos usuários e negócios nos ajuda a ter um caminho mais assertivo e concreto no nosso processo de design e desenvolvimento. Isso, por sua vez, nos ajuda a melhorar produtividade do nosso time de produto (serviços, projetos etc.), já que podemos evitar o retrabalho que resulta da implementação de uma solução inadequada.

Finalizando

Quando paramos para ouvir nossos usuários, temos a oportunidade de encontrar pontos nos quais poderíamos estar míopes estrategicamente. E o melhor de tudo é que, talvez, nossos concorrentes também não tenham encontrado essas lacunas! Ou seja, essa prática pode nos dar uma grande vantagem competitiva.

Ao falar com pessoas reais, que possuem problemas reais, acabamos produzindo insights sobre como conseguir mais fidelidade. E quando falamos em fidelidade nos tempos atuais, não estamos mais nos referindo à ação de recompra, estamos falando sobre defensores de marca, como já disse o pai do marketing, Philip Kotler, em seu livro Marketing 4.0.

Para finalizar, gostaria de ressaltar que o processo de HCD é contínuo e permeia o início, o meio e o fim de uma solução. E sendo assim, ele inclui o processo de desenvolvimento, bem como o time que trará ele a vida.

Então, mesmo que esteja tudo bem com o produto agora, sempre devemos manter essa visão, para que possamos aprimorá-lo e mantê-lo vivo e competitivo no mercado. Afinal, o mundo está em constante evolução, por que nosso produto não deveria mudar para melhor também?

Ficou com alguma dúvida? Gostaria de saber mais sobre algum outro tema da área (ou fora dela, por que não?). Conta pra gente aqui nos comentários.