Um guia explicativo dos fundamentos do design de UX.
Neste artigo, apresentamos um fluxo de trabalho que pode ajudar equipes, produtos, startups e empresas a criar um processo robusto e significativo para desenvolver uma melhor experiência do usuário para os clientes. É possível usar partes diferentes do processo separadamente, mas, idealmente, elas funcionam melhor como uma série de etapas.
Este guia usa muito a metodologia do Design Sprint que várias equipes do Google usam para solucionar problemas e resolver desafios como o Auto Driving Car e o Project Loon.
Losango duplo
Esse fluxo de trabalho é baseado no que, nos círculos de UX, chamamos de diamante duplo, divulgado pelo British Design Council (link em inglês), em que sua equipe divergente para entender uma ideia por meio de pesquisa e, em seguida, converge para definir o desafio, esboçando-o individualmente, compartilhar as ideias, decidir qual é a melhor direção, testar e validar.
Construindo o cenário
A primeira coisa é começar com o desafio em questão e escrevê-lo como uma proposta, perguntando-se: “Qual é o problema que estou realmente tentando resolver?”. A declaração de desafio é o resumo que você está definindo para o projeto que inclui sua meta.
Esse desafio pode ser para um recurso de produto atual que precisa ser refinado ou para um produto completamente novo. Seja qual for sua tarefa, basta ajustar a linguagem para se adequar ao objetivo que você está tentando alcançar. Uma declaração deve estar vinculada aos objetivos da equipe, focada no público-alvo, ser inspiradora e concisa.
Estes são alguns exemplos reais de produtos em que trabalhei anteriormente,
Criar um sistema para gerenciar o tratamento e o acompanhamento de pacientes com pés torto.
Criar um app que simplifique sistemas financeiros complexos e os reduza ao essencial.
Projetar um app para dispositivos móveis consistente em diferentes plataformas sem sacrificar a marca.
Atualizando sua declaração de desafio
Depois de escrever diversas variações do objetivo, apresente-as à equipe para chegar a um consenso. Inclua um prazo para ajudar a equipe a se concentrar no problema. Com os ajustes adicionados, a lista acima poderia ser:
- Criar um sistema para gerenciar o tratamento e acompanhamento de crianças menores de 2 anos que sofram de pés tortos para lançamento no primeiro trimestre deste ano.
- Crie um app financeiro simples que permita comprar e vender ações com um toque, sem conhecimento prévio do mundo financeiro, com lançamento inicial em julho de 2017.
- Produzir um guia de design que seja flexível em várias plataformas e posicione a marca da empresa de forma eficaz em cada plataforma até o final deste ano.
Quando a declaração de desafio terminar, exiba-a em um lugar de destaque para que você possa vê-la enquanto trabalha. Será necessário consultá-lo com frequência e talvez até atualizá-lo ou modificá-lo ao longo do projeto.
Validar o problema
A próxima etapa é pesquisar o desafio e aprender sobre o problema. O que você precisa descobrir é se a compreensão da sua equipe do problema é válida. Muitas vezes, analisamos os problemas do nosso ponto de vista, o que é perigoso, já que a maioria das pessoas da área de tecnologia são usuários avançados e, na verdade, somos uma minoria. Somos uma minoria com participação ativa e isso pode nos levar a pensar que algo realmente é um problema quando não é.
Existem vários métodos de coleta de dados para validar o desafio. Cada uma depende da sua equipe e do seu acesso aos usuários. O objetivo é ter uma melhor compreensão do problema em questão.
Entrevistas internas com as partes interessadas
O processo de entrevista envolve cada membro da equipe e partes interessadas da sua empresa, do marketing às contas. Isso o ajudará a descobrir quais são os desafios reais e quais podem ser as possíveis soluções. Quando falo de solução, não estou falando de soluções técnicas, mas qual seria o melhor cenário e o objetivo final para a empresa ou produto. Por exemplo, usar os desafios acima, “ter nosso software de pé torto em 80% das instalações médicas até o final do ano” seria um ótimo objetivo a ser alcançado.
Há uma ressalva. Esse método de validação é o menos favorável, porque impede discussões e colaborações em equipe, o que pode criar uma atmosfera isolada em uma organização. No entanto, ela pode gerar boas informações sobre os clientes e o desafio de design que poderiam passar despercebidas.
Palestras-relâmpago
Esse processo é semelhante às entrevistas internas, mas, desta vez, você reúne todas as partes interessadas em uma única sala. Em seguida, você escolhe cinco ou seis dessas partes interessadas (marketing, vendas, design, contas, pesquisa etc.) para dar uma palestra, cada uma se concentrando no desafio do ponto de vista delas por, no máximo, 10 minutos. Os tópicos que eles devem abordar em sua apresentação devem ser:
- Metas da empresa
- Desafios do projeto do ponto de vista deles (pode ser técnico, para coleta de pesquisas, criação de design etc.)
- Pesquisa com usuários que você tem atualmente
Reserve 5 minutos no final para perguntas, com uma pessoa eleita fazendo anotações. Quando terminar, atualize o desafio para refletir os novos aprendizados. O objetivo é coletar uma lista de marcadores que possam direcionar um recurso ou fluxo que ajude você a atingir a meta do seu produto.
Entrevistas com usuários
Essa talvez seja a melhor maneira de aprender sobre a jornada do usuário, os pontos problemáticos e o fluxo. Organize pelo menos cinco entrevistas com usuários, ou mais se você tiver acesso a eles. Os tipos de perguntas que você faz devem incluir:
- Como eles concluem uma tarefa existente? Por exemplo, digamos que você queira resolver o desafio do app financeiro acima. Você poderia perguntar “Como comprar ações e ações no momento?”
- Do que eles gostam nesse fluxo?
- Do que eles não gostam nesse fluxo?
- Quais produtos semelhantes o usuário utiliza atualmente?
- Do que eles gostam?
- Do que eles não gostam?
- Se ele tivesse uma varinha mágica e pudesse mudar algo nesse processo, o que mudaria?
A ideia da entrevista é fazer com que o usuário fale sobre seus desafios. Este não é um ponto de discussão para você, e é por isso que você deve permanecer o mais silencioso possível. Isso é válido até mesmo quando um usuário para de falar, sempre aguarde um momento, porque ele pode estar refletindo. Você ficaria surpreso com o quanto alguém continua a falar depois de parar por alguns segundos.
Faça anotações durante todo o processo e, se possível, grave a conversa para capturar qualquer coisa que tenha passado despercebida. O objetivo é comparar o desafio com os insights do usuário que você reunir. Elas estão alinhadas? Você aprendeu algo que o ajuda a atualizar sua declaração de desafio?
Pesquisa de campo etnográfica
É aqui que você observa o usuário em campo, no contexto enquanto faz algo como ele faz as compras, viaja para o trabalho, como envia mensagens SMS etc. O motivo é que, em alguns casos, as pessoas dizem o que acham que você quer ouvir. Mas se você observar os usuários realizando ações e tarefas por conta própria, pode ser perspicaz. Basicamente, você está observando sem interferir, anotando coisas que acham fácil ou difícil e coisas que podem ter deixado passar. O objetivo é mergulhar no ambiente do usuário para ter mais empatia com as dificuldades dele.
Essa técnica geralmente envolve algum trabalho feito em um período mais longo e exige que um pesquisador lidere essa parte do projeto. Mas talvez seja mais esclarecedor, já que é possível ver um grupo de pessoas que você está estudando em seus ambientes naturais.
Coletando tudo
Depois de concluir a fase de aprendizado do seu projeto, você precisa dar uma última olhada no seu desafio. Você está no caminho certo? Há algo que você precisa ajustar? Anote tudo o que você aprendeu e agrupe-as em categorias. Eles podem se tornar a base de um recurso ou fluxo, dependendo do problema que você está resolvendo. Eles também podem ser usados para atualizar e revisar o desafio.
Depois de receber feedback e insights suficientes, é hora de aplicar esse conhecimento à criação de um mapa do projeto.
Mapa do projeto
O problema que você está tentando resolver geralmente é composto por diferentes tipos de pessoas (ou jogadores), cada um com um interesse no fluxo do projeto. Com base no que você aprendeu, você precisa listar os possíveis jogadores. Pode ser um tipo de usuário ou parte interessada, por exemplo, "um médico que trata pés tortos", "um paciente que tem pés tortos", "um cuidador que cuida do paciente" etc. Anote cada participante no lado esquerdo de uma folha de papel ou, se você tiver acesso, em um quadro branco. No lado direito, escreva os objetivos de cada jogador.
Por fim, anote para cada jogador o número de etapas necessárias para que eles atinjam seu objetivo. Por exemplo, para "um médico que trata pés tortos", o objetivo seria "curar um paciente com pé torto", então as etapas poderiam ser "registrar o paciente no sistema", "iniciar um plano médico", "criar um ciclo de revisão da saúde médica" e "realizar procedimento médico".
O resultado é um mapa de projeto com as principais etapas do processo. Pense nisso como uma visão geral do projeto, sem muitos detalhes. Ele também permite que os membros da equipe avaliem se o mapa corresponde à declaração de desafio. Mais tarde, quando você detalhar cada etapa, haverá mais detalhes. Mas, por enquanto, um mapa do projeto oferece uma análise de alto nível das etapas que um usuário vai seguir para concluir o objetivo final.
Wireframes e storyboards
Crazy Eights
Para isso, recomendo um método chamado "oito maluco", que envolve dobrar um pedaço de papel duas vezes para ter oito painéis. Em seguida, em cada painel, você desenha uma ideia com base em tudo o que aprendeu até agora. Dê a si mesmo dez minutos para pensar em ideias para preencher todos os oito painéis. Se tiver mais de 20 minutos, poderá começar a procrastinar, fazer um café, conferir seu e-mail, conversar com a equipe em geral e evitar fazer o trabalho. É importante criar um senso de urgência nesta etapa, porque isso força você a trabalhar com mais rapidez e eficiência.
Se você trabalha em equipe, peça que todos façam o seu próprio. Esse processo vai estimular seu cérebro e fazer você pensar no desafio. Geralmente, o esboço será um wireframe de design de interface.
Depois, você e todos da equipe devem apresentar as ideias ao grupo. Todos precisam explicar cada uma das oito ideias em detalhes e por que escolheram seguir um caminho específico. Lembre cada membro da equipe de usar os aprendizados para justificar suas ideias. Depois que todos se apresentaram, é hora de votar nas ideias. Cada pessoa recebe dois pontos e pode votar em qualquer ideia. Eles podem dar ambos os votos para uma única ideia se realmente gostarem dela.
Refine seu design
Após a votação, escolha a ideia com mais votos e esboce uma ideia final. Você também pode usar outras ideias que ouviu de seus colegas. Reserve mais dez minutos para realizar essa tarefa. Quando terminar, apresente novamente as ideias para sua equipe e vote como antes.
Fazer o storyboard da ideia
Com seu design em mãos, é hora de fazer o storyboard do engajamento com o usuário. A essa altura, você já deve ter pensado nas diferentes etapas que um usuário realiza. É bastante comum incorporar os designs de um dos colegas ao fluxo também. É importante ter um processo passo a passo claro, com alguns pontos em que o usuário pode divergir. Consulte o mapa do projeto para validar seu design em relação à meta.
Criar um protótipo
Criar um protótipo não tem a ver com moldar o código perfeito, mas criar algo que é verossímeno quando usado por alguém. As ferramentas usadas para criar um protótipo variam de pessoa para pessoa. Alguns gostam do Keynote ou do Powerpoint, porque forçam você a pensar no fluxo, não nos detalhes do design. Invista tempo em ferramentas de aprendizado como Balsamiq, Marvel ou Framer, que podem oferecer controles mais comportamentais. Seja qual for a ferramenta usada, ela deve fazer você se concentrar no fluxo e parecer real. Você precisa testar o protótipo em pessoas reais, então, ele precisa ser o mais plausível possível, mas, ao mesmo tempo, não deve levar semanas de trabalho para ser criado.
Criar um protótipo é um equilíbrio entre tempo e veracidade, então tenha cuidado para não pender muito em nenhum dos extremos. De qualquer forma, você pode acabar perdendo tempo.
Testar a usabilidade dos seus designs
Seria ótimo ter um laboratório de testes. Caso contrário, criar um não é difícil, desde que você crie um ambiente confortável para os usuários que não distraia o usuário. Os testes geralmente envolvem o usuário e duas pessoas da equipe, um para fazer anotações e outro para fazer perguntas. Uma boa estratégia é usar um app como o Hangouts e gravar as ações dos participantes. Isso também é útil se você quiser que o restante da equipe observe de outra sala. Isso pode ser muito assustador para nós, como criadores de apps, porque estamos vendo nossos designs à solta. Pode ser uma experiência ao mesmo tempo regeneradora e regeneradora.
Perguntas a serem feitas
Ao testar seu design, peça para o usuário realizar tarefas no app, pedir que ele fale em voz alta e verbalize o que está fazendo e por quê. Isso é estranho, mas ajuda a ouvir o que eles estão pensando. Tente não interromper ou dizer o que ele deve fazer quando ficar preso. Simplesmente pergunte por que ele realizou um fluxo específico após a conclusão (ou NÃO).
O que você precisa descobrir é:
- O que eles gostam no protótipo?
- Do que eles não gostam no protótipo?
- Quais são os pontos fracos?
- Por que um fluxo funcionou
- Por que um fluxo não funcionou?
- O que ele gostaria de melhorar?
- O design/fluxo geral atende às necessidades dela?
Revisitar os designs e outra rodada de testes
Você tem um protótipo funcional com feedback. Agora é hora de revisar seus designs e analisar o que funcionou e o que não funcionou. Não tenha medo de criar um storyboard de wireframe completamente novo e um novo protótipo. Um recomeço pode criar um fluxo melhor do que tentar modificar os elementos do protótipo anterior. Tente não se apegar muito, porque é apenas um protótipo.
Quando estiver satisfeito com seus designs, é possível testá-lo novamente e refiná-lo um pouco mais. Nos casos em que o protótipo não funcionou, você pode achar que o projeto falhou. Na verdade, não foi. É provável que você tenha passado menos tempo desenvolvendo o que se tivesse criado o design e conhecesse mais o que o usuário realmente gosta. Com sprints de design, temos uma filosofia em que você vence ou aprende, então não se preocupe muito se a ideia não funcionar como planejado.
Hora de produzir!
Você já testou suas ideias. O usuário gosta deles. As partes interessadas estão investidas porque se envolveram desde o início. Agora é hora de fazer a coisa. Agora, você já deve ter uma ideia clara do que precisa ser feito e quais são as prioridades da experiência. Em cada marco do projeto, convém introduzir testes de usabilidade para ajudar a validar seu trabalho e manter você no caminho certo.
Não posso salientar o quão importante é descobrir o máximo possível antes de se comprometer com muito trabalho, tempo e energia em algo que pode não ser a solução certa.
Agora, este artigo deve explicar o básico sobre UX e a importância dele. UX não é algo que deve ser considerado uma função de designer ou pesquisador. Na verdade, é responsabilidade de todos os envolvidos no projeto, por isso recomendo o envolvimento deles em todas as oportunidades.