Profile

Scrapbook photo 1
Adalto Junior
120 followers|1,622 views
AboutPostsPhotosVideos

Stream

Adalto Junior

Shared publicly  - 
1
Add a comment...

Adalto Junior

Shared publicly  - 
1
Add a comment...

Adalto Junior

Shared publicly  - 
 
Legal, se acostumar com o novo layout.
1
Add a comment...
Have him in circles
120 people
Karlyson Felipe's profile photo
Pierre Diderot's profile photo
Rafaela Carvalho's profile photo
Mário Chaves's profile photo
duarte joabe Moura's profile photo

Adalto Junior

Shared publicly  - 
 
Massa
1
Add a comment...

Adalto Junior

Shared publicly  - 
 
 
Dica para apps Android: fale a linguagem do usuário.

Resumo (TL;DR): Ao se comunicar com o usuário através de mensagens de erro, tutoriais ou qualquer outra coisa, concentre-se no que ele está fazendo ou quer fazer, não em como o app faz aquilo. O usuário quer que o carro ande, ele não quer saber o nome das peças.

O desenvolvedor e o usuário falam idiomas muito diferentes. Nós, como desenvolvedores, às vezes nos perdemos no nosso próprio mundo de classes, interfaces, métodos, registros, colunas, inteiros, floats, strings e estruturas de dados realmente impressionantes (e outras nem tanto). Nós nos divertimos muito nesse mundo e até olhamos para o usuário com uma certa pena, sabendo que a visão do mundo que ele tem é que tudo num app se dá por uma espécie de magia misteriosa e não pela meticulosa organização do código e perfeita sequência de instruções que você, o desenvolvedor, colocou ali para que essa mágica acontecesse.

Até aqui, tudo ótimo. O problema é quando nós esquecemos dessa barreira, e isso acontece justamente na hora em que vamos fazer algo em que às vezes não somos especialistas: a comunicação com o usuário. É aí que cometemos um erro muito frequente, que é achar que o usuário está interessado em como o app faz algo e não no efeito prático daquilo. Já reparou essa diferença? Nós vemos o app a partir da ótica de "como eu faço"; o usuário o vê a partir da ótica do "o que eu quero fazer". É preciso tomar cuidado com a tradução entre essas duas perspectivas.

Um exemplo. Suponha que o meu app permite ao usuário comprar episódios de seriados e assistí-los. Na minha tela principal, há uma tab que se chama "Destaques", outra chamada "Categorias" e outra chamada "Meus Episódios". Eu acho que o meu app está excelente: ele funciona perfeitamente, não tem bugs horríveis e, claro, segue o padrão visual do d.android.com/design. A navegação também está perfeitamente implementada -- todas as telas têm Action Bar, a navegação "up" está correta, estou usando Action Buttons, Action Overflow, etc.

Ok, o usuário acabou de baixar o meu app. Ele nunca o usou antes. Em seguida, ele clica na aba "Meus Episódios". O que acontece? O meu app mostra uma tela vazia. Óbvio. O usuário não tem episódios comprados. O fato da tela estar vazia está perfeitamente correto, não é? O incorreto seria mostrar um episódio lá, pois o usuário não possui nenhum. Qual é o problema?

Bom, o problema é o seguinte. Se há 2 itens na tela, o usuário entende que existem 2 itens na tela. Se há 1 item na tela, o usuário entende que existe 1 item na tela. E se não houver nenhum item na tela, o que o usuário acha? Não, ele não acha que não existem itens, ele acha que o app está com defeito! Espere... como assim?

Calma. Não, não é que eles não entendam o conceito de zero. Já vi muitos usuários dizendo que dariam nota zero para um app, então eles sabem muito bem o que é zero. O que acontece é outra coisa: é que o usuário está acostumado ao conceito de que toda tela de um app existe para um único propósito: para serví-lo. Sim, que pretensioso da parte deles, não é? Mas é verdade. A tela está lá porque é útil; se não fosse útil, não estaria lá. Uma tela com 2 itens é útil; uma tela com 1 item é útil; mas uma tela com nada... é inútil.

Ok, ok, entendi. O usuário não quer uma tela vazia? Então vou colocar alguma coisa lá. Eu modifico meu app e lanço uma versão nova e fico esperando os reviews positivos. Agora, quando um usuário novo clica na aba "Meus Episódios", eu faço a busca no meu banco de dados e, caso eu não encontre resultados, eu mostro uma mensagem ao invés de deixar a tela vazia. Essa mensagem explica o ocorrido de modo direto e preciso:

"A busca retornou 0 itens."

E agora? O usuário está feliz?

Não. Provavelmente ele está mais confuso ainda. Mas que busca? Mas que retorno? Eu estou falando grego com o usuário; aliás, pior que isso: estou respondendo em grego a uma pergunta diferente daquela que ele fez. O usuário não fez nenhuma busca, até onde ele saiba. O fato de que eu implementei essa tela como uma busca no banco de dados é um fato que eu acho lindo, mas é completamente irrelevante para o usuário; o fato de que buscas "retornam" coisas também é um detalhe técnico (aliás, em português isso nem está certo -- meus professores não conseguiram me livrar do hábito de usar "retornar" em lugar de "devolver").

