Aula 09 - Formulários: a primeira entrega do MVP

Do plano para a primeira entrega

Até aqui o projeto foi desenhado. Na aula 07 você respondeu às perguntas de descoberta e criou a persona. Na aula 08, transformou essas respostas em arquitetura, componentes, decisões técnicas e issues. Nada disso foi construído ainda.

Hoje começa a fase de construção, e ela começa por uma parte só: o formulário.

Abra estes materiais antes de começar:

• descoberta.md, da aula 07, com o público e a ação principal;
• arquitetura.md, com o mapa do site e o caminho até a ação;
• componentes.md, com o que foi previsto para cada página;
• tecnologia.md, com as escolhas e os limites do MVP;
• design.md e tokens.css, da aula 06, com as decisões visuais;
• o quadro de issues no GitHub Projects.

O trabalho de hoje é uma entrega pequena do MVP, feita em um ciclo curto:

Escolher uma tarefa → Construir → Testar → Ajustar → Conferir a entrega

É como cozinhar provando o tempero, a analogia da aula 07. Você não precisa preparar o cardápio inteiro para descobrir que faltou sal. Faz uma parte, prova e ajusta. No site, o teste mostra se quem usa consegue usar o que você construiu.

O plano dá a direção, mas não diz o que está errado. Quem descobre o problema é a pessoa que tenta usar.

Exemplo usado nesta página

Vamos usar o projeto fictício Maria da Padaria para preencher os exemplos.

Decisão já tomada	Registro da Maria
Público	Mães que usam o celular para encomendar bolo
Ação principal	Pedir pelo WhatsApp
Página do contato	/contato, já no mapa da aula 08
Estilo	Acolhedor, com terracota, bege e texto marrom
Limite do MVP	Sem blog e sem pagamento online agora

Use os dados do seu projeto no lugar dos exemplos.

O formulário dentro da ação principal

Antes de criar qualquer campo, volte ao descoberta.md e procure a resposta para a pergunta o que o visitante deve fazer no site? Depois, encontre essa ação no fluxo do arquitetura.md.

Projeto	Ação principal	O que o formulário pode servir
Padaria da Maria	Pedir pelo WhatsApp	Receber a encomenda quando a pessoa prefere escrever com calma
Fotógrafa	Pedir um orçamento	Receber nome, contato e tipo de ensaio
Oficina de bicicletas	Agendar atendimento	Receber contato e descrição do problema
Portfólio pessoal	Conhecer os trabalhos	Receber propostas de trabalho

O formulário não substitui a ação principal. Na Maria da Padaria, o botão de WhatsApp continua em destaque, porque foi assim que o plano definiu o caminho mais rápido. O formulário oferece um segundo caminho, dentro da página que o mapa já previu.

Se o seu projeto não precisa de um formulário como caminho principal, não force. Mantenha o que foi planejado e construa um contato complementar que faça sentido para o seu público.

A analogia do papelzinho

Na loja, a Maria anota um pedido num papel: nome da pessoa, forma de contato e o que ela quer encomendar. O formulário é esse papelzinho em versão digital.

A diferença é o contexto. A Maria está do outro lado da mesa e pode explicar uma pergunta confusa. Quem preenche o formulário está no sofá, no celular, sem ninguém por perto para ajudar. Por isso, cada campo precisa se explicar sozinho.

É como a diferença entre um pedido no balcão e um envelope pelo correio. O conteúdo pode ser o mesmo, mas quem vai ler o envelope não pode te perguntar o que você quis dizer.

Só o necessário

Cada campo novo é mais uma barreira entre a pessoa e o envio. A regra prática é simples: preciso dessa informação para dar o próximo passo?

Informação	Para que serve	Entra agora?
Nome	Saber com quem conversar	Geralmente, sim
E-mail ou WhatsApp	Responder ao pedido	Sim, escolha o canal que será usado
Mensagem	Entender o que a pessoa precisa	Sim
Endereço completo	Organizar uma entrega	Pode ser pedido depois, no contato
CPF	Emitir um documento quando necessário	Não para um primeiro contato

