Meu fluxo de product design com IA sem Figma

O design de produto sem Figma funciona quando um produto já possui um sistema de design maduro. Meu fluxo de trabalho de design de produto de IA usa três habilidades de agente: ui-design explora nove direções, ui-implement transforma a direção selecionada no produto e ui-walkthrough analisa cada estado por meio do Agent Browser integrado. Eu ainda tomo as decisões; o agente cuida da produção e verificação repetitivas.

A maioria dos recursos do produto não começa em uma página em branco. Depois que um produto já existe há algum tempo, suas decisões básicas de design já existem no código. Botões, entradas, cartões, navegação, espaçamento, cores, cópia, estados de foco e comportamento móvel foram todos definidos. Reconstruir essas peças em Figma geralmente significa arrastar os mesmos componentes para outra tela antes de reconstruí-los novamente no produto.

O designer ainda toma as decisões do produto. O agente remove grande parte da montagem e verificação repetitivas. Isso funciona porque Zero já possui um sistema de design razoavelmente maduro.

1. Inicie o design do produto sem Figma com um sistema de design

Trabalhar sem Figma não significa trabalhar sem regras de design. Requer regras mais claras.

Para Zero, o agente pode inspecionar:

• Componentes existentes para botões, entradas, menus suspensos, cartões, caixas de diálogo e navegação
• Espaçamento, tipografia, cores, bordas e raios de canto estabelecidos
• Estados existentes de foco, selecionado, desativado, vazio e móvel
• Copie convenções, como maiúsculas e minúsculas e rótulos curtos voltados para o usuário
• Telas reais que mostram como essas peças são combinadas

Essas referências respondem a questões comuns de design. Uma nova entrada deve ser semelhante às entradas já enviadas. Um novo cartão deve usar a mesma superfície e raio do cartão existente mais próximo. Um botão de ícone deve ter o mesmo feedback de foco que outros botões de ícone.

Isso dá ao agente um limite. Pode explorar a estrutura de um recurso sem inventar uma nova linguagem visual para cada tela.

Figma ainda é útil quando uma equipe está criando uma nova marca, um novo sistema de componentes ou uma interação que não possui referência próxima ao produto. Mas uma vez que o sistema esteja maduro, o produto em execução pode se tornar a principal superfície de design. Esta é a versão em escala de recursos do fluxo de trabalho de design como código que usamos para reconstruir Zero.

2. Use ui-design para explorar nove direções de design de produto

Cada recurso ainda precisa ser explorado. Não quero que um agente pegue minha primeira frase e a transforme imediatamente em código.

Começo com ui-design. Dou ao agente a tela atual, o problema do usuário, o objetivo e as principais restrições. O agente lê os padrões de produtos existentes e retorna uma direção recomendada mais nove alternativas.

Em linguagem simples, a habilidade captura a tela atual, cria uma direção recomendada, explora nove alternativas distintas, apresenta as compensações e aguarda uma escolha humana.

O design thinking dentro desta instrução

Esta instrução não é apenas uma lista de regras visuais. Transforma o processo normal de um designer em uma sequência repetível:

1. Entenda antes de propor. Capture a tela atual e leia o produto ao redor antes de fazer qualquer coisa.
2. Pense em sistemas. Trate componentes existentes, páginas de modelo, padrões de interação e regras de cópia como material inicial.
3. Evite a reinvenção. A IA tende a criar um novo padrão quando o prompt é vago. A instrução diz para encontrar o componente ou página enviado mais próximo e reutilizá-lo em vez de aproximar da memória.
4. Explore antes de escolher. A âncora Depois fornece uma direção plausível. As nove variantes abrem diferentes decisões sobre layout, hierarquia, densidade, ponto de entrada e divulgação.
5. Separe a exploração do compromisso. O agente para após apresentar opções. Um ser humano compara as compensações e escolhe antes do início do código.
6. Analise toda a experiência. Cópia, feedback instantâneo, estados, comportamento móvel e consistência visual fazem parte do design, não da limpeza após a implementação.

Esse é o pensamento sistêmico que desejo da habilidade: entender o produto existente, explorar dentro dele e então fazer uma escolha explícita.

Aqui está a instrução original completa, reproduzida literalmente do fluxo de trabalho ao vivo:

Instruções originais completas do ui-design

# vm0 / Zero Regras de design de IU

## Fluxo de trabalho – recursos visuais primeiro, código depois

**Não pule para o código.** Quando essa habilidade é invocada, a primeira entrega é sempre um conjunto de modelos renderizados para Ming observar. A implementação acontece somente depois que uma direção é escolhida.

### Passo 1 — Capture o “antes”

- Se uma tela já existir, renderize seu estado atual como a imagem **antes** (capture a tela do aplicativo em execução ou renderize o componente existente como uma visualização estática).
- Se a solicitação for para uma tela totalmente nova, o "antes" será a tela existente mais próxima ou um estado em branco — deixe isso explícito na legenda.

### Passo 2 — Produza uma única âncora “depois”

- Uma maquete que representa sua melhor interpretação da solicitação, obedecendo totalmente a todas as regras abaixo (componentes, caixa de frase, entradas/dropdowns de detalhes do agente, raios do cartão do compositor de bate-papo, botão de adição de agendamento, movimentos do IconButton, superfícies cinza-50).
- Combine-o com o **antes** lado a lado. Rotule-os claramente: `Before` / `After`.

### Passo 3 — Gere 9 explorações de variantes

