Um guia explicativo sobre os conceitos básicos do design de UX.
Este artigo apresenta um fluxo de trabalho que pode ajudar equipes, produtos, startups e empresas a criar um processo robusto e significativo para desenvolver uma experiência do usuário melhor para os clientes. Você pode usar diferentes partes do processo separadamente, mas o ideal é que elas funcionem como uma série de etapas.
Este guia se baseia na metodologia de design sprint, que é usada por várias equipes do Google para resolver problemas e desafios, como o carro autônomo e o Projeto Loon.
Duplo diamante
Esse fluxo de trabalho se baseia no que chamamos de duplo diamante, popularizado pelo British Design Council (link em inglês). Nele, sua equipe diverge para entender uma ideia por meio de pesquisas e converge para definir o desafio, diverge para esboçar individualmente, compartilha as ideias, decide qual é a melhor maneira de seguir em frente, testa e valida.
Contexto
Primeiro, comece com o desafio em questão e escreva como uma proposta, perguntando a si mesmo: "Qual é o problema que estou tentando resolver?". A declaração do desafio é o resumo que você está definindo para o projeto e inclui sua meta.
Esse desafio pode ser para um recurso de produto atual que precisa ser refinado ou um produto completamente novo. Seja qual for sua tarefa, basta ajustar o idioma para se adequar à meta que você quer alcançar. Uma declaração precisa estar vinculada às metas da equipe, focada no público, inspiradora e concisa.
Estes são alguns exemplos reais de produtos em que trabalhei no passado:
Projete um sistema para gerenciar o tratamento e o acompanhamento de pacientes com pé torto.
Crie um app que simplifique sistemas financeiros complexos e os reduza ao essencial.
Crie um app para dispositivos móveis consistente em diferentes plataformas sem sacrificar a marca.
Atualizar sua declaração de desafio
Depois de escrever várias variações da meta, apresente-a à sua equipe para chegar a um consenso. Inclua um prazo para ajudar a equipe a se concentrar no problema. Assim, com os ajustes adicionados, a lista acima poderia ser:
- Projetar um sistema para gerenciar o tratamento e o acompanhamento de crianças menores de 2 anos com pé torto para lançamento no primeiro trimestre deste ano.
- Criar um app financeiro simples que permita comprar e vender ações com um toque de um botão sem conhecimento prévio do mundo financeiro, com lançamento inicial em julho de 2017.
- Produzir um guia de design flexível em várias plataformas e posicionar a marca da empresa de maneira eficaz em cada plataforma até o final deste ano.
Quando a declaração do desafio estiver pronta, coloque-a em um lugar de destaque para que você possa vê-la enquanto trabalha. Você vai precisar consultá-lo constantemente, talvez até atualizando ou modificando ao longo do projeto.
Validar o problema
A próxima etapa é pesquisar o desafio e aprender sobre o problema. Você precisa descobrir se o entendimento do problema pela sua equipe é válido. Muitas vezes, analisamos os problemas do nosso ponto de vista, o que é perigoso, já que a maioria de nós na área de tecnologia é usuária avançada e, na verdade, representa uma minoria de usuários. Somos uma minoria vocal e podemos ser enganados a pensar que algo é um problema quando não é.
Há vários métodos de coleta de dados para validar o desafio. Cada uma delas depende da sua equipe e se você tem acesso aos usuários. O objetivo é entender melhor o problema em questão.
Entrevistas internas com partes interessadas
O processo de entrevista envolve conversar com cada membro da equipe e stakeholder da sua empresa, do marketing às contas. Isso vai ajudar você a descobrir quais são os desafios reais e as possíveis soluções na opinião deles. Quando digo solução, não estou falando de soluções técnicas, mas sim do melhor cenário e da meta final para a empresa ou o produto. Por exemplo, usar os desafios acima "ter nosso software de pé torto em 80% das instalações médicas até o fim do ano" seria uma ótima meta.
Há uma ressalva. Esse método de validação é o menos recomendado porque impede a discussão e a colaboração em equipe, criando um ambiente isolado em uma organização. No entanto, ele pode gerar boas informações sobre os clientes e o desafio de design que você poderia perder.
Palestras-relâmpago
É semelhante às entrevistas internas, mas desta vez você reúne todos os stakeholders em uma única sala. Em seguida, escolha cinco ou seis dessas partes interessadas (marketing, vendas, design, contas, pesquisa etc.) para fazer uma apresentação, cada uma focando no desafio da perspectiva delas por no máximo 10 minutos. Os temas que eles precisam abordar na apresentação são:
- Metas da empresa
- Desafios do projeto do ponto de vista deles (podem ser técnicos, de coleta de pesquisa, de criação de design etc.)
- Pesquisa de usuário que você tem no momento
Deixe 5 minutos no final para perguntas, com uma pessoa eleita tomando notas durante toda a reunião. Depois de concluir, talvez você queira atualizar o desafio para refletir novos aprendizados. O objetivo é coletar uma lista de marcadores que podem impulsionar um recurso ou fluxo que ajude você a alcançar a meta dos seus produtos.
Entrevistas com usuários
Essa talvez seja a melhor maneira de aprender sobre a jornada, os pontos problemáticos e o fluxo do usuário. Faça pelo menos cinco entrevistas com usuários, mais se você tiver acesso a eles. As perguntas que você faz a eles devem incluir:
- Como eles concluem uma tarefa? Por exemplo, se você quiser resolver o desafio do app financeiro acima, pergunte: "Como você compra ações no momento?"
- O que eles gostam nesse fluxo?
- Do que eles não gostam nesse fluxo?
- Quais produtos semelhantes o usuário usa atualmente?
- Do que eles gostam?
- O que eles não gostam?
- Se eles tivessem uma varinha mágica e pudessem mudar uma coisa nesse processo, o que seria?
A ideia da entrevista é fazer com que o usuário fale sobre os desafios que ele enfrenta. Não é um ponto de discussão para você, por isso, fique o mais quieto possível. Mesmo quando um usuário para de falar, espere um momento, porque ele pode estar organizando as ideias. Você vai se surpreender com o quanto alguém continua falando depois de parar por alguns segundos.
Faça anotações durante a conversa e, se possível, grave para ajudar a capturar algo que você possa ter perdido. O objetivo é comparar o desafio com os insights do usuário que você coleta. Elas estão alinhadas? Você aprendeu algo que ajuda a atualizar sua declaração de desafio?
Pesquisa de campo etnográfica
É aqui que você observa o usuário no campo, em contexto, enquanto ele faz algo, como compras, vai para o trabalho, envia mensagens de texto etc. O motivo é que, em alguns casos, as pessoas dizem o que acham que você quer ouvir. Mas observar os usuários realizando ações e tarefas por conta própria pode ser esclarecedor. Basicamente, você está observando sem interferir, anotando o que eles acham fácil ou difícil e o que podem ter perdido. O objetivo é se envolver no ambiente do usuário para entender melhor as dificuldades dele.
Essa técnica geralmente envolve algum trabalho realizado por um período mais longo e exige que um pesquisador lidere essa parte do projeto. Mas talvez seja a mais perspicaz, já que você acompanha um grupo de pessoas que está estudando no ambiente natural delas.
Reunindo tudo
Depois de concluir a fase de aprendizado do projeto, você precisa dar uma última olhada no desafio. Você está no caminho certo? Você precisa ajustar alguma coisa? Anote tudo o que você aprendeu e agrupe 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 ter feedback e insights suficientes, é hora de aplicar esse conhecimento para criar um mapa do projeto.
Mapa do projeto
O problema que você está tentando resolver geralmente é composto por diferentes tipos de pessoas (ou jogadores), cada uma com uma participação no fluxo do projeto. Com base no que você aprendeu, liste os possíveis players. Pode ser um tipo de usuário ou stakeholder, por exemplo, "um médico que trata pé torto", "um paciente com pé torto", "um cuidador que cuida do paciente" etc. Anote cada pessoa no lado esquerdo de uma folha de papel ou, se tiver acesso a um, em um quadro branco. No lado direito, escreva os objetivos de cada jogador.
Por fim, para cada jogador, anote o número de etapas necessárias para que ele alcance a meta. Por exemplo, para "um médico que trata pé torto", a meta seria "curar um paciente com pé torto". 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 um procedimento médico".
O resultado é um mapa do 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 julguem se o mapa corresponde à declaração do desafio. Mais tarde, quando você detalhar cada etapa, haverá mais informações. Por enquanto, um mapa de projeto oferece uma visão geral das etapas que um usuário vai seguir para concluir o objetivo final.
Wireframing e storyboarding
Crazy 8s
Para isso, recomendo um método chamado "oito malucos", que envolve dobrar um pedaço de papel duas vezes para que você tenha oito painéis. Em seguida, em cada painel, crie uma ideia com base em tudo o que você aprendeu até agora. Reserve dez minutos para criar ideias para preencher todos os oito quadros. Se você se der mais de 20 minutos, pode começar a procrastinar, fazer um café, verificar o e-mail, conversar com sua equipe e evitar fazer o trabalho. Crie um senso de urgência nessa etapa, porque isso força você a trabalhar de forma rápida e mais eficaz.
Se você estiver trabalhando com uma equipe, peça para todos fazerem o mesmo. Esse processo vai estimular seu cérebro e fazer você pensar no desafio. Em geral, o esboço é um wireframe de design de interface.
Depois, você e todos da equipe apresentam as ideias para o grupo. Cada pessoa precisa explicar detalhadamente as oito ideias e por que escolheu seguir um caminho específico. Lembre cada membro da equipe de usar os aprendizados para justificar as ideias. Depois que todos apresentarem, é hora de votar nas ideias. Cada pessoa recebe dois adesivos e pode votar em qualquer ideia. Eles podem dar os dois votos para uma única ideia se gostarem muito dela.
Refinar o design
Depois da votação, pegue a ideia mais votada e faça um esboço da ideia final. Você também pode usar as ideias que ouviu dos seus colegas. Dê mais dez minutos para concluir essa tarefa. Depois, apresente as ideias à equipe e vote como antes.
Fazer um storyboard da ideia
Com o design em mãos, é hora de criar um storyboard do engajamento com o usuário. Neste ponto, você já deve ter pensado nas diferentes etapas que um usuário realiza. É bastante comum incorporar um dos designs dos seus colegas ao fluxo também. Você quer ter um processo claro, etapa por etapa, com alguns pontos em que o usuário pode divergir. Consulte o mapa do projeto para validar seu design em relação à meta.
Como criar um protótipo
Criar um protótipo não é moldar o código perfeito, mas fazer algo que seja confiável quando usado por alguém. As ferramentas usadas para criar um protótipo variam de pessoa para pessoa. Alguns preferem o Keynote ou o PowerPoint porque eles obrigam você a pensar no fluxo e não nos detalhes do design. Talvez seja interessante investir tempo no aprendizado de ferramentas como Balsamiq, Marvel ou Framer, que oferecem mais controles comportamentais. Qualquer ferramenta que você use precisa fazer com que você se concentre no fluxo e pareça real. Você precisa testar o protótipo com pessoas reais, então ele precisa ser o mais realista possível, mas, ao mesmo tempo, não pode levar semanas para ser criado.
Criar um protótipo é um equilíbrio entre tempo e realidade. Por isso, tenha cuidado para não pender demais para nenhum dos extremos. De qualquer forma, você pode acabar perdendo tempo.
Teste a usabilidade dos seus designs
É ótimo se você tiver um laboratório de testes. Se não tiver, criar um não é difícil, desde que você se preocupe em criar um ambiente confortável e sem distrações para os usuários. Normalmente, o teste envolve o usuário e duas pessoas da sua equipe, uma fazendo anotações e a outra fazendo perguntas. Uma boa configuração é usar um app como o Hangouts e gravar as ações. Isso também é útil se você quiser que o restante da equipe observe de uma sala diferente. Isso pode ser assustador para nós, criadores de apps, porque vemos nossos designs em uso. Pode ser uma experiência revigorante e sóbria.
Perguntas a serem feitas
Ao testar o design, peça ao usuário para realizar tarefas no app e para falar em voz alta e verbalizar o que está fazendo e por quê. Isso é estranho, mas ajuda você a ouvir o que eles estão pensando. Tente não interromper nem dizer o que fazer quando a pessoa ficar presa. Basta perguntar por que eles seguiram um fluxo específico depois de concluírem (ou NÃO concluírem).
Você precisa descobrir:
- O que eles gostam no protótipo?
- O que eles não gostaram no protótipo?
- Quais são as dificuldades?
- Por que um fluxo funcionou
- Por que um fluxo não funcionou
- O que eles gostariam de melhorar?
- O design/fluxo geral atende às necessidades deles?
Revisitar 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. Começar de novo pode criar um fluxo melhor do que tentar mover as coisas no protótipo anterior. Não se apegue muito a ele, porque é apenas um protótipo.
Quando estiver tudo certo com os designs, teste de novo e refine um pouco mais. Se o protótipo não atingir o objetivo, você pode achar que o projeto falhou. Na verdade, não. Você provavelmente gastou menos tempo de desenvolvimento do que se tivesse criado o design, e sabe mais sobre o que os usuários realmente gostam. Com os sprints de design, temos uma filosofia em que você vence ou aprende. Por isso, não se culpe muito se a ideia não funcionou como planejado.
Faça isso!
Você testou suas ideias. O usuário gosta deles. As partes interessadas estão investidas porque participam desde o início. Agora é hora de fazer a coisa. Agora você já tem uma ideia clara do que precisa ser feito e quais são as prioridades da experiência. Em cada marco do projeto, talvez seja interessante fazer testes de usabilidade para validar seu trabalho e manter o projeto no caminho certo.
É muito importante descobrir o máximo possível antes de se dedicar a muito trabalho, tempo e energia em algo que pode não ser a solução certa.
Este artigo oferece uma base sobre UX e a importância dela. UX não é algo que deve ser visto como uma função para um designer ou pesquisador. Na verdade, é responsabilidade de todos os envolvidos em um projeto. Por isso, recomendo o envolvimento em todas as oportunidades.