Design Centrado no Usuário — Parte 1
Um livro de UX para desenvolvedores por Travis Lowdermilk
O livro começa fazendo uma comparação com o mundo atual da tecnologia e comentando sobre como o lançamento do primeiro iPhone aumentou as expectativas dos usuários sobre qualquer outro software que fosse lançado.
O impacto do iPhone foi devido não só a um bom design da parte gráfica, do código ou a funcionalidade. Foi toda uma equipe trabalhando continuamente para entender o usuário, pois as pessoas não sabiam o que queriam, até que foi mostrado a elas.
#FirstThingsFirst
IHC, DCU e UX? — Nomenclaturas que se confundem.
Resumidamente, em ordem de hierarquia:
• Usabilidade: estudo de como os seres humanos se relacionam com qualquer produto.
• Interação Humano Computador(IHC): mesma coisa de cima, mas somente com produtos ligados à computação.
• Design centrado no Usuário (DCU): metodologia de design de software para desenvolvedores e designers.
• User experience (UX): termo usado para sintetizar toda a experiência do usuário com um produto de software (englobando não só suas funcionalidades, mas também o quanto é agradável de ser usado).
DCU vai além da estética, precisamos examinar o quanto o software é eficiente para atingir o propósito pelo qual foi concebido.
Entenda, não é porque você não está aprendendo o framework mais recente ou escrevendo o código, que seu produto não está progredindo. Entender as dores dos usuários é uma parte necessária para a construção e evolução do seu projeto.
Além disso, essa abordagem (se bem utilizada) economiza gastos. Ora, podem ser aplicados testes de usabilidade como parte do programa de gerenciamento de qualidade de software. 💰 Esses testes ajudarão a eliminar bugs mais cedo diminuindo os custos de suporte e correção dos softwares. #roi
📋Use o relatório de bugs para ter uma visão geral, mas lembre-se que é importante entender o que o usuário estava tentando fazer ao reportar um bug. Às vezes o problema não é no código em si. O usuário pode ter achado um caminho alternativo para realizar a tarefa que ele queria.Por isso, é importante dar a possibilidade de um usuário submeter um bug.
Seja resiliente e curioso
Já entendemos que a chave para o sucesso de um software, é garantir que os usuários sejam envolvidos, em algum nível desse processo. Na maioria das vezes, não irão descrever/compreender bem o que necessitam, mas fazer perguntas continuamente e chegar até a raiz do problema é tarefa nossa.
Dito isso, precisamos lembrar que um produto de sucesso demora anos para ser construído. É aquela velha frase: “Não compare o palco de alguém, com os seus bastidores”.
Por exemplo: Leonardo da Vinci tinha um caderno cheio de esboços e desenhos da sua versão definitiva da obra A última Ceia. Passou anos redesenhando diferentes ideias e conceitos, mas poucos sabem disso.
Ou seja, se estiver disposto se manter curioso(a) fazendo perguntas, observando o comportamento do usuário, você aumentará as suas chances obter mais conhecimento, desenvolver o seu produto e alcançar o seu objetivo.
Caso você esteja criando um produto relacionado a Medicina, por exemplo, e não saiba certas terminologias. Não tenha vergonha de admitir que não sabe do que o usuário está falando e peça para que ele/ela descreva o seu fluxo de trabalho de uma maneira que você possa entender.
Saiba lidar com seus usuários
Existem diversos tipos de usuários e precisamos saber lidar com cada um deles. O informante exagerado, por exemplo, é aquele que quer começar a falar da próxima versão. Então explique a ele(a) a importância de permanecerem focados na versão presente.
O obcecado por controle quer estar envolvido em todas as decisões do projeto. Normalmente impõem a sua presença nas reuniões, atrapalhando de alguma forma e dando ordens de como as coisas deveriam ser. A necessidade de controle vem da sensação de insegurança. Então você pode tentar conduzir uma reunião particular e entender o que o preocupa. Esse perfil pode ser transformado em Superusuário. Por serem mais críticos, esse é um bom tipo de personalidade para testar versões em desenvolvimento (beta), mas antes, cabe lembra-los que será preciso um compromisso maior no nível de engajamento. “Com grandes poderes, vem grandes responsabilidades”, não é mesmo?!
Melhorias não se fazem só com feedbacks negativos
Se percebermos que uma alteração no layout de um determinado site incentivou mais vendas. O que podemos aprender com isso e como podemos aplicar no nosso contexto?
Se alguma funcionalidade recente está recebendo feedbacks positivos, explore. Isso pode ser uma oportunidade!
Planejamento e Documentação
É crucial que toda a equipe entenda o motivo daquele projeto. Um template básico inclui:
- Missão da equipe (como o propósito da equipe impacta as pessoas, tanto de forma positiva quanto negativa).
- Detalhes do Projeto (algo tão simples como o título do projeto pode ter um efeito impactante)
- Requisitos de usuário (o que o usuário necessita)
- Requisitos funcionais (Focado na tecnologia, pois você poderá precisar de vários requisitos funcionais necessários para atender a um resquisito do usuário).
- Diagramas de banco de dados/fluxo dados (O diagrama evita que você tenha que administrar todo o fluxo do software contando com a memória. Por mais simples que seja, poderá ter vários caminhos e condições a serem considerados) — #Dica: Ferramentas como a Microsoft Visio oferecem templates para a criação desses diagramas.
- Imagens de telas de protótipos e mockups (ter a documentação e imagens do antes e depois, lhe possibilita revisar as mudanças do projeto ao longo do tempo, trazendo um aprendizado enorme).
“Praticar o design centrado no usuário significa que você estará reagindo a descobertas que não haviam sido incluídas em seu plano original.”
Manifesto, Personas e Cenários
Caso você trabalhe com diversos projetos, é interessante ter um manifesto para cada um. Ele ajudará a saber quais recursos devem ser incluídos e, mais importante, quais recursos você deixará de lado.
O aplicativo Paper da FiftyThree ganhou o prêmio Apple Design Award, exatamente por entender que seu objetivo não era se tornar o aplicativo mais completo de desenho, com mil cores e mil tipos de traços diferentes, mas sim, disponibilizar ferramentas básicas, permitindo que o usuário (artista profissional ou não) focasse na criatividade.
Não sobrecarregue o seu sistema com recursos. Às vezes os desenvolvedores colocam a tecnologia em primeiro lugar e ficam focados demais naquilo que poderiam fazer, e não no que deveriam fazer. Lembrem-se que a ideia não é mostrar os obstáculos tecnológicos que foram capazes de superar.
Criar uma persona(personagem científico) te ajuda a construir a narrativa necessária para entender a jornada do usuário.
Após ober as personas, crie cenários. Mini-histórias de situações pelos quais as suas personas podem passar.
Se você for honesto em relação às limitações do seu produto, explorar diferentes cenários poderá ajudar a entender o quanto uma limitação em particular poderá ser um problema.
“Facilidade de uso pode ser invisível, mas sua ausência não é” — IBM.
Encerro por aqui a primeira parte desse resumo.
Até mais! :)
