Nos testes, algumas tarefas foram realizadas tanto na Web quanto em aplicações. Nesses casos, os participantes sempre foram bem sucedidos na web. Um terço das tarefas correspondentes que envolviam aplicativos, terminou em fracasso. Havia duas razões pelas quais alguns dos aplicativos foram menos bem sucedidos do que os sites: 

1- Os aplicativos continham menos conteúdo do que os sites. Um exemplo é o Sears.

Ao contrário do seu app, o site da Sears permitiu que os usuários estreitassem os resultados de acordo com vários critérios. Ele também incluiu mais informações sobre os produtos e informações sobre os custos de transporte e instalação. Parece que o app foi construído para o usuário de telefonia móvel, que precisa chegar ao conteúdo de forma mais rápida e raramente olha para vários detalhes.

Infelizmente, a maioria dos usuários iPad não usa o iPhone em situações verdadeiramente móveis: você não vê muitas pessoas caminhando em lojas, com seu iPhone nas mãos, tentando descobrir se vale a pena comprar uma máquina de lavar louça no Home Depot ou se é melhor ir para a Sears. Mesmo os usuários que usam seus IPAD’s longe de casa, o utilizam em situações relativamente relaxadas, quando eles estão à espera, ou entre alguma atividade, ou para matar tempo.

2- No caso da Amazônia Windowshop, os usuários ficaram surpresos ao observar e sentir a diferença do look-and-feel dos sites Amazon. 

Muitos usuários gostaram do novo design, mas alguns ficaram impressionados com as fotos e os diferentes look-and-feel. Outro exemplo de aplicativo que gerou falhas foi o Washington Post. Para acessar o conteúdo do aplicativo, os usuários necessitavam realizar um cadastro, como não tinham interesse em efetuar essa etapa, optavam em ir para a Web, já que esta não necessita de cadastro. Um dos participantes argumentou: Por que eu iria dar-lhes o meu email se eu posso acessar o site sem me inscrever?

Se você precisa de um app iPad

1. Design para os usuários de repetição.

Esta pesquisa mostra que os aplicativos móveis funcionam melhor quando são projetados para que os usuários repitam sua utilização: os clientes que já são fãs da marca e interagem com esta regularmente.

Para decidir se você precisa de um app iPad, primeiro, oberve esses dados: quantas pessoas acessam o seu site completo em um iPad? O que eles fazem lá? Eles são capazes de chegar onde eles querem? São esses clientes as pessoas que vão para o seu site, e quantas vezes elas fazem isso?

2. Sua aplicação iPad deve ter uma arma secreta em relação ao seu website.

Se você decidir ter um app iPad, certifique-se que o aplicativo oferece um valor extra, em comparação com o website. A arma secreta do aplicativo pode ser sua excelente usabilidade, usabilidade ou apenas o suficiente para fazer uma tarefa repetida suportável. Veja, por exemplo, no app Epicurious no IPAD. O aplicativo oferece essencialmente o mesmo conteúdo que o site, mas é muito mais útil do que o site na cozinha. Você pode ler a receita sem rolagem, sem maior ampliação, ou tocar na tela - todas essas são tarefas muito chatas na cozinha, quando suas mãos estiverem sujas.

3. Não faça o usuário trabalhar mais em seu aplicativo, do que em seu site.

Raramente os usuários aceitam fazer o download e usar um aplicativo se eles têm que trabalhar mais por isso. Por exemplo, um monte de jornais oferecem acesso gratuito à Internet, mas pedem aos usuários para se registrarem, para usar o aplicativo. Os participantes da pesquisa foram muito relutantes em fazê-lo.

4. Não use o design em um aplicativo iPad como se fosse um aplicativo de iPhone.

Não cometa o erro de conceber um app iPad como você projetou um aplicativo para iPhone: não é só porque o IPAD tem uma tela maior, mas, igualmente importante, porque o contexto de uso é diferente.

Muitos usuários afirmam que o IPAD substituiu seu laptop. Isso não significa que de repente começou a codificação ou criação de apresentações PowerPoint em seus iPad, mas algumas das mais complexas informações de averiguação de tarefas estão migrando do laptop para o iPhone.

