Setembro de 2015

Volume 30 - Número 9

Aplicativos modernos: Práticas de usabilidade recomendadas

Rachel Appel | Setembro de 2015

Rachel AppelA usabilidade é um aspecto importante, porém muitas vezes negligenciado, do desenvolvimento de aplicativos. Os desenvolvedores tendem a deixar usabilidade nas mãos de especialistas em experiência de usuário e designers de interface do usuário. Existem, no entanto, alguns truques de usabilidade — alguns simples, outros mais complexos — que os desenvolvedores podem aplicar para obter um grande impacto.

A principal motivação é desenvolver um software fácil de usar. Isso significa que os comandos mais usados devem estar em destaque e prontamente disponíveis. Os comandos menos usados, por sua vez, devem estar disponíveis com o mínimo possível de cliques. Vamos analisar alguns truques de usabilidade que ajudam a criar ótimos aplicativos modernos.

Muitos desenvolvedores não gostam do termo “melhores práticas”. Ele parece implicar que a prática em questão é a única maneira de se fazer algo, e você sabe que isso não é verdade. Há práticas que funcionam bem na maioria dos cenários, e uma ampla variedade de técnicas que podem ou não funcionar bem. É por isso que a maioria reluta em usar o termo “melhores práticas”. Em vez disso, usarei o termo “boas práticas”. Essas práticas geralmente funcionam tão bem quanto outras maneiras de fazer as coisas, senão melhor. Isso não significa, porém, que você deva aplicá-las em todos os cenários.

Práticas inadequadas costumam ser claramente incorretas. São técnicas de criação ou desenvolvimento para as quais há uma maneira melhor de fazer as coisas. É fácil identificar práticas inadequadas porque eles geram software que não funciona. Todas as vezes que você teve vontade de arrancar cabelos por não conseguir usar um software, a culpa foi de uma prática inadequada.

Boas práticas de usabilidade

A primeira e, provavelmente, mais importante prática de usabilidade é a acessibilidade. Quanto mais acessível o software, mais fácil de usar. Existem alguns tipos de usuários para quem a acessibilidade é um desafio. Pense naqueles com pouca ou nenhuma audição, deficiência visual, motor ou cognitiva. É relativamente fácil desenvolver sites e aplicativos que incorporem design acessível. Muitas dessas técnicas incluem pequenas modificações em HTML ou CSS. Consulte a minha coluna “Criar e desenvolver aplicativos modernos acessíveis” (msdn.microsoft.com/magazine/dn913189) para obter mais detalhes sobre técnicas de design acessível.

Os comandos mais usados devem ser exibidos com destaque. Não obrigue seus usuários a ficar procurando informações. Em vez disso, use algo como a funcionalidade Início Rápido do Visual Studio, que permite aos usuários procurar por comandos digitando o nome ou um sinônimo de determinado comando. Adicione um recurso de Início Rápido aos menus regulares e à navegação. Sob a mesma perspectiva, não obrigue os usuários a trabalharem muito para realizar tarefas. Muitos usuários param em qualquer obstáculo e fornecem avaliações ruins em lojas de aplicativos quando não conseguem realizar tarefas facilmente.

A consistência é a chave para criar software de qualidade. Use estética consistente no aplicativo em si e entre o aplicativo e o sistema operacional. Uma reclamação comum de usuários é tentar usar em um dispositivo Android ou o Windows um aplicativo que tenta se parecer e se comportar como um aplicativo de iPhone. Uma das razões para um usuário comprar determinado dispositivo é gostar daquele estilo. Mantenha os paradigmas de estilo do sistema operacional host, depois lance mão de seu talento. Isso significa que, embora precise de bases de código separadas, você ainda vai poder compartilhar código de back-end entre os aplicativos.

A navegação consistente também é essencial. Use o mesmo estilo de navegação em todo o site ou aplicativo. Como parte de um bom design de navegação, verifique se os usuários têm acesso rápido aos comandos usados com frequência. Você pode determinar esses comandos fazendo logon toda vez que o usuário iniciá-los. Verifique se elementos como botões e controles de formulários têm rótulos consistentes. Se você estiver escrevendo um livro, ter um dicionário de sinônimos à mão para poder combinar de sinônimos é algo quer melhora sua prosa. Em software, usar palavras ou frases alternativas para as mesmas ações ou campos só serve para confundir os usuários.

