Cenários de uso
Quem abre o app, onde, com quanto tempo, com uma ou duas mãos, com que qualidade de sinal. Cada cenário vira uma restrição de projeto.
Método YveTech de Mobile · Etapa 01
Jornada e protótipo
Antes de existir código, existe um aplicativo que você abre no seu próprio celular e usa como se fosse o de verdade. É nele que a discussão acontece — e é muito mais barato mudar uma tela ali do que depois de ela estar construída.
App não se aprova em reunião, se aprova na mão
Layout impresso em slide engana. O mesmo desenho, aberto no celular e tocado com o polegar, revela em minutos o que a apresentação escondeu.
A pergunta que abre um projeto de aplicativo não é "quais telas vamos ter?". É em que momento do dia essa pessoa vai abrir o app, e com quanto tempo e quanta atenção. O vendedor que registra pedido no balcão do cliente, com a outra mão segurando a caixa, precisa de uma tela diferente da do gerente que confere o resultado no fim do expediente. Descrever essas duas cenas com precisão é metade do projeto.
A partir daí desenhamos o fluxo principal — aquele que responde por 80% dos toques — e só depois os caminhos secundários. O protótipo sai navegável: instalável no aparelho ou aberto pelo navegador do celular, com transições, estados de carregamento e mensagens de erro. Não é imagem, é comportamento; e por isso ele já responde perguntas como "quantos toques até salvar um pedido?" e "o que aparece quando a internet cai no meio?".
Levamos esse protótipo para quem vai usar, não só para quem contratou. São de três a seis pessoas do dia a dia, uma de cada vez, com uma tarefa concreta na mão e sem ninguém explicando o caminho. O que elas travam, hesitam ou fazem em ordem inesperada vira mudança no desenho — enquanto mudar ainda custa uma tarde.
Toda hora gasta no protótipo economiza de cinco a dez horas de código. E não é só custo: telas refeitas depois de prontas costumam sair remendadas, e o remendo o usuário percebe.
O que a etapa produz
Seis entregas que transformam a ideia do aplicativo em algo que já dá para usar e criticar.
Fluxo principal
O caminho que responde pela maior parte do uso, contado em toques. É ele que precisa ser curto — o resto pode ter dois passos a mais.
Protótipo navegável
As telas ligadas entre si, abertas no aparelho de verdade, com transições e estados. Você usa antes de aprovar.
Teste com usuários
De três a seis pessoas do dia a dia executando tarefas sem ajuda. Observamos onde travam, não perguntamos se gostaram.
Regras e mensagens
O texto de cada erro, cada confirmação e cada estado vazio, escrito nesta etapa. Mensagem improvisada no fim do projeto é o que faz o app parecer amador.
Escopo da primeira versão
O que entra na versão que vai para a loja e o que fica para depois — com o motivo de cada corte registrado.
Como o protótipo se apresenta
Do mapa do fluxo às telas ligadas e ao registro do que os usuários fizeram com elas.
Como a etapa acontece
De duas a quatro semanas, com você olhando o desenho desde a primeira delas.
Imersão no uso real
Conversamos com quem vai usar e, quando dá, acompanhamos o trabalho de perto. Muito requisito só aparece vendo a pessoa em campo.
Arquitetura de telas
Definimos o que vive em cada aba, o que é atalho e o que fica em segundo nível. Menu inchado é sintoma de decisão adiada.
Protótipo e conteúdo
Montamos as telas navegáveis com texto real — nada de "lorem ipsum", porque o texto de verdade muda o tamanho e a hierarquia.
Teste e ajuste
Rodada de testes, correções no desenho e nova rodada nos pontos alterados. O que sai daqui é o que entra em desenvolvimento.
O que descobrimos nesta etapa
As surpresas que aparecem sempre — e que custam caro quando aparecem depois.
- O fluxo tinha passos demais — o que parecia simples no papel virava sete toques na mão.
- A tela certa não era a primeira — a informação mais consultada estava a dois níveis de distância.
- Metade do menu não era usada — e podia sair da primeira versão sem prejuízo nenhum.
- Faltava o caminho do erro — ninguém tinha pensado no que aparece quando o sinal cai no meio.
O que você recebe no fim
Material concreto — seu, independentemente de quem construir o aplicativo depois.
- Protótipo navegável — aberto no seu celular, para mostrar a sócio, banco ou investidor.
- Mapa de telas e fluxos — a arquitetura do app inteiro em uma página.
- Relatório dos testes — o que os usuários fizeram, onde travaram e o que mudou por causa disso.
- Escopo da primeira versão — a lista fechada do que vai para a loja, com prazo e estimativa.
O que o protótipo responde antes do código
Perguntas que, sem esta etapa, só recebem resposta quando o aplicativo já está construído.
| Pergunta | Como o protótipo responde | O que muda se a resposta vier tarde |
|---|---|---|
| Quantos toques até a tarefa principal? | contamos no aparelho, com o usuário fazendo | refazer navegação em app pronto mexe em quase todas as telas |
| O app funciona com uma mão só? | testamos com o polegar, em pé, sem apoio | botão fora do alcance vira reclamação na avaliação da loja |
| O texto cabe na tela pequena? | usamos conteúdo real, no menor aparelho da lista | quebra de layout descoberta em teste final atrasa a publicação |
| A pessoa entende sem treinamento? | ninguém explica nada durante o teste | app que precisa de treino tem adoção baixa e uso irregular |
| O que aparece sem internet? | os estados offline estão no protótipo | improviso de última hora costuma virar tela branca |
| O que fica de fora da versão 1? | a lista sai desta etapa, com motivo | escopo aberto é a causa mais comum de app que não chega à loja |
Compromissos desta etapa
O que combinamos antes de começar — e cobramos de nós mesmos durante o projeto.
2–4 sem.duração típica da etapa
3–6 pessoasusuários reais testando antes do código
Navegávelprotótipo aberto no seu próprio aparelho
Escopo fechadoantes de a construção começar
Perguntas frequentes sobre jornada e protótipo
As dúvidas que mais aparecem nesta etapa. Sobre prazo, forma de cobrança e contrato, veja as perguntas frequentes da YveTech.
Dá para pular o protótipo e ir direto para o desenvolvimento?
Dá, e às vezes faz sentido — em app pequeno, com fluxo único e sem usuário externo. Fora disso, pular costuma sair mais caro: mudar uma navegação depois de construída mexe em quase todas as telas, e o retrabalho supera com folga o custo da etapa.
Quem participa dos testes?
Gente que vai usar o aplicativo de verdade: o vendedor, o técnico de campo, o cliente final. Diretor e gerente participam da definição, mas não substituem o teste — quem conhece o projeto por dentro não consegue mais se perder nele, e é justamente o se perder que precisamos observar.
O protótipo já é o aplicativo?
Não. Ele simula o comportamento, mas não guarda dado, não conversa com o seu sistema e não roda offline. Serve para decidir desenho e fluxo — e é por isso que fica pronto em semanas, e não em meses.
E se eu já tiver o layout pronto?
Aproveitamos. Revisamos o que existe contra as diretrizes de cada sistema e contra os cenários de uso, montamos o navegável e testamos. Layout pronto encurta a etapa; não elimina a validação, que é a parte que evita retrabalho.
Quer ver o seu aplicativo antes de construí-lo?
Conte quem vai usar e em que situação. Devolvemos o recorte da primeira versão, com prazo e estimativa, em até 1 dia útil.
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
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
Navegação principalA estrutura de abas pensada para o uso com uma mão só
Ambiente de Aplicativos MobileA malha que sustenta o app: serviços, sincronização, push e distribuição