Equipes adotam prototipagem no código com IA em vez de Figma

Do mockup ao branch: prototipando direto no código

A equipe de design da Workable passou a prototipar funcionalidades dentro do repositório real do produto, usando branches Git e os mesmos componentes que a engenharia utiliza em produção, em vez de apenas criar telas estáticas no Figma. A mudança começou como um experimento individual de Margarita Skiada e depois foi adotada pelo time inteiro, com apoio direto dos engenheiros na configuração de acesso, SSH, GitHub e proteções de branch.

Como funciona na prática

O processo é tratado como uma “receita” simples, não como um rito técnico. O designer abre o repositório no Cursor, atualiza o branch main com git pull, cria um branch novo para cada ideia - por exemplo, design/reports-proto - e constrói ali. Em seguida, faz commit e push, o que gera um pull request em rascunho. O fluxo para aí: nada é aberto para merge nem tratado como código pronto para produção.

A principal função desses protótipos é serem avaliados pelo time de produto, engenharia e stakeholders. Como o código usa componentes reais, estados de carregamento, dados, restrições de layout e comportamentos do produto aparecem cedo, ainda na fase de design. Figma continua sendo usado, mas como espaço de exploração inicial e briefing, não mais como entregável final.

Sem link mágico de compartilhamento

Um ponto destacado é que não existe um link público para compartilhar o protótipo. Ele roda localmente na máquina do designer e pode ser visualizado apontando o ambiente de staging para aquele build local, dentro do contexto do produto real. Para outras pessoas do time verem a proposta, basta baixar o branch do GitHub e executá-lo. Para a autora, isso evita vazar trabalho incompleto em URLs públicas e força a avaliação sobre código real, não apenas sobre uma aparência hospedada.

O que a equipe ganhou

O time passou a se comunicar melhor com a engenharia, porque os protótipos já mostram exatamente a intenção visual e técnica, reduzindo interpretações erradas. Restrições reais do produto surgem mais cedo, quando ainda é barato corrigir. Além disso, as histórias no Jira ficam mais próximas da realidade, pois nascem de um protótipo funcional feito com componentes existentes, e não de imagens estáticas.

Playground versus código real

O texto ressalta que prototipar em cima do código não substitui tudo. Um ambiente isolado, tipo playground, segue melhor para ideias amplas, novas features ou experimentos radicais, onde não faz sentido respeitar limitações do sistema atual. Já construir no código real é mais indicado para interações menores, refinamentos e entregas que exigem alta fidelidade e handoff limpo. A recomendação final é: grandes apostas vão para playground; ajustes e melhorias concretas vão para o repositório, com main protegido e protótipos mantidos apenas como referência.