Diretrizes de design UX offline

Um guia para projetar experiências da web para redes lentas e offline.

Nov 10, 2016 — Atualizado May 28, 2021

Available in: English, and Español

Appears in: Aplicações Web Progressivas | Confiabilidade da rede

Mustafa Kurtuldu

Twitter GitHub Homepage

Thomas Steiner

Twitter GitHub Glitch Homepage

Este artigo contém diretrizes de design sobre como criar uma ótima experiência em redes lentas e off-line.

A qualidade de uma conexão de rede é influenciada por uma série de fatores, como:

• Má cobertura de um provedor.
• Condições climáticas extremas.
• Quedas de energia.
• Entrar em "zonas mortas" permanentes, como edifícios com paredes que bloqueiam as conexões de rede.
• Entrar em "zonas mortas" temporárias, como quando se viaja em um trem e atravessa um túnel.
• Conexões de Internet com tempo limitado, como aquelas em aeroportos ou hotéis.
• Práticas culturais que exigem acesso limitado ou nenhum acesso à Internet em horários ou dias específicos.

Seu objetivo é fornecer uma boa experiência que reduza o impacto das mudanças na conectividade.

Decida o que mostrar aos seus usuários quando eles tiverem uma conexão de rede ruim #

A primeira pergunta que deve ser feita é como é o sucesso e a falha de uma conexão de rede? Uma conexão bem-sucedida é a experiência online normal do seu aplicativo. A falha de uma conexão, no entanto, pode ser tanto o estado offline do seu aplicativo quanto a forma como o aplicativo se comporta quando há uma rede lenta.

Ao pensar sobre o sucesso ou falha de uma conexão de rede, você precisa se perguntar estas importantes questões de UX:

• Quanto tempo você espera para determinar o sucesso ou a falha de uma conexão?
• O que você pode fazer enquanto o sucesso ou o fracasso estão sendo determinados?
• O que você deve fazer em caso de falha?
• Como você informa o usuário sobre o acima?

Informar aos usuários sobre seu estado atual e mudança de estado #

Informe o usuário sobre as ações que ele ainda pode realizar quando houver uma falha de rede e o estado atual do aplicativo. Por exemplo, uma notificação poderia dizer:

Você parece ter uma conexão de rede ruim. Não se preocupe! As mensagens serão enviadas quando a rede for restaurada.

Informe os usuários quando a conexão de rede melhorar ou for restaurada #

A maneira como você informa ao usuário que a conexão de rede dele melhorou depende do seu aplicativo. Aplicativos como um aplicativo de mercado de ações que priorizam as informações atuais devem se atualizar automaticamente e notificar o usuário o mais rápido possível.

É recomendável que você informe ao usuário que seu aplicativo da web foi atualizado "em segundo plano" usando uma dica visual como, por exemplo, um elemento de brinde de material design. Isso envolve a detecção da presença de um service worker e uma atualização de seu conteúdo gerenciado. Você pode ver um exemplo de código dessa função em operação aqui.

Um exemplo disso seria o Chrome Platform Status, que posta uma nota para o usuário quando o aplicativo é atualizado.

Você também pode mostrar a última vez que o aplicativo foi atualizado em todos os momentos em um espaço de destaque. Isso seria útil para um aplicativo de conversor de moeda, por exemplo.

Aplicativos, como de notícias, podem mostrar uma notificação simples toque para atualizar informando o usuário sobre o novo conteúdo. A atualização automática faria com que os usuários perdessem seus lugares.

Atualize a IU para refletir o estado contextual atual #

Cada bit de IU pode ter seu próprio contexto e funcionalidade, que mudarão dependendo se for necessária uma conexão bem-sucedida. Um exemplo seria um site de comércio eletrônico que pode ser navegado offline. O botão Comprar e o preço seriam desativados até que a conexão fosse restabelecida.

Outras formas de estados contextuais podem incluir dados. Por exemplo, o aplicativo financeiro Robinhood permite que os usuários comprem ações e usa cores e gráficos para notificar o usuário quando o mercado está aberto. Toda a interface fica branca e depois acinzentada quando o mercado fecha. Quando o valor do estoque aumenta ou diminui, cada widget de estoque individual fica verde ou vermelho, dependendo de seu estado.

Eduque o usuário para que ele entenda o que é o modelo off-line #

Off-line é um novo modelo mental para todos. Você precisa instruir seus usuários sobre quais mudanças ocorrerão quando eles não tiverem uma conexão. Informe-os sobre onde os dados grandes são salvos e forneça configurações para alterar o comportamento padrão. Certifique-se de usar vários componentes de design de IU, como linguagem informativa, ícones, notificações, cores e imagens para transmitir essas ideias coletivamente, em vez de depender de uma única escolha de design, como um ícone próprio, para contar a história toda.

Fornece uma experiência offline por padrão #

Se seu aplicativo não requer muitos dados, armazene esses dados em cache por padrão. Os usuários podem ficar cada vez mais frustrados se só puderem acessar seus dados com uma conexão de rede. Tente tornar a experiência o mais estável possível. Uma conexão instável fará com que seu aplicativo pareça não confiável, enquanto um aplicativo que diminui o impacto de uma falha de rede parecerá mágico para o usuário.

