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 melhor experiência do usuário para os clientes. Você pode usar partes diferentes do processo separadamente, mas elas funcionam melhor como uma série de etapas.
Este guia se baseia muito na metodologia de design sprint que várias equipes do Google usam para resolver problemas e desafios, como o Carro autônomo e o Project Loon.
Diamante duplo
Esse fluxo de trabalho é baseado no que chamamos de diamante duplo, popularizado pelo Conselho de Design Britânico, em que a equipe diverge para entender uma ideia por meio da pesquisa e, em seguida, converge para definir o desafio, diverge para esboçá-lo individualmente, compartilha as ideias, decide qual é a melhor maneira de seguir em frente, testa e valida.
Como preparar o cenário
A primeira coisa a fazer é começar com o desafio em questão e escrevê-lo 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 que inclui sua meta.
Esse desafio pode ser para um recurso de produto que precisa ser refinado ou um produto completamente novo. Seja qual for sua tarefa, basta ajustar o idioma para se adequar ao objetivo que você está tentando alcançar. Uma declaração precisa estar ligada às metas da equipe, focada no público, inspiradora e concisa.
Estes são alguns exemplos reais de produtos em que trabalhei no passado:
Projetar 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.
Projetar um app para dispositivos móveis consistente em diferentes plataformas sem sacrificar a marca.
Como atualizar a declaração do desafio
Depois de escrever várias variações da meta, apresente-a à sua equipe para chegar a um consenso. Inclua um prazo, porque isso vai ajudar a equipe a se concentrar no problema. Com os ajustes adicionados, a lista acima poderia ser:
- Projetar um sistema para gerenciar o tratamento e o acompanhamento de crianças com menos de 2 anos com pé torto para lançamento no primeiro trimestre deste ano.
- Crie um app financeiro simples que permita comprar e vender ações com um toque no botão sem conhecimento prévio do mundo financeiro, com lançamento inicial em julho de 2017.
- Produzir um guia de design flexível para várias plataformas e posicionar a marca da empresa de forma eficaz em cada plataforma até o final deste ano.
Quando a declaração do desafio for concluída, mostre-a em um lugar de destaque para que você possa vê-la enquanto trabalha. Você vai precisar consultar esse documento constantemente, talvez até mesmo atualizá-lo ou modificá-lo ao longo do projeto.
Como validar o problema
A próxima etapa é pesquisar o desafio e aprender sobre o problema. O que você precisa descobrir é se o entendimento da sua equipe sobre o problema é válido. Muitas vezes, analisamos os problemas do nosso próprio ponto de vista, o que é perigoso, já que a maioria de nós na área de tecnologia é de fato usuário avançado e, na verdade, é uma minoria de usuários. Somos uma minoria vocal e podemos ser enganados a pensar que algo é realmente um problema quando não é.
Há vários métodos de coleta de dados para validar o desafio. Cada um deles depende da sua equipe e se você tem acesso aos usuários. O objetivo é entender melhor o problema em questão.
Entrevistas internas com as partes interessadas
O processo de entrevista envolve entrevistar cada membro da equipe e parte interessada da sua empresa, do marketing às contas. Isso vai ajudar você a descobrir quais são os desafios reais e quais são as possíveis soluções. Quando digo solução, não estou falando de soluções técnicas, mas sim do que seria o melhor cenário e o objetivo final da empresa ou do produto. Por exemplo, usando os desafios acima, "ter nosso software de pé torto em 80% das clínicas médicas até o final 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 da equipe, criando uma atmosfera isolada na organização. No entanto, ele pode fornecer informações úteis sobre os clientes e o desafio de design que você poderia perder.
Palestras-relâmpago
Isso é semelhante às entrevistas internas, mas desta vez você reúne todas as partes interessadas em uma única sala. Em seguida, você elege cinco ou seis dessas partes interessadas (marketing, vendas, design, contas, pesquisa etc.) para dar uma palestra, cada uma se concentrando no desafio da perspectiva delas por um máximo de 10 minutos. Os tópicos que ele precisa 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.)
- Pesquisas de usuário que você já tem
Reserve cinco minutos no final para perguntas, com uma pessoa escolhida fazendo anotações ao longo da reunião. Quando terminar, atualize o desafio para refletir as novas aprendizagens. O objetivo é coletar uma lista de marcadores que podem direcionar um recurso ou fluxo que ajude a alcançar a meta do produto.
Entrevistas com usuários
Essa é talvez 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 elas. As perguntas que você faz devem incluir:
- Como eles concluem uma tarefa? Por exemplo, se você quiser resolver o desafio do app financeiro acima, pergunte a ele: "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 no momento?
- Do que eles gostam?
- Do 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 tem. Não é um ponto de discussão para você, e por isso você precisa ficar o mais calado possível. Isso é verdade mesmo quando um usuário para de falar. Sempre espere um momento, porque ele pode estar organizando os pensamentos. Você ficaria surpreso com o quanto alguém continua falando depois de parar por alguns segundos.
Anote tudo e, se possível, grave a conversa para registrar tudo o que você perdeu. O objetivo é comparar o desafio com os insights de usuários que você coleta. Elas estão alinhadas? Você aprendeu algo que ajuda a atualizar sua declaração de desafio?
Pesquisa de campo etnográfica
É quando você observa o usuário no campo, no contexto enquanto faz algo como compras, como viaja para o trabalho, como envia mensagens SMS etc. O motivo é que, em alguns casos, as pessoas vão dizer o que acham que você quer ouvir. No entanto, se você observar os usuários realizando ações e tarefas por conta própria, isso pode ser útil. Basicamente, você está observando sem interferir, observando as coisas que eles acham fáceis ou difíceis e as coisas que eles podem ter perdido. O objetivo é se colocar no ambiente do usuário para criar mais empatia com as dificuldades dele.
Essa técnica geralmente envolve algum trabalho feito por um período mais longo e exige que um pesquisador lidere essa parte do projeto. Mas talvez seja a mais reveladora, porque você pode observar um grupo de pessoas que você está estudando no ambiente natural delas.
Como reunir 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 algo? Anote tudo o que você aprendeu e agrupe em categorias. Elas 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.
Quando você tiver feedback e insights suficientes, é hora de aplicar esse conhecimento para criar um mapa de 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 nos seus aprendizados, você precisa listar os possíveis jogadores. Pode ser um tipo de usuário ou parte interessada, por exemplo, "um médico que trata de 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 tiver acesso a um, em um quadro branco. No lado direito, escreva as metas de cada jogador.
Por fim, para cada jogador, anote o número de etapas necessárias para alcançar a meta. Por exemplo, para "um médico que trata de pé torto", o objetivo 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 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 adiante, quando você detalhar cada etapa, haverá mais detalhes. Mas, por enquanto, um mapa de projeto oferece um detalhamento geral das etapas que um usuário precisa seguir para concluir a meta final.
Wireframes e storyboards
Crazy 8s
Para isso, recomendo um método chamado "Crazy 8s", que envolve dobrar um pedaço de papel duas vezes para que você tenha oito painéis. Em seguida, em cada painel, você desenvolve uma ideia com base em tudo o que aprendeu até agora. Reserve dez minutos para criar ideias e preencher os oito painéis. Se você se der mais de 20 minutos, pode começar a procrastinar, fazer um café, conferir o e-mail, conversar com a equipe e, basicamente, evitar o trabalho. Você precisa criar um senso de urgência nessa etapa, porque ela 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 sobre o desafio. Geralmente, o esboço é um wireframe de design de interface.
Depois, você e todos da sua equipe apresentam as ideias para o grupo. Todos precisam explicar cada uma das oito ideias em detalhes e por que escolheram um caminho específico. Lembre cada membro da equipe de usar as lições para justificar as ideias. Depois que todos apresentarem, é hora de votar nas ideias. Cada pessoa recebe dois pontos adesivos e pode votar em qualquer ideia. Eles podem dar os dois votos a uma única ideia, se gostarem muito dela.
Refinar o design
Após a votação, escolha a ideia com mais votos e desenhe a ideia final. Você também pode usar as outras ideias que ouviu dos colegas. Tenha mais 10 minutos para concluir esta tarefa. Quando terminar, apresente as ideias novamente à sua equipe e vote como antes.
Criar um storyboard da ideia
Com o design em mãos, é hora de criar um storyboard para o engajamento com o usuário. Nesse ponto, você já deve ter pensado nas diferentes etapas que um usuário segue. É bastante comum incorporar um dos designs dos seus colegas no fluxo. Você quer ter um processo claro, com algumas etapas 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 criar algo que seja confiável 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 eles forçam a pensar no fluxo e não nos detalhes do design. Talvez você queira investir tempo em ferramentas de aprendizado, como Balsamiq, Marvel ou Framer, que podem oferecer mais controles comportamentais. Seja qual for a ferramenta que você usa, verifique se ela faz você se concentrar no fluxo e parecer real. Você precisa testar o protótipo em pessoas reais, então ele precisa ser o mais crível 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. Portanto, tenha cuidado para não se inclinar muito para nenhum dos extremos. De qualquer forma, você pode acabar perdendo tempo.
Testar a usabilidade dos designs
É ótimo se você tiver um laboratório de testes. Se não, não é difícil criar um, desde que você crie um ambiente confortável para os usuários que não distraia. O teste geralmente 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ê quer que o restante da equipe observe em uma sala diferente. Isso pode ser bastante assustador para nós, criadores de apps, porque estamos vendo nossos designs no mundo real. Pode ser uma experiência revigorante e desanimadora.
Perguntas a serem feitas
Ao testar seu design, peça para o usuário realizar tarefas no app e faça com que ele fale em voz alta e verbalize o que está fazendo e por que. Isso é uma coisa estranha de se fazer, mas ajuda a ouvir o que a pessoa está pensando. Tente não interromper ou dizer a eles o que fazer quando ficarem presos. Basta perguntar por que eles escolheram um fluxo específico depois de concluírem (ou não concluírem).
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 problemáticos?
- 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 os designs e fazer 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 fazer um novo protótipo. Começar de novo pode criar um fluxo melhor do que tentar mover as coisas no protótipo anterior. Tente não se preocupar muito com isso, porque é apenas um protótipo.
Quando estiver satisfeito com seus designs, teste-os novamente e refine-os um pouco mais. Nos casos em que o protótipo não atingiu a meta, 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 como é o usuário. Com os design sprints, temos uma filosofia em que você ganha ou aprende. Portanto, não se cobre demais se a ideia não funcionar como planejado.
Faça isso!
Você testou suas ideias. O usuário gosta deles. As partes interessadas estão envolvidas porque estão envolvidas desde o início. Agora é hora de criar 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, é recomendável introduzir testes de usabilidade para ajudar a validar seu trabalho e manter você no caminho certo.
É muito importante descobrir o máximo possível antes de investir muito trabalho, tempo e energia em algo que pode não ser a solução certa.
Este artigo deve fornecer uma base básica de UX e sua importância. A UX não é algo que precisa ser considerado como uma função de designer ou pesquisador. Na verdade, é responsabilidade de todos os envolvidos em um projeto recomendaria o envolvimento em todas as oportunidades.