1. Comece pelo problema, não pela lista de ecrãs
Um briefing útil começa por explicar o que precisa de acontecer para o utilizador. “Quero uma aplicação com cinco separadores” descreve uma interface; “quero que uma pessoa encontre rapidamente informação atualizada sobre um local” descreve o problema. Esta diferença ajuda a decidir se os cinco separadores são realmente necessários ou se existe uma estrutura mais simples.
Defina também quem vai utilizar a aplicação e em que contexto. Uma aplicação consultada durante poucos segundos tem prioridades diferentes de uma ferramenta usada durante horas. Tamanho do texto, quantidade de informação por ecrã, necessidade de pesquisa e comportamento sem Internet dependem desse contexto.
2. Separe funcionalidades essenciais de melhorias futuras
Liste o que a primeira versão precisa obrigatoriamente de fazer. Depois crie uma segunda lista com melhorias desejáveis. Esta separação evita que funções pouco importantes bloqueiem a entrega do fluxo principal e permite testar mais cedo se a ideia resolve o problema.
Para cada funcionalidade, escreva uma frase simples: quem inicia a ação, que dados são necessários, o que deve acontecer quando tudo corre bem e o que o utilizador deve ver quando existe um erro. Isto revela dependências que muitas vezes não aparecem num desenho de ecrãs.
3. Identifique de onde vêm os dados
Se a aplicação mostra informação externa, indique a fonte. Existe uma API? É necessária uma conta? Há limites de utilização? A informação muda de minuto a minuto ou apenas uma vez por dia? Pode ser guardada temporariamente no dispositivo? Estas respostas influenciam arquitetura, custos e comportamento em falhas de rede.
Uma integração não deve assumir que o serviço externo responde sempre. O briefing deve indicar o que é aceitável quando a fonte está indisponível: mostrar a última informação conhecida, apresentar uma mensagem clara, tentar novamente ou desativar temporariamente uma ação.
4. Pense em permissões e dados pessoais desde cedo
Localização, câmara, microfone, notificações e acesso a ficheiros não devem ser pedidos “porque podem dar jeito”. Associe cada permissão a uma funcionalidade concreta e defina o que acontece se o utilizador não a conceder. Se a aplicação puder funcionar sem determinada permissão, isso deve refletir-se no fluxo.
Quando existe tratamento de dados pessoais, indique que dados são necessários, para que finalidade, onde são processados e durante quanto tempo. Esta informação ajuda tanto o desenvolvimento como a preparação das políticas e mensagens apresentadas ao utilizador.
5. Defina plataformas, orientação e dispositivos
Especifique se o projeto é apenas para smartphone, se deve funcionar também em tablet ou se existe outro tipo de dispositivo Android. Indique ainda se a aplicação deve funcionar em retrato, paisagem ou ambos. Uma decisão desta natureza altera testes e desenho da interface.
6. Termine com critérios de aceitação
Um critério de aceitação descreve como saber que uma função está pronta. Por exemplo: “ao pesquisar um termo, a lista mostra resultados correspondentes e uma mensagem clara se não houver resultados”. Critérios concretos reduzem interpretações diferentes entre quem pede e quem desenvolve.
Um bom briefing não precisa de ser um documento enorme. Precisa de responder ao essencial: problema, utilizador, funcionalidades prioritárias, dados, integrações, permissões, dispositivos e resultado esperado.