Após o par antes/depois, produza **9 modelos de variantes distintas** para a mesma tela. Cada variante deve explorar um eixo de design significativamente diferente – e não 9 ajustes de cores. Cubra uma propagação como:

1. Layout – coluna única vs. divisão/barra lateral/grade
2. Densidade – compacto vs. espaçoso
3. Hierarquia – qual elemento lidera visualmente
4. Tratamento de superfície — seções planas vs. agrupadas em cartões vs. seções divididas
5. Ponto de entrada – ação inline vs. CTA dedicado vs. herói em estado vazio
6. Enquadramento da cópia - instrutivo x mínimo x coloquial
7. Divulgação - tudo visível vs. revelação progressiva / acordeões
8. Composição - liderada pelo conteúdo vs. liderada pelo controle
9. Uma direção deliberadamente não convencional/curinga que vale a pena ver uma vez

Cada variante ainda deve respeitar os não negociáveis ​​(maiúsculas e minúsculas da frase, componentes de reutilização, estilo suspenso/entrada de detalhes do agente, raios do compositor de bate-papo, botão de adição de agendamento, foco do IconButton, tons neutros cinza-50). As variantes exploram *layout e ênfase*, não "e se ignorássemos o sistema de design".

### Passo 4 — Apresente e espere

- Mostre todas as imagens para Ming em uma mensagem: primeiro o par `Before / After`, depois as 9 variantes numeradas de 1 a 9 com uma legenda de uma linha, cada uma descrevendo o eixo que está sendo explorado.
- Pergunte qual direção (ou qual combinação) seguir.
- Não comece a implementação até que Ming escolha uma direção.

### Renderizando as imagens

- Caminho preferido: crie visualizações estáticas de HTML/React que usam tokens Tailwind reais de `turbo/apps/platform`, capture-os e carregue-os via `okou web upload-file`.
- Para exploração rápida: a habilidade `v0` pode gerar modelos variantes a partir de um prompt — mas o prompt deve enumerar explicitamente as regras abaixo (maiúsculas e minúsculas da frase, entradas de detalhes do agente, raio do compositor de chat, etc.) para que v0 não produza UI SaaS genérica.
- Se a geração de imagens não estiver disponível para a sessão, volte para wireframes ASCII/textuais claramente rotulados para todos os 11 quadros (antes, depois, 9 variantes) e diga isso - nunca pule silenciosamente a etapa visual.

---

# Regras de projeto

Estas são as convenções de design não negociáveis ​​para qualquer nova UI enviada dentro da plataforma vm0 (`turbo/apps/platform`). Aplique-os antes de escrever os componentes e audite os PRs existentes durante a revisão.

## Princípios fundamentais

1. **Reutilize, não reinvente.** Sempre verifique os primitivos existentes em `turbo/apps/platform/src/components/` e os padrões de nível de visualização em `src/views/` antes de introduzir um novo componente. Se uma interação semelhante já for fornecida nos detalhes do agente, na programação ou no compositor do chat, copie esse padrão em vez de criar um paralelo.
2. **Corresponde à linguagem de design Zero.** Superfícies suaves, cinzas neutros, raios generosos, bordas sutis, sem sombras fortes. A linha de base visual é “calma, opinativa, ligeiramente editorial” – nunca padrão SaaS.
3. **Fale do lugar do usuário.** A cópia deve descrever o que *eles* estão prestes a fazer ou ver, não o que o sistema está fazendo. Seja breve – geralmente uma única frase, no máximo duas.

## Padrões de referência (copie-os diretamente)

| Elemento             | Fonte de referência                                  | Por que |
|---------------------|---------------------------------------------------|-----|
| Entrada de texto/área de texto | Entrada da página de detalhes do agente (`src/views/agent-detail/`) | Preenchimento estabelecido, borda, estado de foco, tratamento de espaço reservado |
| Menu suspenso/selecionar     | Menu suspenso da página de detalhes do agente                         | Estilo de gatilho estabelecido, raio do menu, foco do item, posicionamento da marca de seleção |
| Raio do cartão/painel   | Cartão do compositor de bate-papo (procure os componentes `composer`) | Define o raio canônico do cartão e o estilo da superfície no aplicativo |
| Botão da página principal   | Botão "Adicionar agendamento" na página de agendamento          | O primário neutro-escuro usado em todos os lugares *fora* dos modais |
| Botão principal modal  | A cor primária da marca (apenas dentro de caixas de diálogo/popovers) | Os modais mantêm a cor primária da marca; páginas não |
| Botão apenas de ícone      | IconButton existente com fundo flutuante           | Cada ícone clicável deve ter um estado de foco visível |

Em caso de dúvida, abra o componente de referência na base de código, leia seus adereços e nomes de classe e espelhe-os. Não faça aproximações de memória.

## Diretrizes de texto

- **Frases da perspectiva do usuário.** "Conectar sua caixa de entrada" é melhor do que "Conexão com a caixa de entrada necessária". “Nenhum agente ainda” é melhor do que “A lista de agentes está vazia”.
- **Brevidade acima da integridade.** Uma linha curta supera uma frase completa. Preenchimento de acabamento ("simplesmente", "por favor", "para").
- **Caixa de frase para tudo.** Rótulos, cabeçalhos, botões, itens de menu, colunas de tabela — todas as frases ("Fornecedores de modelo", "Chaves de API", "Adicionar programação"). Nunca caso de título. Nunca `uppercase` via CSS nos cabeçalhos das seções. Se você encontrar um rótulo Title-Case ou all-caps, corrija-o.
- **Sem rótulos "decorativos" de legenda** acima dos campos ou seções - eles são lidos como forma e datados. Use um rótulo normal ou ignore o rótulo se o campo for evidente.
- **Sem pontuação final** em rótulos ou botões independentes. Os pontos são para texto do corpo e texto auxiliar.
- Ao renomear uma string, use grep na base de código da string antiga e teste-a — os rótulos são referenciados em testes e traduções.

## Componentes e estrutura

- Sempre crie páginas a partir de componentes existentes (`Button`, `Input`, `Select`, `Card`, `IconButton`, primitivas de diálogo, etc.). Novos componentes são o último recurso e exigem um motivo.
- Procure um layout/modelo existente (página de configurações, página de lista, página de detalhes) e herde seu andaime. Não deriva novamente a estrutura da página.
- Ao adicionar a uma página de estilo de configurações, combine o espaçamento da seção, o tratamento do divisor e a largura da linha do formulário usado pelas seções vizinhas.

## Botões

- **Página principal** (o CTA principal em uma página) → corresponda ao botão "Adicionar programação" na página de programação. Este é o diálogo externo neutro escuro/sólido primário usado em todo o aplicativo.
- **Modal primário** (o botão de confirmação dentro de caixas de diálogo/popovers) → usa a cor primária da marca. As páginas não.
- **Botões secundários/fantasma** → reaproveitar as variantes existentes; não invente novos.
- **Botões de ícone** → devem ter um fundo de foco (normalmente `hover:bg-gray-50` ou o token de foco IconButton estabelecido). Nunca envie um ícone vazio sem foco como alvo de clique.
- Todos os botões devem respeitar os tokens de altura existentes — não introduza tamanhos únicos.

## Campos de entrada

- Espelhe a entrada de detalhes do agente: mesmo preenchimento, mesma borda, mesmo anel de foco (ou falta dele — verifique a referência antes de adicionar um anel de foco), mesma cor do espaço reservado.
- Multilinha: use o padrão de área de texto de detalhes do agente (crescimento automático ou linhas fixas como na referência).
- Não coloque dois pontos no final dos rótulos dos campos.
- Texto auxiliar abaixo da entrada, em cinza suave, linha única.

## Menus suspensos/seleções

- Espelhe o menu suspenso de detalhes do agente: mesma aparência do gatilho, mesmo raio de menu, mesmo preenchimento de item, mesmos estados de foco/selecionados.
- O menu não deve ser mais largo que o seu gatilho, a menos que o conteúdo assim o exija.
- Evite submenus aninhados, a menos que um menu suspenso existente já os utilize.

## Cartões e superfícies

- O raio do cartão e o estilo da superfície correspondem ao cartão do compositor de bate-papo. Não introduza um raio menor ou maior sem motivo.
- As bordas são sutis (linha fina única no token de borda existente). Não há sombras projetadas, a menos que o compositor do bate-papo use uma.
- Superfícies neutras em preenchimentos móveis/cinza claro (fundos de comprimidos ativos, preenchimentos de contêineres de ícones, etc.) → `bg-gray-50`. `gray-100` e `gray-200` foram repetidamente chamados de muito escuros – comece em `gray-50`.

## Foco e interação

- Não adicione sombras de caixa ou contornos `:focus-visible` personalizados aos elementos de navegação/marketing - em vez disso, reutilize a mudança de cor instantânea. (A mesma restrição geralmente se aplica dentro da plataforma, a menos que um componente de referência tenha um anel de foco explícito.)
- Cada elemento interativo (botão, botão de ícone, linha, link) precisa de um estado de foco visível. Teste passando o mouse sobre cada um deles antes de considerar o projeto concluído.
- Os estados desabilitados usam os tokens desabilitados existentes; não role manualmente uma cor desbotada.

## Lista de verificação de revisão

Antes de declarar uma UI pronta, siga estes passos:

1. Reutilizei componentes existentes em vez de construir novos?
2. Combinei um modelo/layout de página existente?
3. As entradas são visualmente idênticas às entradas de detalhes do agente?
4. Os menus suspensos são visualmente idênticos aos menus suspensos de detalhes do agente?
5. Os cartões correspondem ao raio e à superfície do compositor do chat?
6. Cada frase do rótulo é maiúscula? Algum caso de título restante ou letras maiúsculas?
7. A cópia é curta e escrita no assento do usuário?
8. A página principal é o botão estilo "Adicionar programação"? A marca primária é usada apenas dentro dos modais?
9. Cada botão de ícone tem um fundo flutuante?
10. Passei o mouse sobre cada elemento interativo para confirmar o feedback?

Se alguma resposta for “não”, corrija antes de abrir o PR.

## Em caso de dúvida

- Abra o componente de referência, leia sua fonte e copie a estrutura.
- Se dois componentes de referência discordarem, prefira o enviado mais recentemente (verifique o git log).
- Se o projeto realmente precisa de um novo primitivo, levante-o com Ming antes de construí-lo - o trabalho de redesenho agrupado pertence a um PR com ele como revisor.

As nove opções não precisam ser nove designs finalizados. O trabalho deles é me dar amplitude suficiente para ver o problema de maneira diferente e seguir na direção certa. Se um conceito estiver fora do produto atual, um protótipo React autônomo ainda poderá ajudar. Para esse recurso, fiquei dentro do sistema real do produto.

Um exemplo real: navegação de Zero

Zero originalmente tinha uma barra lateral de 300 pixels contendo destinos de produtos, agentes fixados e tópicos de bate-papo. Ele estava fazendo três trabalhos ao mesmo tempo. Queria separar esses trabalhos sem mudar a área de conversação.

O resumo do produto para a exploração foi:

/ui-design

Repita a fase de design da navegação de três regiões do Zero a partir da base histórica real. Separe destinos de produtos, agentes e conversas em regiões mais claras sem alterar a área de conversa. Use tokens, ícones e componentes Zero reais. Produza um Antes fiel à fonte, um Depois forte e nove variantes genuinamente diferentes. Não edite o código do produto nem apresente um modelo como evidência do navegador.

A primeira exploração foi muito cautelosa. Várias opções mudaram de largura e estilos de seleção, mas ainda pareciam a mesma barra lateral. Rejeitei esse conjunto e pedi ao agente que tornasse visíveis as diferenças no nível da arquitetura da informação.

A segunda corrida retornou nove direções genuinamente diferentes. Agrupei-os em uma tabela 3 × 3 para que sejam fáceis de comparar sem transformar o artigo em uma longa faixa de imagens. Cada miniatura é aberta no visualizador de imagens do blog.

1. Navegação superior	2. Gaveta dobrável	**3. Tópico primeiro **
Mova os destinos acima da conversa	Ocultar destinos até que seja necessário	Faça das conversas o principal objeto de navegação
4. Agente primeiro	**5. Conversa primeiro **	6. Lançador de comandos
Escolha um agente antes de seus tópicos	Coloque agentes fixados acima da conversa ativa	Abra destinos em um menu pesquisável
7. Trilho expansível	8. Entrada no painel	9. Doca inferior
Expanda um trilho estreito somente quando necessário	Comece com um trabalho recente	Mover destinos para baixo

Não escolhi uma dessas molduras exatamente como desenhada. Usei-os para decidir o que deveria permanecer e o que deveria mudar. A direção final usou uma barra de destino estreita, uma barra de bate-papo separada, cinco agentes fixados visíveis e a área de conversação existente.

O resultado importante de ui-design não foi apenas a imagem. Foi um registro de decisão curto:

• Mantenha um trilho de destino de 68 pixels e um trilho de bate-papo de 300 pixels
• Mostrar cinco slots de agente fixado
• Mantenha a seleção silenciosa, mas legível
• Mostrar orientação para reordenar apenas ao arrastar
• Manter a conversa e a gaveta móvel existente inalteradas

Isso foi suficiente para iniciar a implementação.

3. Use ui-implement para transformar o design selecionado em código

Depois de escolher uma direção e conectar a base de código do produto, o agente trabalha diretamente no código. Não redesenhei primeiro o quadro selecionado em Figma.

Em linguagem simples, ui-implement ignora a exploração porque a direção já foi escolhida. Ele encontra os componentes reais e a estrutura da página mais próximos, constrói com eles, audita o resultado e verifica o recurso em um navegador.

O que esta instrução protege

• A direção escolhida não deve ser redesenhada durante a implementação.
• O agente deve começar com o componente e a página de modelo existentes mais próximos.
• A reutilização vence um novo componente, a menos que o produto tenha uma lacuna real.
• A autoauditoria e a verificação do navegador detectam cópias, estados e interações inconsistentes.
• Se uma decisão de produto ainda não for resolvida, o trabalho retornará para ui-design.

É assim que o sistema de design permanece ativo durante a implementação. Não é um documento que o agente lê uma vez. Ele molda quais componentes escolhe e como verifica a experiência final.

Aqui está a instrução original completa, reproduzida literalmente do fluxo de trabalho ao vivo:

Instruções originais completas do ui-implement

# Regras de implementação da interface do usuário vm0 / Zero

## Fluxo de trabalho – implemente diretamente

Quando esta habilidade for invocada, **pule a fase de maquete e exploração de variantes**. Comece a implementar em `turbo/apps/platform` imediatamente, aplicando todas as regras de design abaixo.

### Passo 1 — Localize os componentes de referência

Antes de escrever uma linha, abra os componentes de referência que você irá espelhar:

- Entrada / área de texto → entrada `src/views/agent-detail/`
- Menu suspenso / selecione → menu suspenso `src/views/agent-detail/`
- Raio do cartão/painel → cartão do compositor de bate-papo
- Botão principal da página → botão "Adicionar agendamento" na página de agendamento
- Botão apenas de ícone → `IconButton` existente com fundo flutuante

Leia seus adereços e nomes de classe. Espelhe-os – não faça aproximações de memória.

### Passo 2 — Encontre o modelo de página existente mais próximo

Abra a página existente mais próxima da mesma forma (configurações, lista, detalhe) e herde sua estrutura: espaçamento de seção, tratamento de divisor, largura de linha de formulário. Não deriva novamente a estrutura da página.

### Etapa 3 – Construir e depois autoauditar

Implemente a tela com primitivas existentes de `turbo/apps/platform/src/components/`. Quando você achar que está pronto, siga a **Lista de verificação de revisão** na parte inferior desta habilidade antes de reportar. Corrija todas as respostas “não” antes de declarar o trabalho concluído.

### Passo 4 — Verifique no navegador

Para qualquer trabalho de UI, inicie o servidor de desenvolvimento e exercite o recurso em um navegador antes de relatar a tarefa como concluída. Passe o mouse sobre cada elemento interativo, teste o caminho dourado e os casos extremos e observe as regressões nas telas vizinhas. A verificação de tipo e os testes verificam o código, não a correção dos recursos - se você não conseguir abrir o navegador, diga isso explicitamente.

### Quando voltar para ui-design

Se a solicitação for aberta ("criar uma página de configurações para X") sem direção escolhida, pare e execute a habilidade `ui-design` — as variantes antes/depois + 9 existem exatamente para esse caso. `ui-implement` é para quando a direção já está decidida.

---

# Regras de projeto

Estas são as convenções de design não negociáveis ​​para qualquer nova UI enviada dentro da plataforma vm0 (`turbo/apps/platform`). Aplique-os durante a construção e audite suas próprias diferenças antes de abrir o PR.

## Princípios fundamentais

1. **Reutilize, não reinvente.** Sempre verifique os primitivos existentes em `turbo/apps/platform/src/components/` e os padrões de nível de visualização em `src/views/` antes de introduzir um novo componente. Se uma interação semelhante já for fornecida nos detalhes do agente, na programação ou no compositor do chat, copie esse padrão em vez de criar um paralelo.
2. **Corresponde à linguagem de design Zero.** Superfícies suaves, tons de cinza neutros, raios generosos, bordas sutis, sem sombras fortes. A linha de base visual é “calma, opinativa, ligeiramente editorial” – nunca padrão SaaS.
3. **Fale do lugar do usuário.** A cópia deve descrever o que *eles* estão prestes a fazer ou ver, não o que o sistema está fazendo. Seja breve – geralmente uma única frase, no máximo duas.

## Padrões de referência (copie-os diretamente)

| Elemento             | Fonte de referência                                  | Por que |
|---------------------|---------------------------------------------------|-----|
| Entrada de texto/área de texto | Entrada da página de detalhes do agente (`src/views/agent-detail/`) | Preenchimento estabelecido, borda, estado de foco, tratamento de espaço reservado |
| Menu suspenso/selecionar     | Menu suspenso da página de detalhes do agente                         | Estilo de gatilho estabelecido, raio do menu, foco do item, posicionamento da marca de seleção |
| Raio do cartão/painel   | Cartão do compositor de bate-papo (procure os componentes `composer`) | Define o raio canônico do cartão e o estilo da superfície no aplicativo |
| Botão da página principal   | Botão "Adicionar agendamento" na página de agendamento          | O primário neutro-escuro usado em todos os lugares *fora* dos modais |
| Botão principal modal  | A cor primária da marca (apenas dentro de caixas de diálogo/popovers) | Os modais mantêm a cor primária da marca; páginas não |
| Botão apenas de ícone      | IconButton existente com fundo flutuante           | Cada ícone clicável deve ter um estado de foco visível |

Em caso de dúvida, abra o componente de referência na base de código, leia seus adereços e nomes de classe e espelhe-os. Não faça aproximações de memória.

## Diretrizes de texto

- **Frases da perspectiva do usuário.** "Conectar sua caixa de entrada" é melhor do que "Conexão com a caixa de entrada necessária". “Nenhum agente ainda” é melhor do que “A lista de agentes está vazia”.
- **Brevidade acima da integridade.** Uma linha curta supera uma frase completa. Preenchimento de acabamento ("simplesmente", "por favor", "para").
- **Caixa de frase para tudo.** Rótulos, cabeçalhos, botões, itens de menu, colunas de tabela — todas as frases ("Fornecedores de modelo", "Chaves de API", "Adicionar programação"). Nunca caso de título. Nunca `uppercase` via CSS nos cabeçalhos das seções. Se você encontrar um rótulo Title-Case ou all-caps, corrija-o.
- **Sem rótulos "decorativos" de legenda** acima dos campos ou seções - eles são lidos como forma e datados. Use um rótulo normal ou ignore o rótulo se o campo for evidente.
- **Sem pontuação final** em rótulos ou botões independentes. Os pontos são para texto do corpo e texto auxiliar.
- Ao renomear uma string, use grep na base de código da string antiga e teste-a — os rótulos são referenciados em testes e traduções.

## Componentes e estrutura

- Sempre crie páginas a partir de componentes existentes (`Button`, `Input`, `Select`, `Card`, `IconButton`, primitivas de diálogo, etc.). Novos componentes são o último recurso e exigem um motivo.
- Procure um layout/modelo existente (página de configurações, página de lista, página de detalhes) e herde seu andaime. Não deriva novamente a estrutura da página.
- Ao adicionar a uma página de estilo de configurações, combine o espaçamento da seção, o tratamento do divisor e a largura da linha do formulário usado pelas seções vizinhas.

## Botões

- **Página principal** (o CTA principal em uma página) → corresponda ao botão "Adicionar programação" na página de programação. Este é o diálogo externo neutro escuro/sólido primário usado em todo o aplicativo.
- **Modal primário** (o botão de confirmação dentro de caixas de diálogo/popovers) → usa a cor primária da marca. As páginas não.
- **Botões secundários/fantasma** → reaproveitar as variantes existentes; não invente novos.
- **Botões de ícone** → devem ter um fundo de foco (normalmente `hover:bg-gray-50` ou o token de foco IconButton estabelecido). Nunca envie um ícone vazio sem foco como alvo de clique.
- Todos os botões devem respeitar os tokens de altura existentes — não introduza tamanhos únicos.

## Campos de entrada

- Espelhe a entrada de detalhes do agente: mesmo preenchimento, mesma borda, mesmo anel de foco (ou falta dele — verifique a referência antes de adicionar um anel de foco), mesma cor do espaço reservado.
- Multilinha: use o padrão de área de texto de detalhes do agente (crescimento automático ou linhas fixas como na referência).
- Não coloque dois pontos no final dos rótulos dos campos.
- Texto auxiliar abaixo da entrada, em cinza suave, linha única.

## Menus suspensos/seleções

- Espelhe o menu suspenso de detalhes do agente: mesma aparência do gatilho, mesmo raio de menu, mesmo preenchimento de item, mesmos estados de foco/selecionados.
- O menu não deve ser mais largo que o seu gatilho, a menos que o conteúdo assim o exija.
- Evite submenus aninhados, a menos que um menu suspenso existente já os utilize.

## Cartões e superfícies

- O raio do cartão e o estilo da superfície correspondem ao cartão do compositor de bate-papo. Não introduza um raio menor ou maior sem motivo.
- As bordas são sutis (linha fina única no token de borda existente). Não há sombras projetadas, a menos que o compositor do bate-papo use uma.
- Superfícies neutras em preenchimentos móveis/cinza claro (fundos de comprimidos ativos, preenchimentos de contêineres de ícones, etc.) → `bg-gray-50`. `gray-100` e `gray-200` foram repetidamente chamados de muito escuros – comece em `gray-50`.

## Foco e interação

- Não adicione sombras de caixa ou contornos `:focus-visible` personalizados aos elementos de navegação/marketing - em vez disso, reutilize a mudança de cor instantânea. (A mesma restrição geralmente se aplica dentro da plataforma, a menos que um componente de referência tenha um anel de foco explícito.)
- Cada elemento interativo (botão, botão de ícone, linha, link) precisa de um estado de foco visível. Teste passando o mouse sobre cada um deles antes de considerar o projeto concluído.
- Os estados desabilitados usam os tokens desabilitados existentes; não role manualmente uma cor desbotada.

## Lista de verificação de revisão

Antes de declarar uma UI pronta, siga estes passos:

1. Reutilizei componentes existentes em vez de construir novos?
2. Combinei um modelo/layout de página existente?
3. As entradas são visualmente idênticas às entradas de detalhes do agente?
4. Os menus suspensos são visualmente idênticos aos menus suspensos de detalhes do agente?
5. Os cartões correspondem ao raio e à superfície do compositor do chat?
6. Cada frase do rótulo é maiúscula? Algum caso de título restante ou letras maiúsculas?
7. A cópia é curta e escrita no assento do usuário?
8. A página principal é o botão estilo "Adicionar programação"? A marca primária é usada apenas dentro dos modais?
9. Cada botão de ícone tem um fundo flutuante?
10. Passei o mouse sobre cada elemento interativo em um navegador para confirmar o feedback?

Se alguma resposta for “não”, corrija antes de abrir o PR.

## Em caso de dúvida

- Abra o componente de referência, leia sua fonte e copie a estrutura.
- Se dois componentes de referência discordarem, prefira o enviado mais recentemente (verifique o git log).
- Se o projeto realmente precisa de um novo primitivo, levante-o com Ming antes de construí-lo - o trabalho de redesenho agrupado pertence a um PR com ele como revisor.

Este foi o prompt de implementação específico do recurso:

/ui-implement

Comece pela revisão 04d642bb. Adicione uma divisão de área de trabalho padrão com um trilho de destino de 68px, um trilho de bate-papo de 300px e a conversa inalterada. Mantenha a antiga barra lateral de 300px quando o botão estiver desligado e ligado no celular. Renderize cinco slots fixados, preserve a ordem definida pelo usuário e mostre as possibilidades de reordenação somente durante um arrasto ativo. Não inspecione o recurso histórico ou refinamentos posteriores até que o patch independente, os testes e as evidências do navegador sejam congelados.

Para o recurso de navegação, pedi ao agente que mantivesse a barra lateral antiga quando o recurso estivesse desativado, mostrasse o novo layout de três partes quando estivesse ativado, mantivesse a gaveta móvel existente e permitisse que as pessoas reordenassem os agentes fixados.

Durante a implementação, o agente encontrou um problema importante. O produto antigo lembrava quais agentes estavam fixados, mas não lembrava o pedido deles. Uma interação de arrastar pode parecer correta e ser redefinida após uma atualização.

Portanto, o agente fez mais do que desenhar o estado de arrastar. Fez com que o novo pedido persistisse, atualizou a página e verificou se o pedido permaneceu. Ele também confirmou que as alças de reordenação apareciam apenas durante o arrasto e desapareciam depois.

A entrega da implementação mostrou os dois estados da área de trabalho que eu precisava revisar. Eu os mostro em largura total para que a interface permaneça legível. O comportamento móvel aparece posteriormente no passo a passo como uma captura de telefone de alta densidade.

Estado de repouso da área de trabalho

Reordenação ativa

Neste ponto eu tinha um recurso funcional, não outro arquivo de design. Mas a implementação ainda não era o fim. Eu precisava ver o que realmente estava sendo executado na visualização implantada.

4. Use ui-walkthrough para avaliar o produto real

As orientações sobre os produtos costumavam ser tediosas. Eu abriria uma visualização implantada, prepararia a conta correta, ativaria e desativaria recursos, clicaria em cada controle, redimensionaria o navegador, faria capturas de tela e tentaria lembrar qual estado cada imagem representava.

O agente possui um Agent Browser integrado, então posso entregar esse trabalho a ele.

O fluxo de trabalho tem duas etapas principais:

1. Liste os cenários primeiro. O agente transforma as declarações de design e implementação em uma lista de verificação.
2. Execute a lista de verificação e anexe evidências. Ele executa todos os cenários na visualização implementada e retorna PASS, FAIL ou BLOCKED com uma captura de tela para cada estado significativo.

O que esta instrução muda na revisão

• O agente lista os cenários antes de começar a clicar.
• Ele usa o componente real implantado por meio de seu Agent Browser integrado.
• Ele captura uma captura de tela para cada estado significativo.
• Ele marca cada ponto de verificação PASS, FAIL ou BLOCKED.
• Nunca esconde um estado indisponível por trás de evidências falsas.

Isso transforma o clique manual em um pacote de revisão organizado. Posso analisar o comportamento pretendido, o resultado e as evidências juntos.

A instrução completa está abaixo. Traduzi o nome da dependência interna para “Agent Browser integrado” para maior clareza ao leitor; a lógica do fluxo de trabalho permanece inalterada.

Instruções originais completas do ui-walkthrough

# Passo a passo da IU

Controle de qualidade visual completo de um recurso front-end vm0/Zero em sua visualização real por PR. Este fluxo de trabalho define o que verificar e como reportar o resultado; ele não define ferramentas de operação de UI.

## Dependência necessária: Agent Browser integrado

Use o Agent Browser integrado como a única fonte de verdade para cada interação da IU, incluindo:

- Descobrindo e abrindo a visualização por PR.
- Tratamento de proteção de visualização e configuração de sessão.
- Inscrição, OTP, integração, check-out de teste Stripe e acesso ao aplicativo ao vivo.
- Habilitando opções de recursos.
- Navegar, interagir com controles, fornecer dados de teste ou simulados, capturar capturas de tela, fazer upload de artefatos, solucionar problemas e limpar.

Leia e siga as instruções Agent Browser integradas atuais antes de realizar qualquer ação na interface do usuário. Não duplique comandos específicos de tempo de execução, configuração de mecanismo, mecânica de seletor, scripts de contexto de página, gerenciamento de sessão ou métodos de limpeza de processo neste fluxo de trabalho. Se o Agent Browser integrado for alterado, suas instruções atuais terão precedência.

## Quando usar

- Percorra a IU de uma solicitação pull vm0 em sua visualização implantada.
- Verifique um recurso no aplicativo que requer autenticação, integração, cobrança, troca de recursos ou uma conversa de bate-papo real.
- Capture capturas de tela fiéis ou um breve vídeo passo a passo do recurso funcionando no aplicativo ao vivo.

## Fluxo de trabalho passo a passo

### 1. Estabeleça a meta e o escopo

- Identifique o PR, o commit principal, a alteração do comportamento visível ao usuário e a visualização esperada.
- Confirme se a visualização implantada corresponde ao chefe de RP antes de testar.
- Leia a diferença e a descrição do PR para derivar o caminho crítico e os estados que demonstram a mudança.
- Não corrija código, resolva conflitos ou altere o comportamento do produto durante uma demonstração, a menos que o usuário solicite a implementação separadamente.

### 2. Alcance o recurso

Use o Agent Browser integrado para entrar na visualização e atingir o estado do recurso ao vivo. Siga as regras atuais para autenticação, integração, cobrança, troca de recursos e desvios somente de visualização.

Se for utilizado um bypass, divulgue-o no relatório final. Nunca use um desvio de integração quando a integração estiver em teste.

### 3. Defina a matriz de estado visual

Antes de interagir, liste o menor conjunto de estados que prova que o recurso funciona. Inclua os itens aplicáveis:

- Estado inicial/padrão.
- Estado aberto, pairar, focar, selecionado, expandido ou ativo.
- Estados vazios e povoados.
- Estados habilitados e desabilitados.
- Estados de sucesso, validação, carregamento e erro.
- Posicionamento, colisão, inversão, recorte e comportamento responsivo.
- Envio ou ação downstream quando o recurso é interativo.

Prefira exercitar o comportamento real alterado em vez de um teste de fumaça genérico.

### 4. Conduza o componente ativo

Use o Agent Browser integrado para todas as técnicas de interação e dados de teste.

Conteúdo simulado ou injetado pode ser usado apenas para colocar um componente real do aplicativo em um estado visual determinístico. O componente, o estilo e a interação que estão sendo avaliados devem permanecer a implementação ativa da visualização do PR.

Para cada estado simulado:

- Registre qual conteúdo ou pré-requisito foi ridicularizado.
- Distinguir o conteúdo simulado do comportamento real do aplicativo.
- Nunca insinue que o texto ou os dados simulados vieram de um modelo ou fonte de produção.
- Exerça os controles reais e a fiação a jusante sempre que o ambiente permitir.

### 5. Capture evidências

Use o Agent Browser integrado para capturar e fazer upload de evidências para os principais pontos de verificação. Cada imagem deve provar um estado significativo em vez de repetir a mesma visão.

Se o usuário solicitar um vídeo, monte um breve passo a passo legendado a partir dos pontos de verificação verificados. As legendas devem identificar a ação do usuário e o resultado esperado sem obscurecer a IU.

### 6. Entregue e reporte

Relatório:

- Link PR, URL de visualização exato e commit testado quando disponível.
- Fluxo exato do usuário exercido.
- Conta de teste quando uma foi criada.
- `PASS`, `FAIL` ou `BLOCKED` para cada ponto de verificação.
- Links para captura de tela e um link de vídeo opcional com breves descrições.
- Chaves de recursos, desvios, dados simulados e outras configurações somente de teste usadas.
- Verificações falhadas, bloqueadores de ambiente ou lacunas de verificação.

Não afirme que o recurso foi verificado, a menos que o fluxo de visualização ao vivo tenha sido exercido e as evidências tenham sido capturadas. Se a visualização não estiver disponível, relate `BLOCKED` com a evidência de implantação em vez de substituir uma réplica local ou estática.

Este foi o prompt passo a passo específico do recurso:

/ui-walkthrough

Use a visualização implantada por meio do Agent Browser integrado como a única verdade do navegador. Prove a barra lateral desativada, a divisão de 68px e 300px, ordem de destino, estados de foco, cinco slots fixados, alças somente para arrastar, reordenação persistente, seleção de thread, rolagem e a gaveta completa do iPhone. Retorne PASS, FAIL ou BLOCKED para cada ponto de verificação. Não substitua um estado inacessível por uma réplica.

Para esse recurso, o agente organizou o passo a passo em torno destas questões:

• A barra lateral antiga ainda funciona quando o recurso está desativado?
• A nova estrutura da área de trabalho aparece quando está ativada?
• O foco e os estados selecionados estão visíveis, mas silenciosos?
• Cinco agentes fixados são legíveis?
• Os controles de reordenação permanecem ocultos até que um arrasto comece?
• A nova ordem sobrevive a uma atualização?
• Posso selecionar e percorrer tópicos reais?
• A gaveta móvel existente ainda funciona?
• Todos os destinos de navegação estão presentes e na ordem correta?

O agente então abriu a visualização implantada como um novo usuário, concluiu a integração, ativou o recurso e trabalhou na lista. Ele testou o estado de repouso, estado de foco, estado de arrastar, comportamento de atualização, seleção de thread, rolagem e layout do telefone.

O resultado foi 11 PASS, 1 FAIL.

A falha foi útil. O layout e as interações funcionaram, mas a visualização implantada mostrou apenas seis destinos de produtos. Activity e Insights estavam faltando e o pedido não correspondia ao design selecionado.

Cenário	Resultado
Barra lateral antiga com o recurso desativado	PASS
Novo layout de área de trabalho em três partes	PASS
Passe o mouse e estados selecionados	PASS
Cinco agentes fixados	PASS
Orientação para reordenar somente arrastar	PASS
Pedido salvo após atualização	PASS
Seleção e rolagem de thread	PASS
Gaveta móvel existente	PASS
Conteúdo e ordem do destino	FAIL

A entrega final foi um conjunto organizado de capturas de tela, em vez de uma pasta de imagens sem rótulos. As capturas da área de trabalho têm 1440 × 900 pixels e a captura do telefone tem 1170 × 2532 pixels. Eles aparecem um de cada vez abaixo para que a interface permaneça legível; clique em qualquer imagem para ampliá-la sem sair do artigo.

Recurso desativado

Recurso ativado

Layout da área de trabalho

Passar o mouse sobre o destino

Foco do agente fixado

Arrastar ativo

Pedido salvo

Gaveta móvel

Isso me permite revisar um recurso de forma estruturada. Posso ver os cenários pretendidos, o resultado real implantado e as evidências juntas. Se algo falhar, sei exatamente para onde o trabalho deve retornar.

Como uma equipe adota esse fluxo de trabalho de design de produto de IA

O processo completo é curto. Os colegas de equipe podem salvar cada estágio como fluxo de trabalho Zero compartilhado em vez de reconstruir o processo a partir da memória.

Estágio	Entrada	Saída
ui-design	Tela atual, problema, objetivo e restrições	Uma direção recomendada, nove alternativas e um registro de projeto selecionado
ui-implement	O registro de projeto selecionado	Uma alteração de código revisável e capturas de tela dos principais estados
ui-walkthrough	O recurso implantado e seu comportamento esperado	Uma lista de cenários organizada com capturas de tela PASS, FAIL ou BLOCKED

Um colega de equipe não precisa reproduzir meu gosto por design. Eles precisam fornecer um bom contexto, usar o sistema de produto compartilhado, fazer uma escolha explícita após a exploração e revisar as evidências do navegador. Os mesmos três pontos de verificação humanos – problema, direção e aceitação – também moldam a forma como gerencie agentes de IA como uma equipe.

Este fluxo de trabalho não elimina a prática de design ou o design thinking. Isso os move para as partes onde são mais importantes: definir o problema, definir restrições, comparar direções, escolher compensações e julgar o produto em execução.

Quando o sistema de componentes estiver maduro, não precisarei mais reconstruir todos os recursos como blocos arrastáveis ​​em Figma. Posso trabalhar com o agente diretamente no produto, enquanto o sistema de design mantém a saída consistente e o passo a passo mantém o resultado honesto.

Perguntas frequentes

Como você constrói um fluxo de trabalho de design de produto de IA?

Comece com o sistema de produto existente, não com um prompt em branco. Separe o trabalho em exploração, implementação e revisão. Deixe o agente gerar opções e realizar verificações repetíveis, mas mantenha o designer do produto responsável pelo problema, pela direção escolhida e pela aceitação final.

Os designers de produto podem trabalhar sem Figma?

Sim, quando o produto já possui componentes, modelos de páginas e padrões de interação estáveis. Figma continua útil para uma nova linguagem visual ou uma interação desconhecida. A questão não é banir Figma; é evitar reconstruir decisões de produtos conhecidos em uma segunda tela.

A IA está substituindo os designers de produtos?

Não neste fluxo de trabalho. O agente monta opções, edita código e verifica cenários. O projetista ainda enquadra o problema, define restrições, compara compensações, escolhe a direção e decide se o produto em execução é bom o suficiente para ser enviado.