Uma nova regra de negócio, levantada pelo cliente durante a validação.
Ela virou requisito na documentação, com um registro de decisão, antes de alguém mexer no protótipo. Só depois as telas mudaram, e os desenvolvedores leram a mesma regra.
← Todos os cases Design com IA
Case · Processo de design · IA
Design com IA
movido a contexto
O Smart Line Balance é uma plataforma da Getter que ajuda fábricas a balancear suas linhas de produção. Entrei como uma das duas pessoas de design do time e, junto com o outro designer, estruturei uma forma de trabalho em que a IA constrói os protótipos, o time os valida com o cliente e os desenvolvedores recebem uma especificação que podem ler diretamente ou por meio da IA.
- Empresa
- Getter
- Meu papel
- Product Designer, uma de duas
- Ano
- 2026
- Ferramentas
- IA generativa, Figma, Git
Resultados nos dois primeiros meses
2 dias Da aprovação do cliente ao desenvolvimento
~3 h Do pedido ao primeiro protótipo navegável
4 de 7 Protótipos entregues sem reunião de handover
1 dia Do feedback dos stakeholders ao protótipo atualizado
Velocidade sem perder a consistência
Nas fábricas atendidas pelo Smart Line Balance, o engenheiro de processos balanceava a linha manualmente em uma planilha e gastava de 30 a 45 minutos no início de cada turno remanejando pessoas entre as estações de trabalho. O produto precisava substituir essa rotina por cálculo e sugestões da IA, e o time precisava validar cada fluxo com o cliente antes de qualquer linha de código.
A IA generativa tornou a produção de protótipos rápida. Gerados de forma isolada, porém, eles se afastavam uns dos outros: cada um duplicava estilos, divergia do Design System e carregava a própria cópia de regras que já estavam desatualizadas. Com duas pessoas de design e várias features em paralelo, a velocidade estava virando inconsistência.
A principal descobertaA IA é tão boa quanto o contexto que ela lê.
Em vez de prompts melhores, investimos em contexto: uma documentação única para toda a plataforma, requisitos de produto escritos para serem lidos por pessoas e pela IA, e protótipos construídos sobre partes compartilhadas do Design System.
- 01 Requisito Documentação
A página da funcionalidade define o fluxo, os requisitos testáveis, os estados e exceções e os pontos em aberto.
- 02 Protótipo IA generativa
A IA generativa lê a documentação e o Design System e constrói um protótipo navegável.
- 03 Validação P.O. e cliente
O protótipo é revisado em contexto. Toda decisão é registrada na documentação antes de o protótipo mudar.
- 04 Handover Status
Aprovado, o protótipo passa para "Em desenvolvimento" e vira a referência do time de front-end.
Decisões novas voltam para a documentação
Uma documentação que todas as áreas alimentam
Criamos um site de documentação único para toda a plataforma. Os desenvolvedores mantêm a documentação técnica e a arquitetura, o time de produto e as pessoas de design mantêm os requisitos e o Design System, e há guias para que quem não é desenvolvedor também possa contribuir. Consideramos um drive compartilhado, mas escolhemos arquivos de texto com controle de versão: toda mudança é revisada, o histórico fica guardado e o conteúdo é mais leve para a IA ler.
- Requisitos do produto Produto, usuários, glossário, regras de negócio, decisões e uma página por funcionalidade
- Design System Princípios, acessibilidade, conteúdo, tokens, componentes e padrões
- Documentação técnica Arquitetura, registros de decisão e agentes de IA
- Manual do usuário e guias Para os usuários finais e para quem contribui sem ser desenvolvedor
Anatomia de um requisito testável
Requisito: Formatos de arquivo aceitos
O sistema DEVE aceitar arquivos .xls, .xlsx e .csv no padrão de planilha definido pelo cliente.
Critério de aceite: Arquivo em formato aceito
- DADO que o usuário está no passo 1 da importação
- QUANDO o usuário envia um arquivo .xlsx no modelo do cliente
- ENTÃO o sistema lê o arquivo
- Um formato para todos
DEVE, NÃO DEVE ou PODE, com critérios de aceite em DADO / QUANDO / ENTÃO. Desenvolvedores, QA e IA leem a mesma frase da mesma forma.
- Erros não ficam para depois
Cada funcionalidade percorre um checklist de estados e exceções: entrada inválida, ausência de dados, integrações indisponíveis, conflitos, permissões e ações destrutivas.
- Proposta não é regra
O que ninguém confirmou entra como "Proposta" e ponto em aberto. Só vira requisito depois que um responsável aprova.
- Conferido automaticamente
Uma verificação automática valida a estrutura de cada página, o formato testável e os termos do glossário antes de qualquer mudança ser aceita.
Regras que escrevemos para a IA
- Ler antes de propor produto, usuários, glossário, a página da funcionalidade, regras de negócio, decisões e o Design System.
- Não inventar uma regra que falta é sinalizada como lacuna; uma suposição é declarada como suposição, nunca registrada como regra.
- Reutilizar o Design System primeiro um componente novo precisa de justificativa e da aprovação das pessoas de design.
- Acelerar, não decidir o papel da IA é acelerar a exploração de soluções, não substituir as decisões de design.
Protótipos que continuam consistentes
Os protótipos ganharam um espaço próprio. Cada um abre em qualquer navegador, mas os tokens, componentes, navegação e cabeçalho do Design System ficam em partes compartilhadas que todos os protótipos usam. Uma verificação automática aponta qualquer protótipo que divergir. Quando mudamos a escala tipográfica, todos os protótipos foram atualizados de uma só vez.
- Partes compartilhadas
Tokens, componentes e navegação em um só lugar, sincronizados e conferidos automaticamente.
- Especificação dentro do protótipo
Cada protótipo abre a própria especificação de design, com fluxo, cenários, erros e pontos em aberto, escrita para pessoas e para a IA.
- Propostas para validar
As hipóteses que o protótipo adotou aparecem em um painel, para que o P.O. saiba exatamente o que ainda precisa de decisão.
- Duas marcas, dois temas
O mesmo protótipo alterna entre a marca da Getter e a do cliente, no tema claro ou escuro.
O handover virou um status
Cada protótipo mostra sua etapa em uma barra no topo, com histórico datado e a quem procurar. Os desenvolvedores não precisam de uma reunião de handover para saber o que está pronto.
- Rascunho
Ainda em construção. Não é apresentado a stakeholders.
- Em validação
Em validação com o P.O. e stakeholders. Pode mudar.
- Pronto para dev
Aprovado pelo P.O. É a referência para implementar.
- Em desenvolvimento
O time de front-end está implementando. Mudanças só em acordo.
- Arquivado
Não é mais referência.
Histórico de um protótipo real Em validação Em desenvolvimento
Duas pessoas de design, uma base
O outro designer e eu trabalhávamos em propostas separadas sobre a mesma base, uma melhoria de cada vez. Comparávamos as alternativas lado a lado em reunião e só então a decisão entrava na documentação e no protótipo principal. Em uma das telas mais complexas, isso significou cerca de 40 propostas revisadas uma a uma.
As decisões vão primeiro para a documentação
Como todos os protótipos leem da mesma fonte, o feedback da validação altera a documentação, e os protótipos acompanham. Dois momentos das rodadas de validação mostram o ciclo.
Uma rodada de mudanças pedidas em uma reunião de revisão.
As decisões entraram na documentação e a IA reconstruiu o protótipo a partir dela. No dia seguinte havia uma nova versão para revisar, já consistente com o Design System.
O que não funcionou
- Confiar na IA sem limites: Ela alterou arquivos que não devia e relatou trabalhos que não tinha feito. Os limites dela agora estão em regras escritas.
- Protótipos gerados isoladamente: A IA duplicava estilos e se afastava do Design System. As partes compartilhadas resolveram.
- Requisitos copiados nos protótipos: Ficavam desatualizados. Agora os requisitos vivem apenas na documentação.
Principais aprendizados
A IA generativa produz protótipos consistentes quando trabalha sobre partes compartilhadas, regras escritas e uma fonte única de requisitos, e não a partir de pedidos isolados.
- A documentação é a ferramenta de design.
O tempo investido em estruturar os requisitos não foi custo extra: foi o que permitiu gerar um protótipo em horas e validá-lo em dias. Quanto melhor o contexto, menos a IA precisa adivinhar.
- Escrever para dois leitores.
Cada página é lida por pessoas e pela IA. Requisitos testáveis, um glossário que proíbe sinônimos e pontos em aberto explícitos servem aos dois, e também eliminam ambiguidades entre design, produto e engenharia.
- Manter as decisões humanas.
A IA propõe, registra suposições como suposições e nunca transforma uma sugestão em regra. Esses limites só se sustentam quando estão escritos.
- Prototipar com dados em tamanho real.
Preencher os protótipos com dados na escala real do cliente revelou problemas de layout que uma amostra pequena teria escondido, antes de qualquer código.
← Todos os cases Mais cases em breve