Construindo um produto interno de prototipagem

Na Barte, o time de design tem um ambiente próprio de protótipos: um repositório real, com o nosso Design System de verdade, onde protótipos nascem funcionais, e com um detalhe, sem que o designer precise se preocupar com o front-end.

Não foi um projeto de engenharia. Foi construído por design, usando Claude, com o time de engenharia nos apoiando e desbloqueando nos pontos certos. Um projeto que começou despretensioso e virou um produto interno.

Quero contar como chegamos aqui, incluindo os problemas que criamos no meio do caminho.

Por que criamos

Três objetivos guiaram tudo desde o início:

Agilidade para prototipar com o Design System real. Prototipar direto com os componentes de produção, sem reconstruir nada em outra ferramenta e sem escrever front-end na mão, sem a mínima preocupação com o código que está gerando. O designer descreve, o Claude constrói, sempre dentro das regras do DS. Basicamente foi sair do Figma nessa etapa inicial e ir para o Claude.

Abrir ideias cedo e interagir rápido com o time. Um protótipo navegável, rodando no browser, muda a qualidade da conversa. Em vez de discutir sobre uma imagem estática, o time interage com a coisa funcionando.

Testar e aprender sem apego prematuro ao craft. No Figma, às vezes a pessoa investe em acabamento e cria apego cedo demais. Aqui, a ideia ganha forma em minutos, dá para errar rápido, jogar fora sem dor e iterar com uma velocidade que o fluxo tradicional não permite.

Os problemas que isso gerou

Como todo produto de verdade, depois de alguns meses rodando e com uso recorrente, descobrimos problemas que a gente não tinha previsto.

A colaboração ficou dispersa. O protótipo estava lá, navegável, mas o feedback acontecia no Slack, em threads soltas, prints e comentários que se perdiam. O ambiente acelerava a criação, mas não tinha onde acumular a conversa.

Alguns projetos ficaram desapegados demais. O “não se apegue ao craft” funcionou tão bem que, em alguns casos, virou uma bengala. Protótipos avançavam no fluxo sem passar pelo refinamento que o produto da Barte exige. A agilidade precisava de um contrapeso, como seguir eficiente na etapa inicial mas ter atenção no refinamento depois?

O handoff continuava difícil. Reparem que o Figma tinha saído do fluxo. Por ser um ambiente separado, o código do protótipo não era reaproveitado. A engenharia recebia a referência funcional, mas reconstruía do zero, assim parte do valor de prototipar em código se perdia, não fazia sentido “dev tirando print para começar a codar”. Figma usando MCP ainda era muito mais eficiente para engenharia.

O que fizemos

Duas construções atacaram esses problemas de frente:

Uma skill que leva o protótipo para o Figma com fidelidade total ao DS. Não é um print, nem redesenhar do zero, são instâncias reais dos componentes da nossa library, geradas a partir do código do protótipo. Isso devolve ao designer o espaço de trabalhar o detalhe, na ferramenta certa. Assim fechou o ciclo entre código e design nos dois sentidos, craft e handoff.

Uma camada de comentários dentro do próprio ambiente. Criamos um sistema de comentários, estilo Figma, dentro do ambiente em 2 dias. Qualquer pessoa do time comenta direto sobre o protótipo, ancorado no ponto exato da tela, desde os primeiros rabiscos. A conversa que antes se dispersava no Slack agora deixamos centralizada no mesmo local.

E o ambiente também é onde rodamos testes de usabilidade com protótipos funcionais — internos e com clientes, como sempre esteve no plano. Como estamos em um contexto fintech, com compliance e sigilo de dados levados a sério, adicionamos uma camada de autenticação simples via código de acesso — só quem recebe o código entra. Isso nos permite colocar protótipos navegáveis na frente de usuários reais, com segurança, sem expor nada.

Como foi feito

Esse talvez seja o ponto mais importante do artigo: tudo isso foi construído por designer, usando Claude.

O repositório, as skills, a camada de comentários, a integração com o Figma, nada disso passou pelo backlog de engenharia como projeto. O papel da engenharia foi outro, e foi essencial: engenheiros nos apoiando nas decisões de infraestrutura, validando abordagens e desbloqueando o que estava fora do nosso alcance (como por exemplo a infra de base de dados para persistir os comentários).

É um modelo que acredito muito: design com autonomia para construir suas próprias ferramentas, e engenharia como parceira estratégica.

O resultado

O que começou como um atalho para prototipar virou um produto interno: um ambiente que dá eficiência ao time de design e ao processo de produto da Barte como um todo.

Protótipos que nascem em código, com o DS real. Colaboração que acontece em cima do artefato. Craft que volta para o Figma quando precisa de detalhe. E um caminho de handoff cada vez mais curto entre a ideia e o produto.

Ficou curioso de ver como isso roda na prática? O próximo artigo será um estudo de caso de ponta a ponta: como fazemos design na Barte.