Os sites de notícias podem se beneficiar com o download e salvamento automáticos das notícias mais recentes, para que o usuário possa ler as notícias de hoje sem uma conexão, talvez baixando o texto sem as imagens do artigo. Além disso, adapte-se ao comportamento do usuário. Por exemplo, se a seção de esportes é o que eles costumam ver, faça disso o download prioritário.

Informe o usuário quando o aplicativo estiver pronto para consumo offline #

Quando um aplicativo da web é carregado pela primeira vez, você precisa indicar ao usuário se ele está pronto para uso offline. Faça isso com um widget que fornece um breve feedback sobre uma operação por meio de uma mensagem na parte inferior da tela, como, por exemplo, quando uma seção foi sincronizada ou um arquivo de dados foi baixado.

Pense novamente na linguagem que está usando para ter certeza de que é adequada para o seu público. Certifique-se de que a mensagem seja fornecida da mesma forma em todas as instâncias em que é usada. O termo offline geralmente é mal interpretado por um público não técnico, então use uma linguagem baseada em ação com a qual seu público possa se identificar.

Torne a função 'salvar para off-line' uma parte óbvia da interface para aplicativos com muitos dados #

Se um aplicativo usar grandes quantidades de dados, certifique-se de que haja uma chave ou pino para adicionar um item para uso off-line em vez de download automático, a menos que um usuário tenha solicitado especificamente esse comportamento por meio de um menu de configurações. Certifique-se de que o pino ou a IU de download não sejam obscurecidos por outros elementos da IU e que o recurso seja óbvio para o usuário.

Um exemplo seria um reprodutor de música que requer grandes arquivos de dados. O usuário está ciente do custo de dados associado, mas também pode querer usar o player offline. Baixar música para uso posterior requer que o usuário planeje com antecedência, portanto, pode ser necessária educação sobre isso durante a integração.

Esclareça o que está disponível offline #

Seja claro quanto à opção que você está fornecendo. Pode ser necessário mostrar uma guia ou configuração que mostra uma "biblioteca offline" ou índice de conteúdo, para que o usuário possa ver facilmente o que armazenou em seu telefone e o que precisa ser salvo. Certifique-se de que as configurações sejam concisas e deixe claro onde os dados serão armazenados e quem tem acesso a eles.

Mostra o custo real de uma ação #

Muitos usuários equiparam a capacidade offline com 'download'. Os usuários em países onde as conexões de rede falham regularmente ou não estão disponíveis geralmente compartilham conteúdo com outros usuários ou salvam conteúdo para uso offline quando têm conectividade.

Os usuários em planos de dados podem evitar o download de arquivos grandes por medo do custo, portanto, você também pode desejar exibir um custo associado para que os usuários possam fazer uma comparação ativa para um arquivo ou tarefa específica. Por exemplo, se o aplicativo de música acima puder detectar se o usuário está em um plano de dados e mostrar o tamanho do arquivo para que os usuários possam ver o custo de um arquivo.

Ajude a prevenir experiências hackeadas #

Freqüentemente, os usuários invadem uma experiência sem perceber que estão fazendo isso. Por exemplo, antes dos aplicativos da web de compartilhamento de arquivos baseados em nuvem, era comum os usuários salvarem arquivos grandes e anexá-los a e-mails para que pudessem continuar editando em um dispositivo diferente. É importante não ser puxado para a experiência de hackeado, mas sim olhar para o que eles estão tentando alcançar. Em outras palavras, em vez de pensar em como você pode tornar a anexação de um arquivo grande mais amigável, resolva o problema de compartilhamento de arquivos grandes em vários dispositivos.

Torne as experiências transferíveis de um dispositivo para outro #

Ao construir para redes instáveis, tente sincronizar assim que a conexão melhorar para que a experiência seja transferível. Por exemplo, imagine um aplicativo de viagens perdendo uma conexão de rede no meio de uma reserva. Quando a conexão é restabelecida, o aplicativo sincroniza com a conta do usuário, permitindo que ele continue sua reserva em seu dispositivo desktop. Não poder transferir experiências pode ser incrivelmente chocante para os usuários.

Informa o usuário sobre o estado atual de seus dados. Por exemplo, você pode mostrar se o aplicativo foi sincronizado. Eduque-os sempre que possível, mas tente não sobrecarregá-los com mensagens.

Crie experiências de design inclusivas #

Ao projetar, procure ser inclusivo, fornecendo dispositivos de design significativos, linguagem simples, iconografia padrão e imagens significativas que guiarão o usuário para concluir a ação ou tarefa em vez de impedir seu progresso.

Use uma linguagem simples e concisa #

Uma boa UX não se trata apenas de uma interface bem projetada. Inclui o caminho que o usuário segue, bem como as palavras usadas no aplicativo. Evite jargões técnicos ao explicar o estado do aplicativo ou de componentes individuais da IU. Considere que a frase "aplicativo offline" pode não transmitir ao usuário o estado atual do aplicativo.

Não faça

Faça