inteligência artificial
time inspira
Design to code: o que mudou no nosso jeito de construir
A construção de um produto digital costumava funcionar como uma corrida de revezamento. Quem desenha a tela entrega o trabalho para quem programa, que entrega para quem testa, e assim por diante. Cada troca de mãos custa tempo e espera. Aqui na Inspira, redefinimos esse fluxo: a pessoa que desenha agora também entrega o código pronto.
Para ilustrar, vou contar como foi a construção de um portal completo construído por quatro pessoas em seis semanas.
O tempo perdido na passagem de bastão
No jeito tradicional de trabalhar, o caminho entre a ideia e o produto final passa por várias pessoas.
Primeiro, a designer desenha cada tela no Figma, que funciona como uma prancheta digital. Depois, entrego esse desenho para a pessoa que programa, o desenvolvedor. Ele olha o desenho e tenta reconstruí-lo em código, que é a linguagem que o computador entende. Em seguida, eu confiro o resultado e aponto o que ficou diferente do planejado: um espaçamento errado, uma cor fora do tom. O desenvolvedor corrige. Só então o trabalho segue para os testes e para a publicação.
Pense no fluxo de uma petição que passa por revisões sucessivas entre o estagiário, o advogado e o sócio. Cada ida e volta tem um custo. Não é só o tempo de fazer a correção. É o tempo de esperar a sua vez na fila de cada pessoa.
Um ajuste de cinco minutos entra na lista de afazeres do desenvolvedor e pode levar dias para sair, porque ele está ocupado com coisas maiores.
Tem ainda mais um problema: a perda de contexto. Quem desenhou a tela sabe exatamente como ela deveria se comportar em cada situação. Quem programa recebe só uma imagem parada e precisa adivinhar a intenção por trás dela. É nessa distância entre as duas cabeças que nasce a maior parte do retrabalho.
O que mudou na prática
Passei a entregar o código diretamente, sem depender de outra pessoa para traduzir meu desenho. Para isso, usei o Claude Code, uma ferramenta de inteligência artificial que escreve código, conectada ao Figma, onde eu desenho.
Na prática, o fluxo ficou assim:
Desenho a tela no Figma, seguindo o padrão visual da Inspira.
A IA lê o meu desenho e gera o código correspondente.
Eu reviso e ajusto esse código até a tela ficar exatamente como deve, inclusive funcionando bem no celular e para pessoas com deficiência.
Escrevo os testes que verificam se a tela funciona como o esperado.
Submeto o trabalho para o time de programação.
O desenvolvedor revisa a estrutura e a lógica do código, não mais a aparência.
O sistema publica a nova tela automaticamente.
A diferença não é deixar a passagem de bastão mais rápida. É não precisar mais dela. Quem desenha é quem constrói.
Os números de seis semanas
Em seis semanas, escrevi cerca de 10.193 linhas de código aproveitadas no produto final. Os três desenvolvedores do time, somados, escreveram 9.569. Sozinha, entreguei mais código do que toda a equipe de programação.
Seis das doze páginas do portal saíram da minha mão. E não eram só mudanças de cor. Eram telas completas, com tudo funcionando:
Usuários e menu lateral: a página de gestão de usuários e a estrutura de navegação do sistema.
Assinaturas: a área de gestão de planos e o histórico de faturas.
Cobrança: os dados de pagamento e os ajustes finais de interface.
Página inicial: o banner de boas-vindas e a navegação.
Login: a reformulação do fluxo de entrada no sistema.
Uma das minhas entregas foi aprovada e publicada em oito minutos. O desenvolvedor olhou, aprovou e liberou. Isso diz muito sobre a confiança no código que sai desse jeito de trabalhar.
O que muda para cada lado
Para mim, como designer, a palavra é autonomia. Vejo um problema, corrijo e entrego no mesmo dia, sem depender da agenda de ninguém. E a qualidade visual fica garantida, porque não existe mais uma tradução no meio do caminho que possa dar errado.
Para o time de desenvolvimento, a revisão muda de natureza. Em vez de gastar energia conferindo espaçamento e cor, eles conferem a parte que realmente exige o conhecimento deles: a estrutura técnica e as integrações mais pesadas, como segurança de acesso e sistemas de cobrança.
Para o produto, a conta fecha sozinha. Seis semanas, doze páginas, quatro pessoas, um portal inteiro do zero. Na prática, foi como dobrar o time de front-end sem contratar ninguém.
O papel do designer está mudando
Antes, o designer entregava o desenho e esperava. Agora, entrega o produto funcionando, testa e só procura o desenvolvedor para uma validação técnica. É uma mudança de função, não só de ferramenta.
Não acho que isso valha para todo time ou todo projeto. Funcionou aqui porque já tínhamos um padrão visual maduro, uma base técnica bem definida e desenvolvedores dispostos a revisar de um jeito novo. Mas a direção parece clara: a fronteira entre desenhar e construir está mais fina do que era há um ano.
O que fica
A passagem de bastão não foi acelerada. Foi eliminada. Quando a mesma pessoa desenha, constrói e testa, a distância entre a ideia e o produto final quase desaparece. Foi isso que nos permitiu entregar um portal inteiro com um time pequeno, num prazo curto, sem abrir mão de qualidade.
A pergunta que isso deixa para qualquer área, jurídica ou tecnológica, é a mesma: quanto do seu tempo hoje não é gasto fazendo o trabalho, mas traduzindo o que já foi decidido de uma pessoa para outra?
Se você quer entender como unimos design e tecnologia na Inspira, vale conhecer a ferramenta que construímos para elevar a prática jurídica.
Leia mais – Tecnologia construída por quem sabe Direito
Perguntas frequentes
O que é o fluxo design to code?
É um jeito de trabalhar em que a mesma pessoa que desenha a interface também entrega o código dela, sem repassar o trabalho para outra pessoa programar. Uma ferramenta de inteligência artificial lê o desenho e gera o código, que a designer revisa e finaliza.
O designer substitui o programador nesse modelo?
Não. O desenvolvedor continua essencial, mas o foco do trabalho dele muda. Em vez de reconstruir telas, ele cuida da estrutura técnica, da lógica e das integrações complexas, que seguem sendo responsabilidade da engenharia.
Esse jeito de trabalhar serve para qualquer time?
Depende. Funciona melhor quando já existe um padrão visual consolidado, uma base técnica organizada e um time aberto a revisar o trabalho de forma diferente. Sem essa estrutura, a velocidade extra costuma virar retrabalho.
Preciso entender de programação para acompanhar esse modelo?
Para usar o produto final, não. A mudança é interna, no modo como construímos. Para quem é da área e quer adotar algo parecido, o essencial é dominar a ferramenta de desenho e ter alguma familiaridade com a lógica do código.
