Descrever a tua app (mini-PRD)

Porquê descrever antes de gerar

A tentação é grande de abrir a ferramenta e escrever «faz-me uma app de acompanhamento de hábitos». Experimenta, e verás o problema: a IA vai preencher todos os vazios com as suas próprias escolhas. Vai decidir as cores, as funcionalidades, a estrutura — e há poucas hipóteses de as escolhas dela corresponderem ao que tinhas em mente. Vais depois passar dez mensagens a desfazer o que podias ter evitado com dois minutos de reflexão.

É todo o interesse do mini-PRD. PRD significa «Product Requirements Document», o caderno de encargos que as equipas de produto profissionais escrevem. A versão «mini» cabe numa dezena de linhas e responde a cinco perguntas: para que serve a app, quem a usa, o que faz exatamente, que aspeto tem, e sobre que base técnica. Com isso, a IA produz à primeira algo próximo da tua visão.

Há um benefício escondido: escrever o mini-PRD obriga-te a clarificar o teu próprio pensamento. Muitas ideias de apps parecem límpidas na cabeça e revelam-se vagas no papel. «Uma app para ajudar os alunos» — está bem, mas a fazer o quê, concretamente? O mini-PRD é a tua primeira ferramenta de chefe de projeto, antes mesmo do primeiro prompt.

O mini-PRD em cinco blocos

• Objetivo: uma frase. «Uma app web para acompanhar os hábitos de trabalho diários.»
• Utilizadores: quem a usa e em que contexto. «Alunos do ensino básico, no telemóvel, à noite.»
• Funcionalidades: 3 a 5 ações concretas, numeradas. Não mais para uma v1.
• Estilo: 3-4 adjetivos e uma restrição. «Minimalista, mobile-first, destaque verde, botões grandes.»
• Técnica: mantém-te simples. «HTML/CSS/JS simples, armazenamento local, sem conta de utilizador.»

A ordem tem a sua importância: parte-se da intenção (o objetivo) para acabar na implementação (a técnica). Se não souberes o que pôr no bloco técnico, escreve simplesmente «o mais simples possível, sem base de dados nem conta de utilizador» — a IA vai perceber e escolher por ti uma base saudável.

O mini-PRD do Tom, completo

Quero construir uma app web: um acompanhamento de hábitos.
Utilizadores: alunos do ensino básico que querem manter rotinas de trabalho, sobretudo no telemóvel.
Funções:
1. adicionar / eliminar um hábito
2. marcar todos os dias se o hábito foi cumprido
3. ver uma série (streak) de dias consecutivos de sucesso
4. ver um mini-calendário do mês com os dias marcados
Estilo: minimalista, mobile-first, destaque verde, botões grandes fáceis de tocar.
Técnica: HTML/CSS/JS simples, armazenamento local (localStorage), sem conta de utilizador.
Constrói primeiro APENAS as funções 1 e 2. Adicionaremos o resto depois dos meus testes.

Observa a última linha: o Tom dá a visão completa, mas pede explicitamente para construir apenas as funções 1 e 2. É a combinação vencedora — a IA conhece o destino (fará escolhas coerentes com o que vem a seguir), mas o primeiro entregável permanece pequeno e testável. Validas a base, e depois pedes «adiciona agora a função 3» numa mensagem seguinte.

As palavras que mudam tudo

Certos termos do teu mini-PRD têm um efeito desmesurado no resultado. «Mobile-first» diz à IA para conceber primeiro para um ecrã pequeno — crucial se os teus utilizadores estão no telemóvel. «Armazenamento local» evita toda a complexidade das contas e servidores. «Minimalista» orienta para um design sóbrio em vez de sobrecarregado. Estas palavras-chave são atalhos para decisões técnicas inteiras.

Inversamente, certas palavras desencadeiam uma complexidade que nem suspeitas. «Conta de utilizador» implica registo, login, palavras-passe, recuperação — horas de trabalho. «Notificações» implica autorizações e serviços externos. «Tempo real» (ver as alterações dos outros instantaneamente) implica um servidor permanente. Se uma destas palavras se infiltrar na tua v1, pergunta-te seriamente se pode esperar pela v2.

Descrever o estilo sem ser designer

Não precisas de vocabulário de designer para obter uma app bonita. Três técnicas simples: dá adjetivos (minimalista, caloroso, profissional, lúdico), cita uma referência conhecida («no espírito da app Notas da Apple», «sóbrio como um site de imprensa»), e especifica uma cor de destaque («destaque verde», «tons azul-noite»). A IA traduzirá estas indicações em escolhas tipográficas e visuais coerentes.

Se o primeiro resultado não te agradar, afina por comparação em vez de jargão: «mais arejado», «os botões são demasiado pequenos para um polegar», «demasiadas cores, mantém apenas o verde e o cinzento». São comentários que qualquer pessoa pode formular, e a IA compreende-os perfeitamente.

Priorizar: v1 ou mais tarde?

Distingue o «indispensável v1» do «seria bom mais tarde». O teste é simples: sem esta função, a app continua a ser útil? Se sim, é «mais tarde». O Tom aplica o teste: sem a adição de hábitos, a app está vazia — v1. Sem a marcação diária, não serve para nada — v1. Sem as notificações, funciona muito bem — mais tarde. Sem a partilha entre alunos, também — mais tarde.

flowchart TD
  I["Ideia de funcionalidade"] --> Q["Sem ela, a app é útil?"]
  Q -->|"Não, fica inutilizável"| V1["Indispensável v1"]
  Q -->|"Sim, funciona na mesma"| V2["Lista «mais tarde»"]
  V1 --> P["No mini-PRD"]
  V2 --> L["Anotada para a v2"]

Guarda a tua lista «mais tarde» num ficheiro ou numa nota: não é um caixote do lixo, é o teu roteiro. No capítulo 5, com a app implementada, é nessa lista que vais buscar as próximas melhorias — guiado pelo feedback dos teus primeiros utilizadores.

Mini-glossário do capítulo

• PRD: Product Requirements Document, o caderno de encargos de um produto.
• localStorage: um pequeno espaço de armazenamento no navegador, onde uma app pode guardar dados sem servidor.
• Mobile-first: conceber primeiro para telemóvel, depois adaptar aos ecrãs grandes.
• v1 / v2: primeira versão utilizável / versão melhorada seguinte.
• Streak: série de dias consecutivos de sucesso (termo corrente nas apps de hábitos).