Mas, enfim, a tal busca retornou (ou devolveu) 0 itens. Mas... o que é um item!? O usuário não compra itens, ele compra episódios de seriados. Quando ele está no sofá rolando de rir, ele não diz "Esse item é hilário!". Ele não pergunta para os amigos "O que você achou do item que passou ontem na TV?". Ele não vai ao cinema porque há um item legal em cartaz.

Fora isso, para o usuário, a "busca" (se ele tivesse feito uma) não é essa coisa personificada. A busca não é um ser pensante. Não faz sentido dizer que a busca "faz" algo, não "falha" e não "retorna", muito menos retorna "itens". A busca não é uma pessoa nem um bicho. Isso só existe na nossa lógica: o gato mia, o cachorro late, a busca retorna. O usuário não quer saber de "busca". O que importa para ele é conseguir consumir o conteúdo que ele quer.

A "busca" é simplesmente o meio. Isso para nós desenvolvedores é contra-intuitivo, porque nós achamos que a busca, o mecanismo, o algoritmo é a parte mais importante do programa; tão importante que ela vira o personagem principal na nossa comuicação: "a busca falhou" (droga, estávamos torcendo por ela), "a busca foi feita com sucesso" (parabéns, busca!), "insira termos corretos para a busca" (a busca é uma espécie de faraó: tragam os termos corretos, escravos!). O mesmo acontece com outros bichos da nossa fauna como a sincronização (ela terminou com erro), a autenticação (ela requer que uma senha seja digitada... que exigente, né?). Note essa última. A autenticação é uma criatura (voz ativa), mas digitar a senha, que é a ação do usuário, está na voz passiva! A senha é digitada. Por alguém que não importa: o usuário é deixado de lado, nem sequer é mencionado. Bom, já está melhor do que numa outra mensagem que vejo frequentemente: "autenticação falhou: usuário inexistente." Ignorá-lo é uma coisa, mas chamá-lo de inexistente é ir longe demais, não é?

Mesma coisa com "o cadastro requer um número de cartão de crédito válido." Que cadastro exigente! Não melhora muito se mudar para "digite um número de cartão de crédito válido." Por incrível que pareça, o usuário não sabe calcular checksums para saber se um número de cartão é válido ou nao.

Nesses casos que mencionamos até agora, o que faria sentido para o usuário? Sim, algo mais útil, que foca naquilo que o usuário quer fazer, e não em como o app faz aquilo. Oras, se o usuário está vendo a aba "Meus Episódios" do meu app é porque em algum lugar dentro dos sonhos e aspirações dessa criatura, certamente existe algum grau de vontade de possuir um episódio. É isso que ele quer. Assim, não seria bem melhor essa tela dizer algo como "Você ainda não possui episódios de seriados. Conforme você os adquirir, eles aparecerão nesta tela." Logo abaixo disso, que tal colocar botões que levam o usuário diretamente para as seções mais populares da sua loja? Sério, não fazer isso é um desperdício! Anunciantes em todo lugar estão sempre loucos para conseguir uma oportunidade de oferecer algo para um usuário que tem uma intenção clara; fazer isso é um dos maiores desafios de anúcios. E você tem o usuário ali, na palma da sua mão, claramente querendo consumir o seu conteúdo e te dar dinheiro por isso. É justo você dar para ele uma tela em branco, ou uma mensagem esquisita sobre buscas, retornos e itens?

Mesma coisa com "autenticação falhou: usuário inexistente". Em primeiro lugar, tire a tal da "autenticação" da cadeira VIP; já chega dela ficar lá, falando que eu não existo. Que tal: "Esse login não corresponde a um usuário cadastrado. Verifique que você o digitou corretamente. Caso ainda não tenha um login, clique no botão 'Registre-se!' para criar uma conta". Só falta uma coisa: o que é login? Ok, se você sabe que o seu usuário sabe disso, pode usar. Mas se não tem certeza, melhor explicar melhor. Substitua pelo termo correto para seu app. E seja consistente: se você chama de "login" nessa tela, não chame de "nome de usuário" na outra e de "identificador de conta" numa terceira.

No caso do cartão de crédito, ao invés de falar "o cadastro requer um número de cartão de crédito válido", seria melhor algo como: "Você digitou um número de cartão de crédito incorreto. Digite o número completo do seu cartão, com 16 dígitos e sem separadores."

Só que ainda estamos acusando o usuário de digitar um número errado. Pode ser que ele tenha digitado certo e seja nossa culpa, ou o cartão pode estar sem saldo. Que tal então: "Esse cartão de crédito não foi aceito pela operadora. Por favor verifique se você digitou o número corretamente, com 16 digitos e sem separadores."

Resumindo: ao se comunicar com o usuário, lembre do mais importante: deixe de lado os algoritmos, os processos e as estruturas de dados. Fale com ele como se ele fosse o ponto central do seu aplicativo (porque ele é), e como se ele tivesse algo útil que ele está tentando fazer (porque ele tem), e facilite para que ele o faça.
1
1
Add a comment...

Adalto Junior

Shared publicly  - 
1
Add a comment...
People
Have him in circles
120 people
Karlyson Felipe's profile photo
Pierre Diderot's profile photo
Rafaela Carvalho's profile photo
Mário Chaves's profile photo
duarte joabe Moura's profile photo
Basic Information
Gender
Male
Relationship
Married