Todo mundo já é obrigado a fazer logons demais. Um efeito colateral disso é que muitos usam a mesma senha para todos os recursos. Esse é o tipo de coisa que especialistas em segurança alertam para não fazer. Mesmo assim, os desenvolvedores criam sites da Web que incentivam essa prática inadequada, insistindo que você codifique sua própria infraestrutura de segurança em vez de usar um provedor de segurança confiável como OAuth, Microsoft ou Google. Até mesmo a autenticação do Facebook e do Twitter é melhor do que criar a sua própria.

Sempre que possível, dê opções aos usuários. Você pode criar seu próprio sistema de logon, mas, nesse caso, deverá cuidar da manutenção e terá de assumir a responsabilidade em caso de violação de dados. Ao escolher um provedor confiável, é ele que assume essa responsabilidade. Esses provedores têm equipes inteiras trabalhando na manutenção e na proteção de dados do usuário. Ao deixar a segurança com especialistas no assunto, você fica com mais tempo para ser o especialista de negócios e resolver os problemas de negócios com seu software.

Os padrões apropriados ainda percorrem um longo caminho em direção à acessibilidade. Estamos em 2015, e muitos sites e aplicativos ainda obrigam o usuário a inserir a cidade e o estado, em vez de solicitar um código postal e preencher os detalhes automaticamente. Inserir uma pequena sequência de números é algo muito fácil para os usuários quando comparado à necessidade de selecionar itens de uma lista enorme em uma pequena lista suspensa. Confira minha coluna “Uma primeira abordagem de dispositivos móveis para desenvolvimento de aplicativos modernos” (msdn.microsoft.com/magazine/dn948114) para obter mais detalhes sobre como criar software usando design voltado para dispositivos móveis.

Interfaces de usuário dinâmicas se ajustam ao formato e aos recursos de um dispositivo específico. Obviamente, adaptar o software para o dispositivo é algo bom para os usuários. Interfaces de usuário dinâmicas tendem a ser desenvolvidas, em primeiro lugar, para dispositivos móveis. E designs voltados para dispositivos móveis tendem a ser mais fáceis de usar do que os de software tradicionais. Para saber mais sobre interfaces de usuário dinâmicas, consulte “Criar uma interface de usuário dinâmica e moderna com CSS para aplicativos do WinJS” (msdn.microsoft.com/magazine/dn451447).

Um design minimalista é outra característica de aplicativos modernos. Os usuários rejeitam aplicativos que os sobrecarreguem com muitas opções raramente usadas. Eles preferem aplicativos simples e que apresentem as opções necessárias de acordo com o contexto. Em aplicativos para Windows 8 e versões posteriores, é possível usar barras de aplicativo que ficam ocultas enquanto o usuário trabalha no aplicativo, para depois apresentar opções conforme necessário.

Práticas de usabilidade inadequadas

Muitos sites e aplicativos incluem formulários que exigem que o usuário insira o email duas vezes. Se ele não consegue digitar o email corretamente, por que conseguiria inserir corretamente informações como endereço, cidade, estado, entre outras? Por que esses campos não são duplicados?

Pedir a um usuário para digitar o email novamente é irritante. Isso ocorre porque seres humanos são criaturas de hábito. Digitação e erros de ortografia são hábitos como outros quaisquer. A probabilidade de erro de digitação é a mesma em ambas as caixas.

O conceito de Captcha é nobre. Um site ou aplicativo mostrará uma imagem que contém um número, uma palavra ou uma frase. O usuário deve inserir a informação mostrada. Essa informação costuma ficar parcialmente obscurecida para que computadores não consigam identificar a imagem. O problema é que hoje em dia os sistemas de inteligência artificial conseguem reconhecer imagens e decifrar facilmente um Captcha. A maioria das pessoas, ironicamente, têm dificuldades com isso. O olho humano está no mesmo nível que os computadores no que diz respeito a examinar um padrão obscurecido. Às vezes, o que parecia uma boa ideia acaba se revelando um fracasso.

