Um projeto pode começar bonito no diagrama e errado na tela. A pessoa modela banco, define entidades, escolhe framework e só depois descobre que o usuário precisava de outro fluxo, outra permissão ou outro estado de informação.

É por isso que a pergunta sobre por que começar pela interface antes do banco de dados voltou com força em projetos guiados por IA. A tela mostra a rotina real antes que a arquitetura fique cara de mudar.

Direto ao ponto

• Tela revela requisito: campos, ações, estados e permissões aparecem antes da primeira tabela.
• Estado vazio orienta onboarding: a tela sem dados precisa conduzir a primeira ação em vez de avisar que nada existe.
• IA precisa de referência verificável: interface, regra e limite reduzem código plausível sem aderência ao uso.

Interface primeiro não é estética antes de engenharia

Eu não começo pela interface porque acho a tela mais importante que o banco. Começo pela interface quando o projeto ainda precisa descobrir fluxo, prioridade e comportamento visível. A tela força uma conversa que a modelagem sozinha costuma adiar.

Quando você desenha a primeira experiência, surgem perguntas concretas. Qual ação aparece no topo. O que acontece quando não há dados. Quem pode editar. Que erro precisa ser explicado. Qual informação ajuda a decidir. Essas perguntas orientam banco, backend e requisito com menos chute.

Aqui na Promovaweb, eu vejo isso aparecer muito em Vibe Coding. A pessoa pede para a IA criar uma área inteira, mas ainda não sabe qual estado o usuário verá no primeiro acesso. O resultado costuma ser interface polida, regra frágil e backend montado para uma rotina que ninguém validou.

A interface inicial funciona como especificação visível. Ela não precisa nascer perfeita. Precisa mostrar o suficiente para que o responsável técnico, o founder e a pessoa que vai usar o sistema discutam a mesma coisa.

A tela revela requisitos que documento abstrato esconde

Documento de requisito ajuda quando registra decisão, regra e exceção. O problema é usar documento abstrato no lugar de experiência navegável. Uma frase como “usuário gerencia clientes” parece simples até a tela pedir busca, histórico, status, permissão, anotação e alerta.

Começar pela interface antes do banco de dados reduz esse tipo de surpresa. A tela obriga você a escolher hierarquia de informação. Se um campo aparece na primeira dobra, ele provavelmente tem peso no fluxo. Se uma ação fica escondida, talvez ela não seja tão central quanto parecia.

O Manifesto Ágil colocou software funcional acima de documentação extensa. Eu leio esse princípio com cuidado: documentação continua útil, mas uma tela navegável revela fricção que texto sozinho não mostra.

Figma ajuda nessa etapa quando a conversa ainda é visual. A própria Figma apresenta prototipagem como forma de criar experiências interativas antes do desenvolvimento. Em alguns casos, um protótipo basta para alinhar fluxo. Em outros, vale ir cedo para HTML, CSS e navegação real no browser.

Estado vazio precisa nascer antes do backend

O estado vazio é uma das melhores provas de que a interface deveria vir antes. Tela sem dados não é acabamento. Ela define primeira ação, promessa do sistema e evento inicial.

Se você só modela banco primeiro, tende a pensar no estado cheio: lista com registros, filtros preenchidos, gráficos funcionando. Só que o primeiro login normalmente não tem nada disso. A pessoa entra, olha uma tela vazia e decide se entendeu ou não o próximo passo.

No post sobre estado vazio em software SaaS, eu tratei essa tela como requisito de ativação. Aqui o raciocínio é complementar: se o estado vazio muda o onboarding, ele precisa influenciar banco, evento, copy e rastreamento desde cedo.

Um bom estado vazio responde quatro coisas. O que esta área faz. Qual primeira ação devo executar. Que dado será criado. O que muda depois dessa ação. Se a tela não responde isso, o backend pode até estar correto, mas a experiência começa confusa.

IA codifica melhor quando a intenção está visível

Agente de código gosta de instrução clara. O problema é que muita instrução textual ainda deixa margem para interpretação. Quando você entrega uma interface, estados e regras, a IA tem menos espaço para inventar prioridade visual, fluxo e comportamento.

