Exemplos de onboarding móvel: padrões para estudar antes do próximo fluxo
Um guia prático de onboarding em aplicativos móveis, com padrões para oferecer valor logo no início, configuração progressiva, orientação contextual, permissões e uma lista objetiva de revisão de design.

Um carrossel de onboarding sofisticado ainda pode ser a resposta errada. A questão útil não é quantas telas mostrar, mas o que uma nova pessoa precisa entender ou fazer antes que o aplicativo se torne útil.
Os padrões abaixo são exercícios hipotéticos de design, não estudos de caso ou provas de ganhos de conversão. Use-os para comparar abordagens e, em seguida, teste se o seu próprio fluxo ajuda as pessoas a concluir uma primeira tarefa real.
Principais conclusões
- Comece com o primeiro resultado útil e depois decida se é necessária uma etapa de onboarding separada.
- Peça informações e permissões quando o propósito for claro e relevante para a tarefa.
- Ensine ações pouco familiares no contexto, com uma forma visível de pular ou retornar para obter ajuda.
1. Deixe o primeiro momento útil liderar
Imagine um aplicativo de planejamento de refeições que abre com um plano inicial e permite que alguém troque uma refeição, em vez de começar com slides sobre receitas e listas. A interação torna o produto concreto. Mantenha uma introdução apenas quando ela resolver uma incerteza real.
As Diretrizes de Interface Humana da Apple recomendam um onboarding rápido, opcional e focada. NN/g desaconselha a instrução que as pessoas podem aprender através do uso, embora reconheça a configuração, as experiências personalizadas e os fluxos de trabalho desconhecidos como motivos para orientá-los. Um aplicativo familiar de notas ou cronômetro pode ficar mais claro quando aberto diretamente na tarefa.
Estude exemplos na biblioteca de onboarding do ScreenKits para ideias de layout e sequenciamento. Leia-os como referências visuais: uma captura de tela pode sugerir um padrão, mas não pode estabelecer como as pessoas o entenderam ou se funcionou.
- Cite o primeiro resultado significativo em uma frase.
- Pergunte se a própria interface pode tornar a próxima ação compreensível.
- Mantenha uma declaração de boas-vindas ou de valor apenas se isso resolver uma incerteza real.
2. Use configuração progressiva em vez de um mural de questionários
Imagine um aplicativo em execução que deseja uma meta, unidades, horário do lembrete e localização. Uma versão progressiva oferece um plano inicial, pede uma meta quando alguém a ajusta e deixa unidades e lembretes nas configurações. Se uma resposta específica for essencial, explique por que ela é necessária.
Esse padrão é útil quando a personalização depende de um pequeno número de escolhas significativas. É mais fraco quando as perguntas parecem um questionário sem retorno visível. Mostrar progresso apenas quando esclarecer o esforço restante; não adicione várias telas apenas para fazer um formulário curto parecer suave. Forneça valores padrão sensatos e deixe que as pessoas os alterem mais tarde.
A criação da conta pertence à mesma conversa. A Apple recomenda solicitar uma conta apenas quando a funcionalidade principal exigir uma e adiar o login quando possível para que as pessoas possam primeiro entender o aplicativo. Para um fluxo que exige registro, deixe claro o benefício e as informações necessárias. O guia de design de login e inscrição móvel relacionado pode ajudá-lo a revisar essa parte separadamente.
- Para cada pergunta, anote qual decisão do produto depende de sua resposta.
- Mova as preferências opcionais para o momento em que se tornarem úteis ou para as configurações.
- Explique as etapas necessárias da conta em termos da tarefa da pessoa.
3. Ensine uma ação nova no contexto
Considere um aplicativo de orçamento com uma forma desconhecida de dividir uma transação. Um carrossel genérico que aponta para cada aba faz com que a pessoa se lembre das instruções antes de ter um motivo para usá-las. Um padrão contextual espera até que a primeira transação esteja visível e, em seguida, oferece uma breve dica ao lado do controle de divisão. Uma etapa prática interativa poderia permitir que alguém experimentasse a ação em dados de amostra antes de editar um registro real.
A escolha do design depende do tempo e dos riscos. Ensine a interação única no momento em que ela se tornar relevante, mantenha a instrução perto do controle e deixe clara a próxima ação. Se uma pessoa rejeitar a dica, preserve um caminho de ajuda que possa encontrar mais tarde. Evite explicar as convenções de navegação padrão que a interface deve comunicar por si só.
Para fluxos complexos, uma pequena tarefa guiada pode ensinar mais do que um tour: criar um quadro de amostra, salvar um item ou visualizar um fluxo de trabalho. Mantenha o exercício reversível e diga se ele altera os dados reais. A Apple recomenda instruções interativas quando for necessária uma breve preparação prática.
- Identifique a ação que é nova ou fácil de ser mal interpretada.
- Coloque a dica ao lado dessa ação e ofereça um caminho para experimentar agora, quando for seguro.
- Torne simples pular, descartar e encontrar a explicação novamente.
4. Peça permissões quando o motivo estiver visível
Imagine um diário fotográfico que pode anexar um local. Solicitar acesso à localização na tela de boas-vindas torna a solicitação abstrata. Esperar até que alguém escolha Adicionar localização cria uma explicação clara: a localização pode rotular esta entrada e o recurso funciona sem ela. Trata-se de um momento de permissão vinculado a um benefício específico, com uma alternativa clara caso o acesso seja recusado.
O mesmo raciocínio se aplica a notificações, câmeras, contatos e dados de saúde. Uma explicação pré-permissão deve ser precisa, concisa e específica sobre o recurso. Não insinue que o acesso é obrigatório se o aplicativo principal ainda funcionar sem ele. A Apple aconselha fazer solicitações de onboarding somente quando o acesso privado for um pré-requisito; caso contrário, pergunte quando a pessoa usa pela primeira vez a função que precisa dela.
- Vincule cada solicitação a uma ação que a pessoa acabou de escolher ou a uma tarefa que está tentando concluir.
- Indique o que a permissão permite e o que permanece disponível sem ela.
- Mantenha o prompt do sistema diferente de sua própria explicação do benefício.
Uma lista de verificação de revisão prática
Antes de aprimorar as transições, revise cada etapa em um telefone pequeno. Dê a alguém que não conhece o aplicativo uma tarefa inicial realista e observe onde ela hesita. Compare uma versão mais leve quando o produto puder suportá-la com segurança. Trate as descobertas como evidências de usabilidade e não como resultados de negócios garantidos.
- Alguém pode realizar uma primeira tarefa significativa sem memorizar um tour?
- Cada pergunta ou etapa de configuração tem um motivo claro e imediato?
- As pessoas podem pular as instruções opcionais e encontrá-las novamente mais tarde?
- As permissões são solicitadas quando a pessoa usa o recurso que precisa delas, com uma explicação honesta?
- Os padrões permitem que as pessoas prossigam sem configurações desnecessárias?
- O fluxo funciona com textos mais longos, tecnologias assistivas e sessões interrompidas?
Perguntas comuns
Quantas telas um fluxo de onboarding móvel deve ter?
Não existe um número fixo útil. Mantenha apenas as etapas necessárias para tornar a primeira tarefa compreensível, concluir a configuração necessária ou introduzir uma interação genuinamente desconhecida. Remova telas que repetem informações ou podem esperar até mais tarde.
O onboarding do aplicativo deve ser ignorável?
Torne as instruções e o conteúdo promocional ignoráveis quando a experiência principal puder prosseguir sem eles. Se uma etapa for realmente necessária, explique o motivo e deixe clara a ação solicitada.
Quando um aplicativo deve solicitar notificação ou acesso à localização?
Geralmente quando alguém acessa pela primeira vez um recurso que usa esse acesso. Explique o benefício do recurso e o que ainda funciona se ele for recusado; solicite acesso durante o onboarding inicial somente quando for necessário começar a usar o aplicativo.