A rolagem infinita e as atualizações de página automáticas também são problemáticas, especialmente para aqueles que dependem de tecnologias auxiliares, como narradores de tela. Embora o Facebook e, mais recentemente, o Twitter façam bem a rolagem infinita, ainda pode haver dificuldades na chegada de novos conteúdos que se sobrepõem ao que havia antes. Considere a possibilidade de tentar entradas alternativas e dispositivos acessíveis se estiver implementando esses recursos.

Botões Fechar pequenos podem enlouquecer até os usuários mais experientes. É comum que usuários de dispositivos sensíveis ao toque não consigam usá-los porque a área é pequena demais para responder ao toque. Isso não é tão ruim se o botão Fechar for fácil de visualizar. Muitas caixas de diálogo, no entanto, contêm apenas um botão para continuar, sem maneira de voltar. Aplicativos modernos e dinâmicos sempre oferecem uma maneira fácil para desfazer ações.

A formatação inadequada é a ruína do design de sites. Muitos usuários tem calafrios quando veem um campo para inserir o telefone em um formulário. Nunca se sabe que tipo de validação maluca está acontecendo. Este campo está pedindo o código do país? É preciso digitar os parênteses e os traços, ou somente os números? O usuário geralmente tenta inserir o formato de número que acreditam ser correto, para logo depois ser repreendido por uma caixa de diálogo modal que interrompe ainda mais o fluxo de trabalho.

Junto com os assustadores campos de telefone vêm os campos de URL. Muitos deles não colocam o http:// automaticamente. Os mesmos sites e aplicativos nunca dizem que o http:// é necessário até você clicar em enviar, a validação falhe e os campos de formulário sejam redefinidos.

Há todo um conjunto de práticas inadequadas relacionadas a falhas de formulário. A única razão para a existência de formulários é capturar dados. Ainda assim, os desenvolvedores costumam fazer formulários difíceis e confusos. É enlouquecedor tentar preencher um formulário que insiste em limpar os dados se você esquecer algum dados ou fizer algo errado. Muitos sites e aplicativos continuam a fazer isso. Demora duas vezes mais tempo para fazer tudo.

Se seu aplicativo está tentando fazer dinheiro, essa é uma péssima opção. Você está impedindo o usuário de fazer compras. Quanto maior a chance de um aplicativo fazer coisas como limpar formulários, maior o tempo que o usuário levará para preenchê-los. Quanto mais tempo levar este processo, maior a probabilidade do desenvolvedor ter decidido limpar o formulário de usuários desavisados.

Outra falha de formulário não implementar os padrões apropriados. A maioria dos seus usuários é de seu país? O padrão deve ser esse, mas outros países devem ser exibidos. O mesmo se aplica a estados, códigos postais ou os valores mais popular de qualquer campo específico. Se seu aplicativo já foi implantado, você pode verificar esses valores no banco de dados. Se ainda está em desenvolvimento, pergunte aos usuários. Um padrão que sites da Web parecem nunca esquecer, no entanto, é definir a opção de marcar para receber um boletim informativo ou informações de produtos.

Muitos sites e aplicativos não fornecem a funcionalidade de pesquisa apropriada. Alguns sequer fornecem uma funcionalidade. O site Search Engine Watch diz que avassaladores 92% dos usuários da Web usar pelo menos um mecanismo de pesquisa o tempo todo.

Apresente resultados de pesquisa em resumos fáceis de consumir e de maneira clara e consistente. Coloque anúncios em torno de resultados de pesquisa ou conteúdo, mas nunca sobre esses resultados e conteúdos. Quando vê um anúncio dentro de um conjunto de resultados de pesquisa, o usuário pode pensar que é chegou ao fim dos resultados e desistir da pesquisa por não ter encontrado o que queria.

