A planilha que virou produto

Estive em todas as etapas, da primeira conversa até o código: defini o problema, modelei o domínio, desenhei o produto inteiro, construí o design system e segui na implementação ao lado de um desenvolvedor, aprendendo versionamento e programação assistida por IA no caminho.

A entrega final foi além das telas: mantive um repositório com a documentação de todo o processo, em que cada decisão ficou registrada junto do raciocínio que a sustentava. Foi o que permitiu a informação atravessar as etapas sem se perder e chegar inteira ao desenvolvimento.

Antes de abrir qualquer ferramenta de design, eu defini o método.

Conduzi o projeto inteiro com IA, e a primeira coisa que construí não foi uma tela: foi uma skill. Um conjunto de instruções reutilizável que ensinava o Claude a conduzir qualquer etapa seguinte, do brainstorming à modelagem de domínio. Apoiei essa skill em frameworks de estruturação de incerteza e formulação de perguntas, e fixei nela uma regra inegociável: nenhuma lacuna de informação é preenchida por suposição.

Com o método de pé, dirigi a construção do documento de produto a partir de duas fontes: um documento de brainstorming e a planilha que o usuário já usava. Pedi a leitura das fórmulas da planilha, não só dos valores visíveis. Essa instrução fez aparecer a lógica de negócio que a planilha já tinha.

Com as regras estáveis, pedi a tradução do documento para um modelo formal de domínio: eventos, comandos, políticas e agregados. Onde havia tensão sem resposta certa ainda, instruí que ficasse marcada como hotspot em vez de decidida no automático.

Com o modelo de negócio validado, passei de "o que o sistema faz" para "o que a pessoa vê".

Comecei pelo fluxo do usuário: mapeei o caminho completo, do primeiro acesso até as ações do dia a dia. Assim desenhei cada tela sabendo por que ela existia e o que vinha antes e depois dela.

Desenhando os wireframes, apareceram mais decisões. Toda vez que uma tela levantava uma pergunta de comportamento, eu registrava a pergunta, a resposta e o raciocínio por trás dela, na ordem em que aconteceram. Esse hábito virou um documento: um histórico cronológico do porquê de cada tela ser do jeito que é.

E a documentação virou artefato de handoff. Para cada tela, escrevi a especificação funcional separada do desenho visual, o modelo de dados exato de cada campo, e um glossário fechado de nomenclatura. A meta era simples: quem fosse implementar não deveria precisar me perguntar nada que já não estivesse escrito.

Parte da interface é gerada a partir do dado. Então documentei também as regras de renderização: o algoritmo por trás do desenho. Sem isso, quem fosse programar teria que inventar comportamento para cada caso extremo.

Antes de aplicar qualquer visual definitivo, construí o sistema.

Uma coleção fechada de tokens de cor nomeados por papel semântico, cada um com valor próprio para o tema claro e para o escuro. Junto, escalas de tipografia, espaçamento e raio, e uma biblioteca de componentes documentada com cada variante e cada estado.

E foi só vendo a cor na tela real que decisões novas apareceram. O par de cores que distingue pessoa física de pessoa jurídica passava no contraste no tema claro e reprovava no escuro. Corrigir exigiu matizes diferentes por tema, não um ajuste automático. Tema escuro não é inversão: é um segundo sistema, e precisa ser validado sozinho.

Entreguei o design e continuei junto.

Construí o produto ao lado de um desenvolvedor e do Claude: backend completo, banco de dados, contrato de API e centenas de testes automatizados, tela por tela, fiel ao que eu tinha desenhado e documentado.

No fim, uma auditoria de fidelidade. Mais de cem agentes de IA rodando em paralelo, cada um cruzando uma tela implementada contra o frame real no Figma, mostrou o tamanho do que a documentação sustentava sozinha. Com tudo já especificado antes, a implementação só precisou seguir.

O produto existe, funciona e está em uso.

Aprendi a decidir o que as coisas são, e sustentar essa decisão em cada tela depois. Aprendi a escrever para quem vem depois de mim, e descobri que documentar bem é o que faz o design sobreviver ao contato com a implementação. E aprendi que trabalhar com IA se decide antes, não depois: o que define a qualidade do que volta é a regra que eu estabeleci no começo, não a minha avaliação de cada resposta. Sem ela, qualquer resultado plausível passa.