Três campos são um bom ponto de partida para um formulário de contato, mas não são regra. Uma reserva de horário precisa de data e hora. Um orçamento de fotografia pode precisar do tipo de ensaio. O que não pode acontecer é um campo que você não consiga justificar.

Um endereço pedido com folga é mais fácil de obter do que um cliente perdido. A Maria pode perguntar o CEP no WhatsApp, depois que a pessoa já se comprometeu com o pedido.

A tarefa no quadro

No GitHub Projects, encontre a issue ligada à página de contato. Se ela estiver grande demais para uma aula, separe a construção do formulário em uma tarefa que possa ser concluída e testada hoje.

O que diferencia uma boa issue de uma ruim é a lista de critérios de conclusão. Ela diz quando a tarefa acabou, sem depender de opinião.

Exemplo de issue:

## Título
Adicionar formulário de contato à página Contato

## Contexto
Algumas pessoas preferem descrever a encomenda por escrito.
O formulário complementa o botão de WhatsApp da Maria da Padaria.

## Pronto quando
- O formulário pede nome, contato e mensagem.
- Os campos têm nomes visíveis e instruções claras.
- O visual usa os tokens do projeto.
- Uma mensagem de teste chega ao destino escolhido.
- A pessoa vê se o envio deu certo ou se precisa tentar de novo.
- O formulário pode ser preenchido no celular.

Dois desses critérios carregam o peso da aula. “Ficou bonito” não basta se o pedido não chega. “A mensagem chegou” também não basta se ninguém consegue preencher no celular.

Coloque a issue em Fazendo. Ideias maiores, como agenda automática ou painel de pedidos, ficam no Backlog e não entram hoje.

Para onde vai o pedido

Um formulário tem duas partes:

1. O que a pessoa vê: título, instruções, campos, botão e o retorno depois do envio.
2. Para onde o pedido vai: um serviço que recebe as informações e as entrega a quem cuida do site.

A segunda parte é a que costuma ser esquecida. Um site estático mostra os campos com muita facilidade, mas os campos por si só não guardam nem enviam nada.

Para receber pedidos sem construir um sistema próprio, existem serviços que recebem os dados de um formulário e os entregam por e-mail ou guardam numa planilha: Formspree, Web3Forms, Getform e outros. O caminho mais simples é configurar a URL do serviço no action do formulário. O que importa não é o nome da ferramenta, e sim você saber responder a uma pergunta: onde o pedido vai parar e quem vai ver?

Também existe a opção de incorporar um Google Forms, que gera um bloco pronto para colar na página. Ela serve quando a prioridade é começar rápido e organizar respostas numa planilha. Em troca, o formulário tem menos liberdade para seguir o visual do site e costuma parecer um formulário genérico dentro da sua página.

Escolha um caminho e siga até o fim. Não é necessário fazer os dois.

Antes de pedir ajuda à IA, confirme o destino das mensagens e use respostas fictícias nos primeiros testes. Um formulário publicado recebendo dados reais de pessoas que não são do projeto é um problema de privacidade, não um detalhe técnico.

O retorno depois do envio

A parte mais esquecida de um formulário é o que acontece depois que a pessoa aperta o botão. Ela precisa saber o que aconteceu, e você precisa ter pensado nas três situações possíveis.

Situação	O que a página deve comunicar
Falta uma informação	Qual campo precisa ser preenchido ou corrigido
Envio concluído	Que a mensagem foi enviada e o que acontece depois
O envio falhou	Que a mensagem não chegou e como tentar de novo

Cada uma dessas respostas pede uma decisão diferente de quem preenche. Uma mensagem de sucesso que não confirma nada deixa a pessoa em dúvida e abre a página de novo, o que costuma gerar mensagens duplicadas.

Promessa é dívida. Se o formulário diz “respondemos em 24 horas”, alguém precisa assumir esse compromisso. Se ninguém assumiu, escreva “recebemos seu pedido e vamos responder pelo contato informado”.