Há várias dicas sobre o que não fazer em termos de design de interface do usuário. Eu gosto de chamar essas falhas de “interfaces do usuário duras de se ver”. São erros como fontes minúsculas que precisam ser ampliadas para a leitura, anúncios demais ou anúncios dentro de anúncios. Muitos sites e aplicativos dependem de receitas de publicidade, por isso anúncios são um mal necessário. No entanto, quando anúncios trazem outros anúncios (sim, isso está acontecendo), o que temos é um desastre.

Muitas escolhas infelizes relacionadas a padrões de usabilidade estão relacionadas à escolha e à localização de botões. Em geral, um botão designado para continuar ou levar a uma ação aparece em vermelho brilhante. Essa cor indica parar ou cancelar uma ação. Deve-se fazer como em semáforos, cujas cores verde, amarela e vermelha tendem a indicar seguir, ter atenção ou parar, respectivamente.

Outras práticas de usabilidade

A navegação se enquadra em “outros princípios de usabilidade” porque há alguns tipos de navegação úteis para a facilidade de uso, outros, não. Ao projetar um esquema de navegação, ele deve ser claro e consistente. A melhor opção é seguir os paradigmas do sistema operacional do host. Manter a consistência entre o aplicativo e o sistema operacional facilita a vida dos usuários. Isso é especialmente verdadeiro no caso de novos usuários ou aqueles que não usam muito a tecnologia. No entanto, essa orientação também se aplica a usuários experientes que gostam de atalhos com base na consistência de paradigma.

Menus com guias geralmente são mais adequados e mais fáceis de navegar. No entanto, se houver muitas linhas de guias, fica difícil navegar. Aplicativos de área de trabalho funcionam bem com as estruturas de menu suspenso tradicionais, mas aplicativos para Web e de dispositivo nativo geralmente exigem um esquema diferente. O Windows Phone, por exemplo, usa Blocos Dinâmicos para aprimorar a experiência do usuário, fornecendo áreas grandes e fáceis de tocar para iniciar aplicativos ou navegar.

Acredita-se que menus hambúrguer diminuam significativamente o comprometimento de um aplicativo ou site da Web, de acordo com o site de tecnologia de mídia TechCrunch. Se escolher um menu hambúrguer, você precisará se manter informado sobre as estatísticas de uso. Para obter mais informações sobre os fundamentos de usabilidade de navegação , consulte “Noções básicas de navegação nos Aplicativos da Windows Store” (msdn.microsoft.com/magazine/dn342878).

Conclusão

Como regra geral, quanto mais acessível, mais utilizável é um software. Você pode aumentar a base de usuários em 20% se implementar pequenas alterações. É uma porcentagem considerável em termos de padrões de negócios, e qualquer gerente que faça jus ao posto que ocupa (mesmo chefes mal-humorados) arregalaria os olhos diante desses números. Uma ótima maneira de incorporar a acessibilidade e, portanto, de alcançar melhor usabilidade, seria experimentar tecnologias acessíveis por si mesmo. Feche os olhos e tente usar uma página com um leitor de tela. Use um dispositivo de voz.

Embora algumas práticas aqui sejam listadas como “boas” ou “ruins”, isso não significa que sejam sempre uma coisa ou outra. Você sempre pode quebrar o ciclo de práticas inadequadas e fazer algo mais utilizável. É possível que as práticas recomendadas deem errado, também. Pergunte aos usuários do que eles gostam, mas não acredite sempre neles, porque também o cliente nem sempre tem razão. Monitorar o uso do aplicativo é uma ótima maneira de ver o que eles realmente estão fazendo. Use o bom senso.


Rachel Appel* é consultora, autora, mentora e antiga funcionária da Microsoft com mais de 20 anos de experiência no setor de TI. Ela dá palestras em importantes congressos do setor, como o Visual Studio Live!, o DevConnections, o MIX e muitos outros. Sua experiência está ligada a soluções de desenvolvimento que alinham negócios e tecnologia com foco na pilha de desenvolvimento da Microsoft e em Web aberta. Para obter mais informações sobre a Appel, visite seu site em rachelappel.com.*

Agradecemos ao seguinte especialista técnico da Microsoft pela revisão deste artigo: Frank La Vigne