É nossa responsabilidade construir aplicativos altamente intuitivos - Emptor.

Aprendi muito como desenvolvedor de software em 2010. Na época, eu estava trabalhando na Ikea implementando grandes projetos, e lá tive a oportunidade de usar frameworks e bibliotecas sobre os quais eu só havia lido. Tudo era novo e surpreendente para mim, mas o mais surpreendente foi a cultura. A empresa, entre muitas coisas, usava um conceito de escritório aberto. Cada departamento era composto por elegantes mesas estilizadas para facilitar a comunicação entre os departamentos. Meu local de trabalho ficava ao lado do departamento de TI - posicionado estrategicamente para nos ajudar com o suporte ao usuário e, às vezes, até nos culpar por bugs quando a causa raiz era algum bug nosso.

Uma tarde, quando era hora de ir para casa, após uma ligação urgente de suporte, ouvi algo que não esperava: um colega de TI disse: “Não foi um erro do sistema, foi um problema de camada 8.” Foi a primeira vez que ouvi essa piada, mas curiosamente não foi engraçada para mim. Fui para casa pensando em quanta responsabilidade temos pelos erros que os usuários cometem com nossos sistemas.

Espere um minuto, eu acabei de dizer erros cometidos pelos usuários… embora “um problema de camada 8” seja uma piada comum, ela requer alguma explicação.
(Nota: Se você é um ninja de sysadmin, pule essa parte 😉)

O modelo de Interconexão de Sistemas Abertos (modelo OSI) é um modelo de referência para protocolos de rede e visa interconectar sistemas de diferentes fontes. Ele é dividido em várias camadas ou níveis:

• Camada Física: estrutura física (wireless, cabo coaxial, repetidores, hubs)
• Camada de Enlace de Dados: Quadros (ethernet, switches, bridges)
• Camada de Rede: Pacotes (IP, IPSec, IGMP)
• Camada de Transporte: Conexões ponto a ponto (TCP, UDP)
• Camada de Sessão: Sincronização e envio para porta (APIs, Sockets)
• Camada de Apresentação: Camada de sintaxe (SSL, SSH, FTP)
• Camada de Aplicação: Camada de usuário final (HTTP, FTP, IRC)

Você notou que existem apenas 7 camadas… a 8ª camada que o cara de TI mencionou era o usuário. Um erro na 8ª camada significa que é culpa do usuário. (Eu sei, eu poderia apenas dizer essa última parte, mas pense nisso, agora você também sabe sobre o modelo OSI.)

Deixe-me colocar dessa forma… digamos que um médico gaste mais de 10 anos em uma universidade para aprender a desempenhar seu trabalho; quando ele estiver trabalhando em um hospital, provavelmente perdeu a maior parte de uma década de mudanças tecnológicas. Como podemos esperar que eles saibam usar sua (preguiçosamente construída) interface do usuário, se eles não têm muito tempo para mais nada enquanto estudam medicina? A mesma interface que você construiu com o mantra: “Vou colocar isso em qualquer lugar, não sou designer!” Eu sei, não foi feito intencionalmente; parte do problema é que tendemos a nos comparar com o usuário; usamos a nós mesmos como protótipo do usuário. Mas sabe o que? Você e o usuário estão longe de ser os mesmos.

Parte do problema é que tendemos a nos comparar com o usuário; usamos a nós mesmos como protótipo do usuário.

Você precisa ter conversas reais ou interação com seus usuários reais. Não espere até a fase final do projeto para adicionar um pouco de UX a ele; geralmente isso não funciona. A UX é muito importante e, à medida que a concorrência evolui, cada empresa deve trabalhar mais para construir algo com o qual todos os usuários possam interagir.

Como eu disse antes, você pode dizer: “Não sou designer, não preciso me preocupar com isso.” Mas você pode encontrar casos como “O botão de $300 milhões”, onde uma empresa fez uma mudança em um rótulo em seu site de comércio eletrônico e viu um aumento de $15 milhões em receita no primeiro mês e mais $300.000.000 até o final do ano. Pense nisso - é impressionante que uma mudança tão “minúscula” possa ter um impacto tão massivo na receita. Cada caso é diferente. Talvez você esteja focado em reduzir o número de chamadas de suporte, inclinando-se mais para o self-service: por exemplo, os engenheiros da McAfee projetaram um processo que reduziu em 90% as chamadas de usuários para obter suporte. Parece incrível, não é?

É nossa responsabilidade como engenheiros facilitar a jornada do usuário e do cliente.