Nomes visíveis nos campos

A pessoa precisa saber o que escrever mesmo depois de começar a digitar. Por isso, cada campo tem um nome visível acima dele. Um texto dentro da caixa serve de dica, mas não substitui esse nome.

Mais difícil de entender	Mais claro
Campo sem nome, com “Digite aqui” dentro	Seu nome acima do campo
“Contato” sem explicação	WhatsApp para resposta
“Mensagem” sem contexto	Conte o que você gostaria de encomendar

Marque como obrigatórios só os campos necessários para responder, e diga isso perto do formulário. Uma pessoa que preenche um campo à toa e recebe um erro no final entende que o site fez ela perder tempo.

O visual já foi decidido

Use o design.md e o tokens.css da aula 06. O formulário é um componente do mesmo site que o resto: mesma fonte, mesmo espaçamento, mesmas cores, mesmo padrão de botão.

Peça à IA para construir reaproveitando os componentes que já existem. Uma cor nova, uma borda com espessura diferente e um botão de outro formato fazem o formulário parecer um formulário colado dentro da página.

O botão precisa ser fácil de localizar e ter um texto que descreva a ação, como Enviar pedido. Um botão que se pareça com um link de texto faz a pessoa passar por cima dele sem perceber que existe.

Persuasão com honestidade

Você conheceu a ideia de design persuasivo na aula 02 e organizou conteúdo, CTA e prova social na aula 06. No formulário, essas decisões ajudam a pessoa a entender por que vale a pena escrever em vez de só procurar o telefone.

Perto dos campos, mostre o que ajuda a decidir: o que acontece depois do envio, por qual canal a resposta vai chegar e, se o projeto já tiver, um depoimento real.

Existe um limite, e ele é a honestidade. Um desenho que leva a pessoa a agir sem saber o que está fazendo é o que se chama de dark pattern. Três exemplos que aparecem com frequência em formulários:

O que é	Como se manifesta
Seleção pré-marcada	Uma opção que a pessoa não pediu já vem marcada
Escassez inventada	“Últimas 3 vagas” reaparecendo todo dia, mesmo quando há mais
Campo que não pode ser recusado	Assinatura de newsletter misturada ao botão de enviar

A diferença entre persuasão honesta e manipulação cabe numa pergunta: essa pessoa receberia a mesma informação se eu estivesse do outro lado? Se ela leria tudo, entenderia tudo e concordaria, a manipulação está errada.

Um formulário de confiança é aquele que você não teria receio de mostrar para a sua cliente mais antiga. Ela lê tudo, entende tudo e concorda.

Prática guiada

A prática tem cinco etapas. O objetivo não é terminar rápido, e sim terminar com uma entrega que funciona e um problema concreto anotado.

1. Escolher e preparar a tarefa

1. Leia a ação principal no descoberta.md.
2. Localize no arquitetura.md a página onde o contato acontece.
3. Confira no componentes.md se o formulário já foi previsto.
4. Escolha os campos necessários e o destino das mensagens.
5. Escreva os critérios de conclusão na issue e mova para Fazendo.

2. Construir uma primeira versão

Peça à IA para trabalhar com os arquivos que já existem, e faça uma mudança pequena por vez: primeiro os campos e o envio, depois o acabamento visual.

Prompt de exemplo para o OpenCode:

Leia descoberta.md, arquitetura.md, componentes.md, tecnologia.md,
design.md e tokens.css antes de alterar o site.

Quero acrescentar à página de Contato um formulário com nome,
[e-mail ou WhatsApp] e mensagem. Mantenha o CTA principal definido
no projeto. Use os estilos e os componentes existentes. Explique como
configurar o destino das mensagens no serviço escolhido. Depois, mostre
quais arquivos foram alterados e como posso testar o envio.

