Time de UX
Git & Versionamento para protótipos de design
Como transformar o GitHub em um fluxo seguro de criação, revisão e handoff — versionando protótipos em front com o apoio do Claude Code.
01
Contexto
Git não é só coisa de dev. É o controle de evolução do design.
Quando o protótipo vira front, o design deixa de ser uma tela estática. Ele ganha estrutura, histórico, colaboração e entrega versionada.
Segurança
Sem quebrar a principal
O time explora variações em branches separadas, sem tocar na versão oficial do protótipo.
Rastreio
Histórico claro
Cada decisão relevante fica registrada em commits e pull requests.
Handoff
Entrega organizada
O PR vira um pacote de revisão pronto para UX, PO e devs.
Para quem vem do Figma
Você já versiona no Figma. O Git é a mesma ideia, com mais controle.
Nada aqui é totalmente novo: a maioria dos conceitos de Git tem um equivalente direto no que o time já fazia no Figma.
Histórico de versões
Commits
No Figma o histórico é automático. No Git, você escolhe o marco e dá um nome que explica a mudança.
Branch do Figma
Branch do Git
Você já criava ramificações para testar ideias sem mexer no arquivo principal. Mesma lógica, agora no front.
Compartilhar · Dev Mode
Pull Request
O link de handoff vira um PR: o que mudou, como testar e onde comentar antes de aprovar.
Salvamento automático
Commit manual
Aqui você controla o ponto de salvamento. Dá um pouco mais de trabalho, mas o histórico fica limpo e reversível.
Comentários na tela
Review no PR
Os comentários saem de cima do layout e passam a ficar ligados à mudança exata em revisão.
Arquivo principal
Branch main
O “arquivo oficial” do Figma é a sua main: a versão estável que todo mundo enxerga como verdade.
Dicionário UX
Os termos técnicos traduzidos para a linguagem de design.
main
A versão oficial, estável e aprovada do protótipo.
branch
Uma cópia segura para testar uma nova tela, ajuste ou fluxo.
commit
Salvar uma etapa importante da evolução do trabalho.
push
Enviar sua branch e seus commits para o GitHub.
PR
O pedido de revisão antes de juntar tudo na versão oficial.
merge
Juntar uma entrega já aprovada na branch principal.
Processo recomendado
Da ideia até o handoff, sem bagunçar a versão oficial.
1
Atualizar a mainGaranta que você parte sempre da última versão.2
Criar a branchSepare a nova entrega da versão oficial.3
PrototiparUse o Claude Code para criar telas e componentes.4
Commit + pushSalve a evolução e envie para o GitHub.5
PR + mergeRevise, ajuste e junte na main.git checkout main
git pull
git checkout -b feature/criacao-campanha-ia
# prototipar, testar e ajustar
git add .
git commit -m "Cria fluxo de campanha com IA"
git push -u origin feature/criacao-campanha-ia
Mão na massa
Exemplo fácil: adicionar um subtítulo na home.
O menor exemplo possível, do início ao fim — só para ver o fluxo funcionando de verdade.
Antes
Bem-vindo
Depois
Bem-vindo
Comece criando sua primeira campanha
1
Parta da versão oficial
git checkout main && git pull2
Crie uma branch para a mudança
git checkout -b design/subtitulo-home3
Adicione o subtítulo no código (editar a tela com o Claude Code)
4
Salve a mudança com um nome claro
git commit -m "Adiciona subtítulo na home"5
Envie para o GitHub
git push -u origin design/subtitulo-home6
Abra o PR, peça revisão e dê merge na main — pronto, está na versão oficial.
Cenário realista
Nova feature: criação de campanha com IA.
O projeto principal já existe. O designer nunca mexe direto na main: cria uma branch para explorar, evoluir e só depois leva o resultado para a versão oficial.
Projeto: fideliza-prototipo-campanhas
Branch: feature/criacao-campanha-ia
Destino: main
Mapa visual
mainversão oficial
featurenova jornada em evolução
mergefeature aprovada volta para a main
Como ler o fluxo
O caminho de uma mudança de design até virar versão oficial.
Toda mudança nasce numa branch (feature/, fix/ ou design/), é revisada por um PR e só então volta para a main — virando uma nova versão oficial.
Evolução da branch
A feature pode evoluir várias vezes antes de entrar na main.
Cada mudança importante vira um commit. O PR continua o mesmo e se atualiza sozinho a cada novo push.
Commit 1Cria a tela inicial da campanha com IA.
Commit 2Adiciona a seleção de produtos e os cards.
Commit 3Ajusta o layout mobile e o espaçamento.
Commit 4Altera o CTA após revisão do time.
git add .
git commit -m "Ajusta texto do CTA principal"
git push
# o PR aberto no GitHub é atualizado automaticamente
Pull Request
O PR é o espaço oficial de revisão da entrega.
feature/criacao-campanha-ia
A branch com a nova jornada: commits, ajustes e protótipo em evolução.
→
main
A branch principal: estável e pronta para handoff ou deploy.
O que o PR precisa ter
O que foi feito, como testar, observações de design, prints ou link do preview e as pendências em aberto.
Quem revisa
UX cuida da qualidade da experiência, PO valida a regra de negócio e o dev avalia a viabilidade técnica.
Template prático
Um modelo simples para padronizar o handoff.
## O que foi feito
- Criação da tela de campanha com IA
- Adição da seleção de produtos
- Ajustes mobile first
## Como testar
1. Rodar o projeto
2. Acessar o fluxo de campanhas
3. Validar seleção de produtos
4. Testar no mobile
## Observações de design
- CTA fixo no rodapé
- Cards com hierarquia visual
- Fluxo pensado para uso rápido
## Pendências
- Integração real com API
- Revisão final de textos
Anti-patterns
O que o designer não deve fazer.
Não trabalhe direto na main
×Alterar o projeto principal sem criar uma branch.
×Subir telas não testadas direto na versão oficial.
×Deixar a main instável para o resto do time.
Faça uma branch por entrega
✓Crie uma branch para cada tela, fluxo ou ajuste relevante.
✓Valide o resultado antes de abrir o PR.
✓Junte na main somente após a revisão.
Organização
Nomes ruins criam confusão. Nomes bons contam a história.
Evite
teste
alex
nova
ajuste
final
final-agora-vai
branch2
Prefira
feature/criacao-campanha-ia
design/cards-produto
fix/responsivo-mobile
experiment/nova-home
handoff/campanha-ia-v1
Commits e segurança
Não transforme o GitHub numa pasta “final_final_v3”.
Não faça commits genéricos
teste
mudanças
agora foi
ajustes
final
Faça commits claros
Cria tela de seleção de produtos
Ajusta espaçamento dos cards
Corrige responsivo mobile
Adiciona estado vazio
E nunca suba arquivos sensíveis: .env, chaves de API, tokens, senhas ou a pasta node_modules.
Política simples
6 regras para o time de UX.
1. Nunca mexa direto na main.
A main é a versão oficial do protótipo.
2. Toda entrega tem branch.
Vale para nova tela, fluxo, experimento ou correção relevante.
3. Branch com nome claro.
O nome precisa dizer qual é o objetivo da entrega.
4. O commit explica a mudança.
Nada de “teste”, “final” ou “ajustes”.
5. PR sempre com descrição.
O que foi feito, como testar e o que ainda falta.
6. Revise antes do merge.
UX, PO e dev comentam no mesmo espaço.
Mensagem final
A gente nunca mexe direto na versão oficial. Cria uma cópia, trabalha nela, mostra para o time, ajusta e só depois junta na principal.
Assim o GitHub vira uma camada de colaboração para UX: versionamento, revisão, rastreabilidade e handoff em um único fluxo.
Mais segurança
Menos retrabalho
Handoff melhor
Histórico de decisões
Resumo visual
A vida de uma feature, do início ao merge.
Feature: feature/criacao-campanha-ia
1
Sincronizar
→
git checkout main
git pull
Parte da versão oficial atualizada
2
Branch
→
git checkout -b
feature/criacao-campanha-ia
Cria a cópia segura para trabalhar
3
Commit
→
git add .
git commit -m "..."
Salva cada marco com nome claro
4
Push
→
git push -u
origin feature/...
Envia a branch para o GitHub
5
Pull Request
→
gh pr create
--base main
Abre a revisão: UX, PO e dev
6
Merge
merge do PR
→ main
Aprovado, entra na versão oficial