Matar tempo é um uso muito corriqueiro dos smartphones, o que é compartilhado com o IPAD. Nesta tarefa, o usuário pode ter um objetivo muito geral (por exemplo, ler notícias, navegar através de uma revista) e está feliz de ter mais ou menos o que quer que o conteúdo do dispositivo oferece. Porém, o tempo que é geralmente disponível no smartphone é muito mais curto e mais fragmentado do que a disponível no IPAD. Sobre o smartphone, os usuários podem procurar por um artigo rápido para matar os 3 minutos de espera pelo trem, uma vez no trem, eles podem tirar o iPad para o tempo que levam até em casa. Como um usuário colocou: "Eu não estou com pressa, quando eu uso este dispositivo."

Se você não precisa ou não pode pagar por um aplicativo, o que você pode fazer para tornar a sua aparência decente no IPAD?

Primeiro e mais importante, você deve testar seu site. Veja quais s ão os pontos negativos, para então consertá-los. Muitas vezes correções irão melhorar a usabilidade geral do seu site no ambiente de trabalho, também. Algumas das correções mais óbvias incluem:

• Livrar-se de conteúdo em Flash;

• Criação de alvos e metas maiores para, eles aceitem melhor o toque;
• Espaçamento em links sempre que possível;

• Detecção de localização;

• Minimizar a necessidade de digitação;

• Controles de Agrupamento ou peças de informação que estão relacionados (para evitar ter conteúdo ignorado porque é abaixo da dobra).

O Touch Screen e Affordances

Tamanho do Target

No primeiro relatório IPAD, lamentou-se o uso de targets pequenos em aplicativos. Porque o IPAD é um dispositivo touchscreen, ele tem a problemática de chegar a targets pequenos. Mesmo as pessoas sendo capazes de chegar ao target, quando estes são pequenos, há mais trabalho de utilização. 

A pesquisa mostrou que o melhor tamanho de target para widgets é 1cm x 1cm para dispositivos touch, no entanto, ainda vemos alguns aplicativos que possuem targets minúsculos, muito abaixo do limite recomendado. Alvos pequenos não são apenas difíceis de tocar, às vezes, eles também são difíceis de descobrir.

Metas Tagets

Quando os alvos são colocados muito próximos uns dos outros, os usuários podem facilmente acertar o errado. Em Pennant, os usuários podem explorar o cronograma para seleccionar um ano e encontrar mais informações de desempenho de seu time favorito para esse ano. Cada barra na linha do tempo é tappable e, claro, as barras são muito próximos uns dos outros, tornando difícil para selecionar um ano em particular.

Pennant usa essa linha do tempo de navegação em outros casos, também, por exemplo, para indicar eventos de várias níveis de importância de um específico jogo. Em uma nota lateral, alguns usuários consideraram chato ter de deslizar o dedo ao redor do círculo para encontrar informações sobre o jogo, e disseram que teriam preferido uma sinopse mais textual do jogo.

Padding

Uma solução que os designers de app têm encontrado para alvos pequenos é padding: embora a parte visível do target possa ser pequeno, há algum espaço invisível que o rodeia.

Quando vários itens estão listados em colunas, uma em cima da outra, os usuários esperam ser capazes de atingir qualquer lugar na linha para selecionar o alvo correspondente a essa linha. Sempre que um projeto não cumprir essa expectativa, é frustante para os usuários.

Gestos em aplicações de produtividade

Em vários aplicativos de produtividade, utilizou-se gestos para permitir aos usuários executar operações diferentes. Por exemplo, no Adobe Photoshop Express, os usuários tinham que usar vários gestos para manipular imagens. Os gestos funcionaram bem para todos os nossos participantes - eles eram capazes de facilmente concluir suas tarefas e satisfeito com a aplicação. Uma coisa que ajudou foi que a Adobe oferece dicas sempre que os usuários efetuaram a operação. Os gestos eram relativamente simples, e não requeriam o uso de mais de um dedo.