Todos nós já ouvimos alguém dizer: “Ah, meu filhinho é tão inteligente, ele sabe usar um iPad e ele tem apenas 3 anos.” A verdade é que alguns engenheiros muito inteligentes se esforçaram para construir uma interface incrivelmente amigável ao usuário. Poderíamos testá-la dando à mesma criança um velho Palm Treo para ver quanto tempo ela gasta tentando usá-lo.

Agora vou lhe dar 3 pontos a ter em mente quando se trata de construir aplicativos.

1. Torne-se centrado no usuário.
   Pare de tomar decisões com base em coisas como ego, tópicos quentes ou algo que seu influenciador tecnológico favorito acabou de tuitar. Sua decisão deve ser guiada pelas necessidades, objetivos, expectativas e motivações do usuário, e não as suas.

   Sempre que você tiver a oportunidade de construir algo, você deve construí-lo com o usuário em mente. A usabilidade é melhor do que a beleza, e os usuários lhe agradecerão quando descobrirem como usar um novo recurso sem gastar muito tempo lendo instruções. Eles ficarão mais felizes e produtivos se você colocar apenas as opções de que eles podem precisar, em vez de todas aquelas que você, com seus superpoderes, é capaz de criar.

2. Evite comportamento preguiçoso com a UX.
   Eu sei, temos que levar várias coisas em consideração quando estamos construindo, como: interpretar bem os requisitos funcionais, considerar requisitos não funcionais que não foram listados nos requisitos e talvez também usar alguma linguagem de programação ou biblioteca incrível. Todas essas coisas para “Exibir um número incremental em um rótulo”. Realizar todas essas coisas pode consumir muita da sua energia, então quando se trata de se preocupar com como o usuário vai usá-lo, talvez você não esteja prestando muita atenção a isso.

   Você deve usar autocontrole para evitar cometer alguns erros básicos de UX; aqui estão alguns “não faça”:

   • Não jogue toneladas de dados na tela: Eu não conheço seu usuário, mas eles provavelmente não precisam de todo o banco de dados na tela de uma vez.
   • Não exponha a tecnologia ao usuário: mesmo como uma pessoa técnica consumindo uma API externa, esperamos receber uma mensagem bem formatada para um código de erro.
   • Não seja inconsistente: se você já decidiu mover o botão de fechar para a parte inferior da janela, certifique-se de que seja o mesmo em todas as suas janelas.

3. Esteja ciente dos vieses cognitivos.
   Os vieses cognitivos são “bugs” que a mente humana possui. Você pode encontrar uma lista muito extensa por aí e ver como eles podem afetar a percepção da realidade pelas pessoas. É muito importante saber que você pode ser afetado por um deles quando estiver criando algo, então aqui estão alguns comuns para ter em mente:

   • Viés de ponto cego é o viés cognitivo de reconhecer o impacto dos vieses no julgamento dos outros, enquanto não consegue ver o impacto dos vieses em seu próprio julgamento.
   • Déformation professionnelle (“nerdview”) é a tendência de olhar as coisas do ponto de vista de sua própria profissão ou especialidade, em vez de uma perspectiva mais ampla ou humana.
   • Reflexo de Semmelweis é uma metáfora para a tendência reflexiva de rejeitar novas evidências ou novos conhecimentos porque contradizem normas, crenças ou paradigmas estabelecidos.
   • O efeito manada é um fenômeno pelo qual a taxa de adoção de crenças, ideias, modismos e tendências aumenta em relação à proporção de outros que já o fizeram. À medida que mais pessoas acreditam em algo, outros também “entram no barco”, independentemente das evidências subjacentes.
   • Viés de confirmação é a tendência de procurar, interpretar, favorecer e lembrar informações que confirmam ou apoiam suas crenças ou valores anteriores.

Finalmente, quero deixá-lo com o pensamento de que assumir a responsabilidade por como os usuários vão usar o aplicativo que você está construindo é a maneira mais justa de pensar sobre isso, porque, no final, você é o profissional na construção de software. Pense um pouco sobre os usuários, não importa que tarefa eles estejam realizando. É seu dever ajudá-los com seus aplicativos, em vez de trazer-lhes mais problemas.

Sempre que você se encontrar pensando algo como “Eles pedem um formulário, aqui está um formulário”, lembre-se de toda a frustração que você sente ao usar qualquer software horrível em sua vida diária, talvez porque não há outra opção. Pense que você tem a oportunidade de deixar alguém feliz; toda vez que eles usarem esse formulário que você está prestes a criar.

Se você gosta desse tipo de conteúdo, sinta-se à vontade para nos seguir em nossas contas de redes sociais.