Leia a proposta antes de aceitar. Se aparecerem campos novos, uma paleta diferente ou uma página que não estava no MVP, pergunte o motivo antes de aprovar. Quem filtra a sugestão da IA é você, não o contrário.

3. Fazer o primeiro teste

Abra o site no celular ou na visualização de celular. Preencha com dados de teste e envie uma mensagem que você consiga reconhecer de imediato, como Teste aula 09 - pedido de bolo de cenoura.

Confira os dois lados da conversa:

• Quem envia: entendeu os campos e recebeu um retorno claro na página?
• Quem recebe: encontrou a mensagem no destino configurado?

Teste também o caminho dos erros: um campo obrigatório vazio e um contato escrito errado. Se o serviço de envio mostrar uma página externa depois do envio, confirme que a pessoa ainda entende que o pedido foi registrado.

4. Observar outra pessoa

Esta é a etapa que muda o resultado da aula. Convide uma colega para fazer um pedido fictício e não explique onde clicar. Observe em silêncio e deixe que ela tente sozinha.

Depois pergunte:

• Onde você esperava encontrar o contato?
• Alguma pergunta ficou confusa?
• Você soube se o envio deu certo?
• O que mudaria para terminar mais rapidamente?

Anote o problema com as palavras dela. “Ela parou no campo de contato porque não sabia se devia escrever e-mail ou WhatsApp” serve. “Ela não curtiu” não serve, porque não aponta nada que você possa corrigir.

5. Ajustar e conferir

Escolha o problema mais importante do teste e corrija aquele. Pode ser o nome de um campo, a mensagem de retorno, o espaço para tocar no botão, ou o destino do envio.

Teste de novo só a parte que mudou. Se o pedido chega, a pessoa recebe um retorno claro e os critérios da issue foram cumpridos, mova a tarefa para Feito. Se faltar algo, registre na própria issue e deixe a próxima tentativa começar com uma informação melhor do que a primeira.

Problemas comuns

O que aconteceu	O que conferir
O formulário aparece, mas a mensagem não chega	Confira a URL configurada no action e faça outro teste
A mensagem chega, mas a pessoa não sabe disso	Acrescente ou corrija o retorno mostrado depois do envio
A pessoa não entende um campo	Troque o nome ou a instrução por palavras usadas pelo seu público
O formulário é difícil de usar no celular	Reveja largura, espaçamento e o tamanho do botão
O formulário ganhou campos demais	Volte à ação principal e mantenha só o necessário agora
O botão de WhatsApp sumiu	Compare a página com o fluxo e o CTA definidos na aula 08
O visual ficou diferente do resto	Reutilize o design.md, os tokens e os componentes existentes
Chegaram mensagens duplicadas	A resposta de sucesso não está confirmando o envio
Apareceu uma ideia boa, mas grande demais	Registre no Backlog e termine a entrega atual

O ciclo se repete

O que você fez hoje é o mesmo que vai fazer nas próximas tarefas do site:

Plano do MVP → Uma entrega pequena → Teste com uma pessoa → Ajuste → Próxima tarefa

A mentalidade ágil aparece aqui: o plano dá a direção, e cada teste ajuda a decidir o próximo passo. Um formulário que funciona porque você testou vale mais do que um formulário que funciona porque parece certo.

Habilidades que desenvolvi hoje

• Sei encontrar no plano a ação principal do visitante e a página onde o contato acontece
• Sei escolher os campos necessários e justificar por que cada um entra
• Sei registrar os critérios de conclusão na issue antes de começar
• Sei configurar o destino das mensagens e confirmar que o pedido chega
• Sei garantir nomes visíveis nos campos e um retorno claro depois do envio
• Sei testar o formulário no celular e registrar um problema concreto observado

Material de apoio

Recurso	Para que usar
Slides da aula 09	Deck para projetar na sala
Demo de Contato	Ver os campos e o retorno funcionando
MDN Web Docs - Forms	Consultar atributos de campo
Formspree	Serviço que recebe os dados de um formulário HTML
Web3Forms	Alternativa de envio sem backend