Navegação

Toques acidentais no botão Voltar

Um monte de apps jornal não usam botões de volta. O Telegraph é um dos poucos jornais que usa um botão para trás e tem uma barra de navegação em cada página, permitindo aos usuários alternar entre diferentes seções sem voltar para uma página de listagem de notícias.

Muitas aplicações têm um hub-and-spoke modelo de navegação que exige que os usuários de leiam um artigo e depois voltem para uma página de listagem. O artigo é muitas vezes exibidos em uma sobreposição, e que faz com que o botão voltar aparentemente desnecessárias (já que o usuário pode dispensar a sobreposição e retornar à lista de artigos). Alguns sites de e-commerce que exibem informações do produto em uma página separada também usam o botão voltar para permitir aos usuários navegar de volta para os resultados da pesquisa.

No entanto, muitos dos sites que têm um botão "Back - voltar" (Zappos incluído) interrompem o fluxo de volta à homepage. Isto expõe-los para o mesmo problema que Sears tinha no exemplo acima: se os usuários voltarem à página inicial acidentalmente, eles vão perder os resultados da pesquisa ou o produto que eles estavam inspecionando.

É por isso que a recomendação é incluir um botão de volta verdade que protege o usuário contra acidentes.

Se seu aplicativo terá seções com nenhum botão voltar, pelo menos, certifique-se que os links para essas seções têm menos probabilidade de ser acidentalmente tocado. No caso da Zappos, significa colocar o "Home" link longe do link "Voltar". Por causa disso, é realmente possível reconstruir uma sequência de navegação, mesmo se o usuário apertar o botão home em outras partes do aplicativo.

Para resumir:

• Incluir um botão voltar em seu app para permitir aos usuários desfazer qualquer toques acidentais;

• Certifique-se que o botão voltar funciona também na home page.]

Navegação horizontal

A rolagem carrosel horizontal

No relatório do ano passado, observou-se que estas duas formas de navegação eram muito bem sucedidos: o deck do modelo de cartões parecia funcionar bem na revista e aplicativos mesmo jornal, uma vez que os usuários entenderam que o modelo mental do aplicativo seguido de um jornal de papel ou revista. O carrossel foi também é fácil de usar, se a affordance de swiping horizontal era bom.

Uma grande quantidade de aplicativos usa carrosséis. Apps tem muitas novidades apresentadas em linhas de imagens, mais texto, e vários dos usuários comentaram que gostaram desse tipo de display, porque eles poderiam obter informações de ambos a imagem e o título da história.Um usuário comentou sobre o app Bing: "[O carrossel] é o meu tipo favorito de design - você desliza para ver o que você precisa. Isso mostra a maior quantidade de informação sem ser intrusivo".

Em geral, o problema de carrosséis é que eles só mostram um pequeno número de itens de uma vez. Há situações em que pode ser bom, no entanto, carrosséis não são apropriados para longas listas. Os usuários tendem a mudar de orientação quando ocorre um impasse e, se o aplicativo não oferece suporte a eles, seu fluxo vai ser interrompido, e eles vão se perguntar por que ele não está funcionando.

Navegações inconsistentes (horizontal e vertical) através de orientações

Alguns aplicativos usam uma direção de navegação diferente nas duas orientações, por exemplo, eles usam de navegação horizontal na paisagem e uso de navegação vertical no retrato, como por exemplo, o app Style Shop.

