Registo de Utilizadores num Contexto Móvel – Parte II

01/07/2016 Paulo Ribeiro

Problemas, Necessidades e Equívocos

A primeira pergunta que devemos fazer é: Devemos introduzir uma barreira de registo ao nosso produto? Por favor, não confundir esta pergunta com “Devemos ter um processo de registo de utilizador de todo?”, uma vez que são dois conceitos completamente diferentes. Devemos ter um processo de registo de utilizador porque este permite a criação de uma identidade para um utilizador dentro do nosso sistema, que irá fornecer, continuamente, informações sobre esse utilizador em particular, o que por sua vez nos dá uma vantagem competitiva, em termos comerciais, em relação a esse utilizador. A barreira de registo a que me refiro pode ser facilmente entendida como o passo adicional e intencional que é adicionado à experiência de utilização aquando do processo de registo de utilizador. Geralmente, o processo de registo de utilizador (e de login) interrompe a execução e o fluxo da aplicação tornando-o intrusivo e pode levar a que os utilizadores fiquem frustrados e possivelmente irritados (quantos de nós decidimos desinstalar uma aplicação após a primeira utilização da mesma, simplesmente porque não queríamos terminar um tedioso processo de registo?). Assim, o primeiro compromisso que precisamos de defender e exercer passa por fazer sempre o nosso melhor quando criamos experiências de utilização para as nossas aplicações, desenvolvendo todos os esforços no sentido de nunca comprometer.

Embora o ambiente de desenvolvimento de aplicações móveis tenha amadurecido ao longo dos anos ainda vemos problemas decorrentes de más escolhas de design, principalmente em termos de UI e UX, erroneamente focadas numa orientação para desktop. Isto também se reflete ao nível do fluxo de registro de utilizador em aplicações móveis. A maioria dos processo de registo de utilizador dependem do preenchimento de formulários por parte dos mesmos. Os formulários são um mecanismo muito utilizado e comum em web sites que exigem input do utilizador. Em teoria, a utilização de formulários permite a captura de uma quantidade considerável de dados de utilizador (nomes, informação de contato, moradas) de uma só vez, que podem ser usados de várias formas e com muitas finalidades diferentes (marketing direcionado, destinos de envio, etc.). Contudo, o uso de formulários não é adequado num contexto móvel. Passemos em revista alguns dos problemas que o uso de formulários criam dentro deste contexto:

Fazem com que os utilizadores necessitem de escrever bastante

Os formulários estão inerentemente cheios de campos de entrada de texto e escrever não tem a mesma experiência de utilização num contexto móvel. Temos uma experiência muito diferente ao escrever num teclado virtual (num contexto móvel) versus escrever num teclado físico (num contexto de desktop). Isto leva a conflitos com as expectativas / desejos dos utilizadores:
- Propensão a erros enquanto os utilizadores esperam inputs corretos;
- Velocidade reduzida enquanto os utilizadores desejam escrever rápido (aqui temos de levar em conta o tempo necessário para corrigir erros bem como a velocidade de escrita);
- “Deficiência” no toque enquanto os utilizadores normalmente interagem com teclas físicas de grande proporção para escrever, em dispositivos móveis são forçados a utilizar pequenas teclas virtuais que não combinam com o tamanho das suas pontas dos dedos;
- O ato de escrever é entendido como múltiplos cliques em botões (teclas virtuais) algo que vai contra o estilo de experiência nativa que é baseado à volta de taps e swipes (poucos toques em botões e gestos) [apesar de este problema ter sido parcialmente mitigado através do uso de alguns teclados virtuais que permitem escrever através de swipes].

Contribuem para o desenvolvimento da fraca tolerância a erros por parte dos utilizadores

Como descrito no ponto anterior, o uso de formulários dentro de um contexto móvel significa, normalmente, que os utilizadores necessitam de introduzir dados em espaços comprimidos, sem o conforto que um teclado físico ou um rato / trackpad lhes proporciona. Isto torna a correção de erros uma tarefa morosa e mais do que isso, torna todo o processo ineficiente. Eventualmente este facto leva, mais uma vez, à frustração dos utilizadores e possivelmente à sua ira (o que é definitivamente mau!).

Pedem demasiada informação em alturas inapropriadas

O uso de formulários requere que os utilizadores introduzam uma grande quantidade de informação de uma só vez. Deve esta situação ser a norma? Será realmente necessário pedir toda essa informação de uma só vez, especialmente num contexto móvel? Deixem-me dar um exemplo simples: um utilizador abre a vossa app pela primeira vez, tenta efetuar o procedimento de registo de utilizador e no formulário de registo vocês pedem um endereço de e-mail. É esta informação particularmente critica neste fase? Irá a app enviar um e-mail ao utilizador imediatamente após a finalização do processo de registo de utilizador? Se a resposta é não, então este exemplo ilustra uma situação onde o endereço de e-mail foi requisitado numa altura inapropriada (além de ter tornado o formulário de registo mais longo, desnecessariamente).

São restringidos e forçam o uso de fragmentação

Os dispositivos móveis têm ecrãs com tamanho limitado, o que significa que quando um formulário pede demasiada informação, está a introduzir a necessidade de fragmentar o mesmo por forma a tentar agilizar o impacto do seu preenchimento e submissão. As soluções mais comuns prendem-se com o uso de múltiplos “ecrãs” ou tabulação o que torna, por sua vez, a carga cognitiva da aplicação mais pesada e complexa do que deveria ser.

Encorajam o Copiar & Colar

Copiar & Colar é uma operação muito popular e usada em aplicações desktop. No entanto, tal como descrito anteriormente, torna-se uma dor de cabeça num contexto móvel. Pode até ser considerado desnecessário. Deixem-me dar um exemplo simples mas comum onde o uso de formulários encoraja ao uso do Copiar & Colar: é pedido ao utilizador para introduzir uma password para a sua nova conta de utilizador. Para atingir este propósito, o utilizador tem tipicamente de preencher dois campos (geralmente consecutivos) para a password, um campo para a definição da password e outro para confirmar a password introduzida no campo anterior. Este é um mecanismo extremamente ineficiente e em geral desnecessário, dentro de um contexto móvel (embora que este exemplo já tenha sido mitigado recorrendo ao uso da popular abordagem de two-factor authentication, o que tornou mais usual a introdução da password em texto claro, eliminando assim a necessidade da duplicação da introdução da mesma).

Continua na Parte III.

About
Latest Posts

Paulo Ribeiro

paulo.ribeiro@simdea.pt
Hardworking and passionate individual keen on learning and clearing any challenges coming his way.
Working in such a fast paced industry as Application Development, Paulo always aims to try and learn new technologies and new ways to perform his work, either through optimization or efficient process management. He is always open to embrace projects as long as they represent a brand new challenge and learning experience for him.