O GitHub Spec Kit trabalha a ideia de especificações orientando implementação. Eu gosto de juntar esse raciocínio com interface inicial: a especificação textual define regra, limite e validação; a interface mostra fluxo, estado e ação.

Esse par é mais forte que prompt solto. Se você pede “crie um painel de clientes”, a IA pode devolver algo visualmente aceitável e funcionalmente raso. Se você mostra a tela, define estado vazio, lista permissões e descreve o evento que nasce da primeira ação, o código tende a ficar mais próximo do uso real.

Essa é uma boa conexão com requisitos menos ambíguos no SDD. A IA não precisa apenas de pedido; precisa de limite verificável. Interface sem requisito vira desenho. Requisito sem interface vira abstração difícil de testar.

Quando o banco de dados deve entrar

Banco entra quando o fluxo já mostrou sinais suficientes. Isso não significa esperar até o fim. Significa não fixar estrutura antes de entender a ação principal, o estado vazio, as permissões e os dados que realmente aparecem na tela.

Eu costumo olhar para três perguntas. Qual dado nasce da primeira ação. Qual dado será consultado com frequência. Qual dado precisa de histórico ou permissão. Se essas respostas ainda estão vagas, modelar tudo cedo demais aumenta retrabalho.

O artigo sobre lugar dos dados na arquitetura aprofunda essa parte. A tela ajuda a descobrir necessidade, mas a decisão final ainda precisa respeitar consistência, auditoria, cache, integração e custo de mudança.

Também existe o risco oposto: ficar refinando interface para adiar decisão técnica. Se a regra de domínio já é conhecida, se há integração crítica ou se existe restrição de segurança, banco e backend precisam entrar junto da tela. Interface primeiro não autoriza improviso.

Checklist para revisar antes da primeira tabela

Antes de modelar banco, eu revisaria a interface com um checklist curto. Ele ajuda a separar tela útil de mockup bonito.

• Ação principal: a tela deixa claro o que a pessoa deve fazer primeiro.
• Estado vazio: a tela sem dados orienta ação, cria referência e evita mensagem genérica.
• Permissão: cada ação importante tem dono, limite e consequência.
• Erro esperado: falhas previsíveis aparecem com mensagem compreensível.
• Dado necessário: cada campo existe porque ajuda decisão, registro ou automação.
• Uso mobile: a experiência continua legível em telas menores.
• Custo de manutenção: a interface não cria promessa que backend, suporte ou contrato não sustentam.

Esse checklist conversa bem com a Formação IA Makers, porque Vibe Coding exige mais do que pedir código. Você precisa revisar intenção, tela, regra e consequência antes de deixar a IA avançar.

Para comparar ferramentas e stack, a página de ferramentas da Promovaweb ajuda a situar Figma, Astro, Tailwind CSS, agentes de IA e outras peças do processo. A página de Vibe Coding completa esse caminho quando a dúvida é como transformar interface, requisito e revisão em código assistido por IA.

Perguntas comuns sobre interface antes do banco

Figma substitui código navegável?

Não substitui em todos os casos. Figma ajuda a validar fluxo visual, hierarquia e conversa com cliente. Código navegável ajuda a testar responsividade, estados reais, acessibilidade e limites de implementação.

Começar pela interface atrasa backend?

Quando a tela é objetiva, costuma reduzir retrabalho. O atraso aparece quando o protótipo vira exercício estético sem regra, estado ou decisão técnica.

Isso funciona com IA?

Funciona melhor quando a interface vem acompanhada de especificação curta. A IA precisa saber quais estados existem, quais ações são permitidas e qual resultado deve ser verificado.

Quando não começar só pela tela?

Quando o sistema depende de regra regulatória, integração crítica, segurança forte ou domínio já definido, interface e modelagem precisam caminhar juntas desde o início.

Como aplicar o critério na rotina

Começar pela interface antes do banco de dados é uma forma de reduzir suposição. A tela mostra o que a pessoa precisa fazer, o que falta no primeiro acesso e quais dados realmente sustentam a experiência.

Eu não usaria esse critério como moda de design. Usaria como disciplina de descoberta: primeiro entenda a ação visível, depois modele o dado que sustenta essa ação. Em projetos com IA, essa ordem ajuda a transformar Vibe Coding em trabalho revisável, não em geração de tela bonita sem contrato técnico.