Um problema que a área de TI sofre é em acompanhar as rápidas mudanças nas necessidades dos negócios, que cada vez ocorrem de forma mais constante, um exemplo bem atual é a situação da pandemia que estamos vivendo e o quanto isso mudou o cenário e até o modelo de negócio de diversas empresas. Tudo isso demanda um esforço da área para fornecer soluções que atendam essas demandas cada vez mais urgentes, mas apesar da urgência requisitada em muitas dessas demandas, precisamos nos atentar em entregar soluções que atendam de fato as necessidades dos clientes e zelem pela experiência dos usuários.
Imagine que em um dia qualquer, o TI recebe reclamações de clientes a respeito de não terem determinada funcionalidade que necessitam no sistema, o departamento define então rapidamente como vai ser feita essa funcionalidade para resolver logo o problema e é colocado urgência na tarefa.
Você é incubido dessa tarefa e rapidamente entrega o solicitado. Passado um tempo, o departamento continua recebendo reclamações de que o sistema não atende. Vocês mostram onde está a funcionalidade mas ainda assim os clientes reclamam do sistema e se mostram extremamente frustrados.
Cenário comum? Para alguns, talvez até para a maioria, sim. O que aconteceu? Podem ser muitas coisas, mas dado esse contexto, diante de todos os problemas, sem dúvidas houve uma falta de zelo pela experiência do usuário, perceba que uma tarefa foi recebida e definida sem pararem para entender de fato qual era a real necessidade dos clientes, sem pararem para sequer entender de fato quem são os usuários do sistema e ter dados destes para aí sim definir o que e como seria feita tal tarefa para atende-los e resolver suas frustrações de forma adequada.
Devemos zelar pela experiência dos nossos usuários.
Já vi justificativas de que o cliente que não sabe usar o sistema, ou de que o sistema atende e o cliente que é preguiçoso e que ele deve aprender a fazer como o programador definiu que deve ser, ou qualquer coisa parecida. E essa forma de pensar está completamente errada. O time de desenvolvimento precisa absorver a real necessidade dos usuários para conseguir criar soluções que façam sentido para eles.
Percepções diferentes a respeito de um mesmo problema.
Quando pensamos em um produto, precisamos entender como pensam os nossos usuários, e tomar cuidado com pré-concepções, ego, e outras características que influenciam a nossa percepção e prejudique a qualidade das nossas soluções.
Inicialmente eu seguia o senso comum de UX, não entendia muito da área, mas ao longo das minhas experiências fui entendendo a importância dessa área quando estamos desenvolvendo soluções, e aprofundei meus estudos nela com o objetivo de criar e propor soluções melhores.
Mas pera ai, UX o que? Acho que antes de mais nada eu deveria me atrever a tentar definir o que é UX Design.
UX Design ¶
UX, em sua essência, trata de experiência, todos temos uma experiência ao fazer uso de produtos e serviços, podendo ser boa ou ruim. UX engloba toda a experiência dos usuários finais desses produtos, o objetivo principal da área é entender a fundo os usuários, seus desejos, sua forma de pensar e de ser, para construir toda uma experiência que faça sentido para eles do início ao fim.
UX, quando estamos falando de construção de sistemas, remete a duas áreas muito interessantes, a engenharia de usabilidade, que tem como objetivo a construção de soluções pensando nos usuários dessas soluções, e a arquitetura da informação, que é a disciplina que tem como objetivo a estruturação de um conjunto de dados em informação. O trabalho de UX na construção de sistemas é zelar pelo produto para que este atenda as necessidades e expectativas do cliente, sendo assim uma solução de sucesso.
Apesar de tudo isso parecer meio óbvio, muitas vezes fazemos exatamente o contrário. Diversos produtos já falharam pela falta do pensamento na usabilidade, antes de fazermos uma solução precisamos nos questionar se ela realmente agrega valor, resolve o real problema do usuário, não vai gerar mais problemas depois, e se realmente entendemos o problema a ser resolvido.
Eu já vi muitas soluções que resolvem um monte de problemas e dão um monte de dados para o usuário final, mas sem pensar se aquela solução realmente vai ser efetiva, e se aquele monte de dados fazem de fato algum sentido para o usuário final (ou seja, foram transformados em informação). Isso no fim acaba gerando mais problemas e mais soluções que no fim não satisfazem e não chegam em lugar nenhum. E é assim que muitos desenvolvedores trabalham hoje, propondo um monte de soluções de problemas mas sem pensar no usuário final do produto. E se uma solução que para todo um time de desenvolvimento possa parecer perfeita, para os usuários for horrível e não fizer sentido nenhum?
Para quebrar essa mentalidade, precisamos entender que o que agrega valor às organizações não é resolver um monte de problemas, ou fornecer um monte de dados e informações, e sim trazer soluções e conhecimento que agregam valor ao usuário final do produto. E para isso, precisamos entender o nosso usuário, entender seu modelo mental de como são os processos a respeito do contexto do nosso produto, e ter um processo de criação e desenvolvimento que os envolva de forma efetiva na criação e manutenção deste produto. A prioridade de uma organização deve ser o cliente, não importa o quanto revolucionário seja o produto, se o cliente não quer ele vai fracassar.
UX é a disciplina do conhecimento que tem como objetivo fazer isso, envolver o usuário na concepção das soluções, para termos produtos que agreguem valor e resolvam os problemas deles.
Por que UX pode me tornar um desenvolvedor melhor? ¶
O modelo se concentra na análise dos requisitos, interagindo intimamente com a programação e o design. E, em um círculo virtuoso, ele aprofunda a visão que os membros da equipe têm sobre o domínio, permitindo que eles vejam com mais clareza levando a um refinamento ainda maior do modelo.
-- Eric Evans
Eric Evans, em seu livro Domain-Driven Design, tem como base do processo de desenvolvimento de software a criação, manutenção, e entendimento do modelo de domínio do negócio ao qual o software busca atender. Segundo ele, nosso trabalho é a solução de problemas relacionados ao domínio para os usuários.
Para termos um software maduro, que em seu coração consiga transcrever um modelo de domínio de um contexto de negócio, com toda a sua bagagem e conhecimentos específicos, é de suma importância nós como desenvolvedores investirmos um grande esforço no aprendizado do negócio no qual estamos atuando.
Uma empresa é formada pelos seus processos, nossos softwares devem ser reflexos desses processos.
Por consequência, é natural que para atingirmos esse nível de maturidade em nossas soluções, nós envolvamos os usuários, que entendem e convivem diariamente com o negócio, em nosso processo de análise e desenvolvimento, que é exatamente o que a UX prega. No DDD, é exposto de forma explícita que todo o conhecimento que precisamos para montar bons modelos de domínio ricos em conhecimento vem dos especialistas do domínio, dos usuários, e de experiências anteriores da equipe com sistemas legados.
Claro que a finalidade da proximidade com o usuário no DDD e na UX possuem suas diferenças, mas no fim, o objetivo é criarmos softwares que atendam de forma adequada nossos usuários.
Com isto, é possível concluir que o estudo da área de UX agrega e muito para nós desenvolvedores, nos trazendo mais próximos dos usuários conseguimos propor soluções que os atendam de forma mais adequada.
O que eu preciso saber sobre UX? ¶
Para começar, acredito que um entendimento básico sobre o conceito de Affordance, de Usabilidade, e as 10 heurísticas de Nielsen, é um bom começo, então vou dar uma breve introdução disso tudo logo abaixo.
Affordance ¶
No nosso dia a dia, mesmo sem perceber, somos apresentados a novos objetos constantemente, e naturalmente sabemos como utilizar eles, exemplos clássicos são a maçaneta de uma porta e canecas.
Affordance, é a qualidade que faz identificarmos a funcionalidade de um objeto sem a necessidade de explicações prévias, seja por intuição ou conhecimentos prévios.
Nossas soluções de software são recheadas de Affordances, cada componente visual tem seu objetivo e o uso adequado deles faz toda a diferença. Exemplos: ícones, botões, e links.
Uma usabilidade que pode ser óbvia para alguns não é para outros, por isso a importância de entendermos muito bem os usuários das nossas soluções.
Quando nos aprofundamos nos estudos de Affordance, começamos a entrar em discussões muito interessantes também sobre Psicologia Cognitiva, onde vamos discutir muito sobre o modelo mental do usuário e a importância de entender e respeitar ele.
Usabilidade ¶
Usabilidade, no nosso contexto de sistemas, diz respeito a facilidade com que os usuários conseguem realizar suas tarefas dentro do contexto de uso (negócio) do sistema.
É composta de três atributos:
- Eficácia: facilidade com a qual o usuário atinge seus objetivos utilizando o sistema.
- Eficiência: gasto de esforço para o usuário atingir seus objetivos utilizando o sistema.
- Satisfação: o nível de aceitação do usuário após o uso do sistema.
10 heurísticas de Nielsen ¶
Jakob Nielsen é uma das maiores referências em usabilidade, e após muito estudo e vivência de mercado ele definiu 10 heurísticas a serem seguidas para construirmos soluções melhores:
- Visibilidade do status do sistema: deve ser claro para o usuário o status dele dentro do sistema. Por exemplo em sistemas de assinatura, deve ser claro o status dela, data de vencimento, valor a ser cobrado, etc.
- Compatibilidade entre o sistema e o mundo real: o sistema deve respeitar o modelo mental do usuário, se um conceito não existe no contexto de negócio do mundo real, não faz sentido para o usuário existir no sistema.
- Controle e liberdade para o usuário: o usuário deve ter controle para realizar e desfazer suas tarefas. Imagina se o usuário faz por engano algo que não deveria e o sistema não tem a opção de desfazer? Acreditem, já vi situações de que quando isso aconteceu foi considerado culpa do usuário e ele foi punido por isso.
- Consistência e padronização: o sistema deve ser consistente e manter um padrão. O framework Bootstrap é um ótimo exemplo, ele nos dá um sistema visual consistente e padronizado.
- Prevenção de erros: devemos auxiliar os usuários a não cometerem erros, caixas de confirmação de ações são exemplos clássicos que seguem essa heurística.
- Reconhecimento ao invés de memorização: devemos evitar sobrecarregar a mente do usuário fazendo com que ele tenha que pensar demais toda vez que for realizar uma tarefa no sistema, exemplos para seguir essa heurística é utilizar elementos visuais padrões do mercado (ícone de salvar um arquivo por exemplo), ou colocar titles nas ações do sistema.
- Eficiência e flexibilidade de uso: mesmo os usuários mais leigos devem conseguir fazer uso com facilidade do sistema, e usuários avançados devem conseguir ter domínio para realizar suas tarefas com mais fluidez (com atalhos por exemplo).
- Estética e Design minimalista: devemos evitar sobrecarregar o usuário com informação demais, pois isso irá fazer com que sua mente tenha que processar toda essa informação antes de tomar decisões dentro do sistema. Num e-commerce por exemplo, pode significar até em menos vendas.
- Ajude os usuários a reconhecerem, diagnosticarem e recuperarem-se de erros: caso ocorra um erro no sistema, não diga simplesmente que ocorreu um erro (e olha que eu já vi muito sistema nem dizer isso), direcione o usuário para que ele consiga resolver facilmente o problema sozinho.
- Ajuda e documentação: o sistema deve ter uma área em que o usuário pode utilizar caso precise ajuda.
Conclusão ¶
É isso, queria me aprofundar mais, mas acho que ia ficar muito extenso, então decidi me manter ao que considero essencial para começarmos os estudos na área com a mentalidade correta.
Espero ter feito um bom trabalho em passar essa mentalidade de como podemos pensar nas nossas soluções como desenvolvedores, e como encarar melhor os problemas do dia a dia, além de introduzir o básico do básico dessa área para quem, assim como eu, é um desenvolvedor que nunca tinha se envolvido muito com Design.
Hoje, encaro muito diferente os problemas do dia a dia em relação a antes de começar os estudos na área. E isso refletiu muito na qualidade das soluções que proponho como desenvolvedor. Ter mais envolvimento e empatia com os usuários fez com que eu, por consequência, desenvolva melhores modelos de domínios e proponha soluções de mais qualidade.
Referências e recomendações de leitura ¶
EVANS, Eric. Domain-Driven Design: Atacando as Complexidades no Coração do Software. 2° Edição. Alta Books, 2010.
LOWDERMILK, Travis. Design Centrado no Usuário. 1° Edição. Novatec Editora, 2013.
NIELSEN, Jakob; LORANGER, Hoa. Usabilidade na Web: Projetando Websites com Qualidade. 1° Edição. GEN LTC. 2007.
NIELSEN, Jakob; BUDIU, Raluca. Usabilidade Móvel. 1° Edição. GEN LTC. 2013.
NORMAN, Donald A. O Design do dia a dia. 1° Edição. Anfiteatro, 2006.
Agradecimentos ¶
Ao meu amigo Gabriel Kamimura Yano, Frontend e UX Designer que abriu a minha cabeça para esse mundo, e com o qual tive diversas discussões que sem elas não teria conseguido escrever esse artigo.
Aos meus amigos Roberto Santos, Nickolas da Silva, e José Filho os quais tive ótimas discussões que ajudaram a amadurecer e conceber esse artigo.
Ao grupo de meetup UXCO (antigo UXCaféBR), o qual me acolheu e me ensinou muito.