|
Análise de usabilidade do registro em um
sorteio
Julho, 2006
Jorge Marmion
Há alguns dias, ao carregar combustível em um
posto de gasolina de uma grande distribuidora, o frentista me convidou a
participar de um sorteio de combustível, e ao aceitar me entregou dois cupons
que eu devia registrar para participar da promoção.
O cupom, cujas laterais tinha de rasgar para ler o
conteúdo, continha um número, que eu devia informar ou por telefone ou através
de um site cujo endereço constava no interior.
"Eis uma aplicação interessante", pensei, já que:
- Não é possível determinar o grau de instrução do
usuário. Pode tanto ser um doutor em ciências da computação ou seu motorista,
que talvez mal acabou o ensino primário;
- Não é possível saber qual o grau de experiência
do usuário com um computador ou com a internet. Pode ter profunda experiência na
manipulação de diversas aplicações, ou ter acabado de receber em casa seu
primeiro computador, comprado em 50 parcelas;
- Não é possível treinar o usuário no aplicativo.
Ou o usuário "se vira", ou não completa a tarefa.
Como será que nossos colegas solucionaram o
problema? Muito bem, eu diria.
Ao ingressar no endereço divulgado no cupom, um "box"
com uma cor vibrante, que se destaca do resto das cores, convida o usuário a
participar da promoção.
Impossível não ver. Nota dez.
Poderíamos argumentar que o contraste dos dizeres do box com o fundo é
inadequado. É mesmo, mas o conteúdo é irrelevante.
Após clicar no link apropriado, abre
uma nova tela, que mantém as cores da tela anterior (algo positivo) e apresenta
instruções sobre como participar da promoção. Um botão, cuja cor contrasta
adequadamente com a cor de fundo, convida o usuário a clicar e preencher o
formulário para participar. (Nota: esta tela, e algumas das que seguem, foram
propositalmente alteradas para ressaltar a região de interesse em nosso artigo):
Novamente, nota dez para o
projetista. Se você só quer registrar seu cupom e não está interessado em detalhes, em poucos instantes consegue saber como
continuar, evitando perder tempo lendo detalhes (para você) inúteis.
Após clicar no botão, e passar
por uma tela intermediária de confirmação (para evitar fraudes de robots), uma
nova tela pede o código do cupom e algumas informações do usuário:
e ao descer a barra de rolagem há
uma pergunta cuja resposta (óbvia) está assinalada.
As informações solicitadas são
claras, as perguntas e respostas são pertinentes (especialmente quanto à necessidade
de informar CPF, algo que desperta muitos receios), o fato de assinalar a
resposta correta é totalmente acertado, mas .... essa barra de rolagem! Me
pergunto se um usuário sem a suficiente experiência em manipulação transacional
saberá, sem ajuda de terceiros, que tem de descer a barra de rolagem para
visualizar o resto da tela. A resposta que imagino definitivamente não me deixa tranqüilo.
Eu optaria por projetar novamente a tela, compactando espaços e permitindo que
todas as informações necessárias fossem apresentadas em uma única visualização.
E aproveitaria para "bolar" um botão "Avançar" mais "sexy"; para mim esse que
está aí destoa do resto da tela (mas isso, convenhamos, nada ter a ver com usabilidade). Eis
uma proposta alternativa (que aproveita o botão atual):
Quanto ao Telefone, obviamente o primeiro campo é o DDD. Bem, esse "obviamente" também me deixa intranqüilo. Eu não
arriscaria: escreveria, abaixo do primeiro campo, "DDD" e abaixo do segundo,
"Número", em letras pequenas, do tamanho das perguntas e respostas.
Após informar os dados solicitados e
clicar no botão Avançar, é apresentada uma tela parabenizando o usuário por ter
completado a transação, e instruindo-o a guardar o cupom. E a distribuidora aproveita a oportunidade para "vender o peixe" do
seu cartão, mas isto é feito ética e até discretamente, e não há qualquer obrigação de continuar:
Em resumo, uma bela implementação. É
fácil saber o que fazer, e mesmo um usuário sem muita experiência
consegue completar a tarefa (ressalva feita à tal barra de rolagem).
Há, entretanto, uma melhoria que
poderia aprimorar o fluxo transacional. Um cartão lhe é dado cada "x" litros de
combustível que você carrega. Caso você encha o tanque, e este estiver vazio,
provavelmente você ganhará dois ou três cupons. E na última tela não há como
retornar diretamente à primeira. Uma opção "Informar mais um cupom" seria muito
conveniente, e evitaria vários retrocessos ou, então, digitar o endereço do site
novamente.
Lições que podemos aprender deste
caso:
-
Não enrole. O usuário tem de saber
rapidamente o que fazer. Destaque as ações mais prováveis (a primeira tela desta
transação é um excelente exemplo).
-
Mantenha o "look and feel" da
transação através de todas as telas. Isso cria uma sensação de familiaridade.
-
Evite barras de rolagem em
aplicações de uso público cuja audiência tem um espectro cultural muito grande
ou desconhecido. A barra é aceitável em um formulário de inscrição online em uma
faculdade, por exemplo. No exemplo que estamos comentando, nem arrisque: projete
novamente a transação para eliminá-la de vez. Se não for possível neste caso
"empacotar" tudo em uma tela, transfira a pergunta a uma próxima tela, onde você
poderia dizer, para amenizar: "Você está quase lá. Só falta responder uma
pergunta ...."
-
Planeje o fluxo transacional
considerando as possibilidades após a transação corrente ter sido completada. É
possível executar um novo ciclo desta mesma transação? Ou, após finalizada,
acabou (exemplo: removi meu endereço de e-mail do sistema de newsletter de um
site).
|
