Zona do polegar
Ação repetida na metade de baixo, ao alcance de uma mão. Topo para informação, não para botão.
Ecossistema YveTech · Mobile · Por dentro
Navegação principal
Estrutura de abas pensada para o uso com uma mão só. Por trás dessa frase existe um conjunto de decisões concretas: o que merece uma aba, o que é atalho, onde o dedo alcança sem esforço e o que muda entre o iPhone e o Android.
O polegar tem alcance, e ele é curto
Celular grande, mão ocupada, pessoa em pé no ônibus ou no balcão do cliente. É essa a situação real de uso.
Segure um celular moderno com uma mão só e observe até onde o polegar chega sem que a mão se reposicione: uma faixa em arco, na metade de baixo da tela. É ali que ficam as ações que se repetem — as abas, o botão de confirmar, o de adicionar. O topo da tela é ótimo para título e informação, e péssimo para o que a pessoa vai tocar quarenta vezes por dia.
A segunda decisão é quantas abas existem. Três a cinco funcionam; seis já viram um menu que ninguém lê. E o critério para ganhar uma aba não é a importância que a área tem no organograma da empresa, é a frequência de uso: o que é aberto todo dia merece aba, o que é aberto uma vez por mês vive dentro de outra tela sem prejuízo nenhum.
A terceira é respeitar o sistema. iPhone e Android têm convenções diferentes de voltar, de rolar, de posicionar ação — e o usuário aprendeu as do aparelho dele, não as do seu app. Um aplicativo que impõe o comportamento do iOS ao Android parece estrangeiro e gera erro de uso. Uma base de código não significa uma interface idêntica: o que é compartilhado é a lógica; o comportamento de navegação segue a casa.
Todo item de menu que ninguém abre é um custo permanente: ocupa espaço, dispersa a atenção e precisa continuar funcionando a cada atualização.
As decisões que compõem a navegação
Seis critérios aplicados em toda tela que desenhamos.
Alvo de toque
No mínimo 44 por 44 pontos no iOS e 48 por 48 dp no Android — erro de toque é frustração silenciosa.
Abas por frequência
De três a cinco destinos, escolhidos pelo que se usa todo dia, não pelo organograma.
Convenção de cada sistema
Voltar, rolar, ordenar e posicionar ação seguindo o que o usuário já aprendeu no aparelho dele.
Acessibilidade
Leitor de tela, contraste suficiente e respeito ao tamanho de fonte escolhido no sistema.
Estados visíveis
Carregando, vazio, erro e sem conexão desenhados — o app nunca deixa a pessoa olhando para o nada.
A navegação por dentro
O mapa, o alcance real do polegar e o que acontece quando a tela não tem o que mostrar.
Como chegamos a essa estrutura
A navegação é decidida na etapa de protótipo e verificada com uso real depois da publicação.
Inventário de tarefas
Listamos tudo o que o app precisa permitir e com que frequência cada coisa acontece.
Corte das abas
As tarefas diárias viram abas; o resto entra dentro delas ou no perfil. Nada de aba "mais".
Teste de alcance
Verificamos no aparelho, com uma mão, em pé — inclusive nos modelos de tela grande.
Verificação com dados
Depois de publicado, o uso mostra se a estrutura acertou. Aba morta é sinal de corte errado.
Sinais de navegação mal resolvida
O que costumamos encontrar em aplicativos que chegam para reforma.
- Menu com tudo dentro — a lista de opções cresceu até ninguém achar mais nada.
- Ação principal no topo — o botão mais usado exige reposicionar a mão a cada uso.
- Voltar imprevisível — às vezes volta uma tela, às vezes sai do fluxo inteiro.
- Aba que ninguém abre — ocupa espaço permanente e responde por 1% do uso.
O que verificamos antes de publicar
Uma lista curta que evita a maior parte das reclamações de usabilidade.
- Uso com uma mão — as ações frequentes ao alcance do polegar, em tela grande.
- Tamanho dos alvos — nenhum botão abaixo do mínimo recomendado por cada sistema.
- Fonte aumentada — o layout continua legível com o texto ampliado do sistema.
- Leitor de tela — a navegação inteira percorrida sem enxergar a tela.
O que muda entre iPhone e Android
Diferenças que respeitamos mesmo quando a base de código é uma só.
| Elemento | iOS | Android |
|---|---|---|
| Voltar | gesto da borda esquerda e botão no topo | gesto do sistema ou botão de navegação |
| Destinos principais | barra de abas na base | barra de navegação na base ou gaveta lateral |
| Ação principal da tela | botão no topo à direita ou barra inferior | botão flutuante no canto inferior direito |
| Alvo mínimo de toque | 44 × 44 pontos | 48 × 48 dp |
| Confirmação e alertas | diálogo padrão do sistema | diálogo do Material Design |
| Tipografia e ícones | família e conjunto do sistema Apple | família e conjunto do Material Design |
Compromissos desta etapa
O que combinamos antes de começar — e cobramos de nós mesmos durante o projeto.
3–5destinos na navegação principal
44 · 48alvo mínimo de toque em cada sistema
1 mãocritério de alcance das ações frequentes
Leitor de telanavegação verificada sem enxergar a tela
Perguntas frequentes sobre navegação principal
As dúvidas que mais aparecem nesta etapa. Sobre prazo, forma de cobrança e contrato, veja as perguntas frequentes da YveTech.
Meu app precisa ser igual no iPhone e no Android?
A estrutura e as funções, sim; o comportamento de navegação, não. Manter o gesto de voltar, a posição da ação principal e os diálogos de cada sistema faz o app parecer nativo dos dois lados. Impor um padrão único costuma agradar a quem aprovou o projeto e atrapalhar quem usa.
Quantas abas o aplicativo pode ter?
De três a cinco. Com duas, provavelmente não era caso de abas; com seis ou mais, a barra fica apertada e as pessoas param de ler os rótulos. Quando a lista não cabe, o problema costuma ser escopo, não navegação — e é melhor resolver ali.
Menu lateral é ruim?
Não é ruim, é escondido: o que está lá dentro recebe muito menos uso do que o que está visível na base. Funciona bem para configurações, perfil e áreas ocasionais. Colocar a tarefa principal dentro dele é o erro que vemos com mais frequência.
Acessibilidade atrasa o projeto?
Quando entra desde o protótipo, quase não pesa: é escolher contraste adequado, dar rótulo aos ícones e testar com o leitor de tela. Adaptar depois é que custa caro — e nas duas lojas a acessibilidade já aparece em critério de avaliação.
Sua equipe reclama que não acha as coisas no app?
Revisamos a navegação com base no uso real e propomos uma estrutura nova — sem reconstruir o aplicativo inteiro.
Continue explorando
As quatro etapas do método e os três recortes da operação — cada uma com o seu próprio detalhamento.
Aplicativos MobileVoltar à visão geral da área
Jornada e protótipoAs telas navegáveis validadas com gente de verdade antes do código
DesenvolvimentoNativo ou multiplataforma, decidido pelo seu caso e não por preferência
Publicação assistidaApp Store e Google Play conduzidas por nós, inclusive as recusas
Evolução por dadosO que o uso real revela — e as atualizações que nascem disso
O app em movimentoO que sustenta a fluidez: 60 quadros por segundo e resposta ao toque
Ambiente de Aplicativos MobileA malha que sustenta o app: serviços, sincronização, push e distribuição