É isso aí galera, estou de volta.
Depois de uma certa experiência com usabilidade mobile, tanto Android quanto iOS (em breve vou abordar também sobre Windows Phone), resolvi criar alguns posts para tratar do tema.
Nessa introdução vou comentar sobre o que é a Usabilidade Mobile e abordar um dos primeiros problemas enfretados pelos arquitetos de informação na área.
Para entender o assunto tratado é necessário que você seja arquiteto, desenvolver ou designer voltado ao mundo mobile. 😉
Vou começar tratando desse tema, afinal, sabemos que a maioria dos arquitetos iniciaram suas atividades com websites, aplicações desktop, etc, no geral, estão acostumados a pensar no contexto do Desktop. E o que seria isso?
Quando pensamos em uma aplicação desktop pensamos em todo o espaço que o mesmo nos oferece, temos a tal área quente que sabemos que fica na esquerda superior, temos o percorrer dos olhos que corta a página da direita superior a esquerda inferior e todo aquele processo já conhecido pelos profissionais da área de AI. Logo a Usabilidade é dentro desse contexto, e o que acontece é que muitos arquitetos acabam tentando utilizar esse processo na área Mobile, o que obviamente não funciona.
Resta dizer, para aqueles arquitetos que possuem uma experiência com aplicações web RIA, ou aplicações que rodem no Desktop, diferente dos arquitetos puramente Web, garantem uma vantagem quando se trata da navegação fluída, que é também experimentada no mobile.
A Usabilidade Mobile é totalmente diferente da usabilidade web no desktop, ou da usabilidade de apps para desktop. Eu chamo de Usabilidade de Imersão.
A Usabilidade de Imersão tem confundido diversos arquitetos nos últimos tempos, e não é incomum pegarmos aplicações cuja navegação está comprometida, exatamente porque foi pensada de maneira errada, foi pensada através da visão desktop e não da visão mobile.
Quando falamos em imersão estamos falando em como o usuário enxerga as apps no mobile e como ele navega no mesmo. Ele está imerso naquele mundo o contexto é bem específico, podemos separar da seguinte forma, topo com navegação, conteúdo, e base as vezes com navegação.
Mas afinal, porque estou chamando de imersão? Porque é raro você clicar em alguma ação de algum botão e não sair da tela em que está para outra, 90% das vezes a sua tela é trocada, você não tem apenas um detalhe que é carregado, ou apenas uma pequena informação que é alterada, geralmente ao se clicar em ações o usuário se depara com a próxima tela que vem até ele, pelas diversas formas de transições que podem ser utilizadas (vou abordar o assunto transições na usabilidade mobile em um outro post). Os outros 10% ficam com alerts que aparecem, lists que são utilizadas, etc.
Portanto, vamos agora falar de como funciona o Fluxo Mobile, ele na maioria das vezes percorre da esquerda para a direita, conforme o usuário vai clicando para navegar uma próxima página aparece vindo da direita. Essa é a navegação mais tradicional e por onde começam a atuar os arquitetos, e logo, onde acontecem os primeiros problemas de fluxo que podem ser encontrados.
Nesse post vou tratar do maior problema que percebi ocorrer na maioria das apps desenvolvidas pelos novatos. Para isso vou fazer uso da imagem abaixo que nos ajudará a entender esse fluxo e seu problema com o usuário.
A idéia é bem simples, vamos supor que temos uma navegação tradicional, o usuário tem que fazer algumas ações e finalizar a mesma na tela 3, onde temos o botão [finalizar atividade]. Estou apenas supondo 3 telas, mas geralmente os fluxos nas apps acabam abordando 5 ou mais telas.
A navegação ocorre conforme a seta verde, observe, você clica em avançar (indiferente do que faz a sua app, é apenas um exemplo prático), passa para a segunda tela, e então a terceira, que poderá finalizar ou avançar, indifere. Supondo que o usuário vai finalizar ação, o que acontece então? Geralmente os arquitetos respondem a esse problema voltando a tela inicial, mas, e quando o usuário tem como disponibilidade voltar para a tela 2, ou a tela 1? O que ocorre é que os arquitetos acabam preferindo jogá-lo para a tela 2, já que, assume a premissa de que se o usuário quiser, poderá ir para a tela 1 clicando em voltar, uma etapa a mais não é problema, só que, se temos 5 telas a coisa começa a complicar. Esse fluxo de retorno da seta vermelha pode ser quebrado da seguinte forma, a tela 4 é apenas um alert que inseri para demonstrar a solução.
Solução.
O Alert sobe, dando a opção ao usuário para voltar para a tela 1, ou a tela 2. Mas, não acaba aí, o que não pode ocorrer é o arquiteto utilizar apenas os botões e inserí-los em uma quarta tela que também viria da direita. Não mesmo, isso porque ao fazer o retorno você sairia da tela 4 diretamente para 1 utilizando a transição que viria da esquerda para a direita. O que acontece é que você confunde o usuário, ele passa a não entender mais o fluxo da sua aplicação, pois ele assume a idéia de que a tela anterior é a 3 e não a 1, só porque apertou o botão para voltar a aquela tela, esse conflito acontece no cérebro do usuário, já que, ele sabe que clicou no botão para voltar a tela 1, mas as transições indicam um fluxo reverso.. e aí mora o perigo. O Fluxo é a forma como trabalhamos a usabilidade no ambiente Mobile, se utilizado de maneira errada, o problema passa a aparecer, e o usuário passa a se confundir.
Nessa solução eu apenas inseri um Alert, ele virá de uma transição da base para o topo, assim mostrando que é uma ação diferenciado do fluxo tradicional, o usuário irá clicar no botão para voltar a tela 1 (tela inicial), e a mesma será carregada atrás desse alert, ao mesmo tempo o Alert desce, do topo para a base, sumindo, e a tela inicial se mostrará. Esse fluxo trabalha a mente do usuário de forma que ele passa a compreender o fluxo da sua aplicação.
Transições não são meros enfeitos que você usa para enfeitar a sua aplicação, elas respeitam e demonstram como é o fluxo da sua informação, a relevância, e claro, a sua hierarquia.
Espero com esse post despertar o interesse pelo estudo sério do segmento, sabemos que, iOS, Android e demais sistemas operacionais Mobile possuem suas próprias Guidelines, que inclusive já abordei nesse blog, as Guidelines existem exatamente para engessar parte da arquitetura a fim de que não sejam criadas aberrações, mas… não impede a inovação. Exemplo disso é a nova interface feita pela app do Facebook, bem como o menu principal da aplicação Path.. ou ainda, a fantástica usabilidade das app Flipboard, tanto para iPhone quanto para iPad.
_________________________________________
Eduardo Horvath é UX Specialist e Designer na redspark.
Formado pela Faculdade Impacta de Tecnologia no curso Design de Mídia Digital ele atua na área de Design há mais de 15 anos.
@eduardohorvath