Quando as pessoas mudam as orientações de seus IPAD`s, elas esperam o mesmo tipo de interação do app. Navegações inconsistentes entre orientações também degrada a capacidade de aprendizado do app: é mais difícil para os usuários associar qualquer esquema de navegação particular com esse app.

Usuários são ligeiramente mais propensos a mudar de orientação quando se usa um aplicativo de revista, do que outros tipos de aplicação, principalmente porque esses aplicativos possuem conteúdo que tem uma orientação preferencial (por exemplo, fotos ou vídeos). Nos testes, um participante se atrapalhou um pouco com o tempo até que descobriu o que tinha que fazer quando ele mudou as orientações. Mudar de retrato para paisagem foi especialmente difícil, porque os usuários tentavam fazer a rolagem vertical em vão. A recomendação então, é se certificar de que o esquema de navegação é utilizado o mesmo na paisagem e retrato.

Experiência Inicial

Tempo de download

            Nesta pesquisa, realizamos questionamentos para estimar quanto tempo um usuário aguanta “sofrer”em um download. A resposta foi mais ou menos 20 segundos. Após esse período, eles tornan-se impacientes e começam a pensar em fazer em outra coisa. O tempo para baixar o conteúdo depende de uma variedade de fatores, muitos dos quais estão além do controle do aplicativo. O que você pode fazer para se certificar de que seus usuários não abandonará seu aplicativo?

1. Exibir uma barra de progresso (e não uma engrenagem girando).
Mesmo que você possa estimar que o seu conteúdo irá fazer o download em um milésimo de segundo, é absolutamente vital para exibir uma barra de progresso que informa aos usuários claramente o quanto o download progrediu, e, muito importante, que o aplicativo está funcionando.

2. Se, uma vez que o usuário tenha inicializado, seu aplicativo precisar de mais de 20 segundos para baixar conteúdo e tornar-se totalmente funcional, pense seriamente sobre como você está indo para entreter o usuário durante o tempo de download.
Algumas sugestões possíveis incluem:

• Mostrar uma pré-visualização do conteúdo que é baixado;

• Mostrar o conteúdo que é baixado até o momento;

• Mostrar as instruções e dicas sobre como usar o aplicativo.

Telas de abertura, ruído e vídeo

Rebatizado como telas de lançamento, o splash telas muitas vezes não contêm nenhuma informação sobre quanto tempo o aplicativo vai levar para carregar, nenhuma barra de progresso, e, além disso, não têm relação alguma com a primeira tela do aplicativo.

Muitos aplicativos se sentem compelidos a começar com gráficos elaborados. Às vezes, animações complexas que podem demorar alguns segundos estão envolvidos. Considerando que uma animação bonita pode trazer um sorriso a primeira vez que os aplicativos é iniciado, pela quinta vez, torna-se irritante. Alguns aplicativos dam um passo além e adicionam vídeos ou sons para a tela inicial.

Aconselha-se veementemente a não utilização de sons de inicialização, pois os usuários não esperam ouvir ruídos quando iniciam um app. Muitas vezes, os usuários iniciam um app em momentos onde ruídos são inapropriados, como por exemplo, em reuniões.

Então, o que se deve fazer em relação a telas de lançamento?

• Se você tiver um, siga a recomendação da Apple e torne-o o mais próximo possível de sua primeira tela funcional.

• Não use animações, sons e vídeos quando o aplicativo for lançado.

O ideal é que o aplicativo seja funcional sem instruções. Se ele necessitar de instruções, deve ser simples e de fácil memorização. Não se deve inundar o usuário com uma grande quantidade de insformação de uma só vez, bem como, deve-se ter essa informação disponível, mas nunca se deve forçar o usuário a utilizá-lo, especialmente quando o aplicativo é lançado.

Infelizmente, os usuários não têm paciência para se aprofundarem nos detalhes dessas instruções. Ninguém vai memorizar todas essas opções de fazer. É melhor se concentrar em uma ou duas características que são importantes, da tarefa iniciada.

Resumindo:

• Se você precisa usar instruções, torne-os claros e simples.

• Foque em uma única característica da cada vez. apresente apenas aquelas instruções que são necessárias para o usuário começar.

Fluxo de trabalho

Um dos usuários estava confuso, porque ele não sabia onde entravam as informações de pagamento. O problema foi amplificado pelo fato de que quando pressionado "Enviar meu pedido", a mensagem de erro falou sobre um método de pagamento.

No aplicativo era de fato esperado que o usuário preenchesse o endereço de entrega, após isso, ele seria apresentado ao seu pedido de informações de pagamento. Mas o usuário estava preocupado porque não havia nenhuma indicação clara de que ele faria isso mais tarde.

Resumindo: