/grill-design
Objetivo: definir como a aplicação deve parecer e se comportar para o usuário final, apoiado em patterns consolidados e em produtos reais, e registrar isso de forma persistente.
Preparação (silenciosa)
- Ler
wiki/index.md,wiki/overview.md, specs relacionadas emwiki/ui-specs/eschema/design-system.md(se existir). - Inspecionar a UI existente no código (biblioteca de componentes, tokens, Tailwind config, telas parecidas).
- Ler o catálogo de patterns.
- Se a feature não tem
/grillprévio e as regras de negócio são incertas, sugerir rodar/grillantes.
Regras de condução
-
Uma pergunta por vez, com recomendação justificada.
-
Toda pergunta de design vem com sugestões concretas, no formato:
**Pergunta:** Como o usuário deve navegar pelos 2.000 pedidos? | Opção | Pattern | Referências (o que copiar) | Prós | Contras | |---|---|---|---|---| | A ⭐ | Data table + filtros facetados + saved views | **Stripe Dashboard** (chips de filtro acima da tabela), **Linear** (views salvas na sidebar) | Escala, power users | Pior no mobile | | B | Master-Detail | **Gmail** (lista + leitura lado a lado) | Contexto preservado | Exige tela larga | | C | Cards grid | **Airbnb** (cards com foto) | Visual | Difícil comparar | **Recomendo A** porque o público é operacional, desktop, e compara status/valores. -
Referências devem ser apps reais e correlatos ao domínio do projeto (fintech → Nubank, Stripe, Mercury; produtividade → Linear, Notion; marketplace → Airbnb, Mercado Livre; etc.). Diga o que exatamente copiar (um detalhe específico), não só o nome.
-
Se o agente tiver busca web, pode pesquisar exemplos (Mobbin, Page Flows, Dribbble) para enriquecer.
-
Sempre que possível, mostre um wireframe ASCII da opção recomendada.
-
Respeite o design system existente; só proponha mudanças nele explicitamente.
Dimensões (percorrer o que for relevante, nesta ordem)
| # | Dimensão | Perguntas típicas | Patterns comuns a sugerir |
|---|---|---|---|
| 1 | Público e contexto | Quem é? Frequência de uso? Desktop/mobile? Nível técnico? | — (define o resto) |
| 2 | Jornada / user flow | De onde vem, qual objetivo, para onde vai? Passos? | Wizard, hub-and-spoke, linear flow |
| 3 | Arquitetura de informação | Quais telas? Hierarquia? Navegação? | Sidebar, tabs, bottom bar, ⌘K, breadcrumbs |
| 4 | Layout e hierarquia visual | Ponto focal? Densidade? Grid? Responsividade? | Master-detail, dashboard de KPI, split view |
| 5 | Exibição de dados | Lista, tabela, cards, gráfico? Busca/filtro/ordenação? | Data table, kanban, facetas, saved views |
| 6 | Criação e edição | Como cria/edita? Validação? Salvamento? | Modal, drawer, inline edit, autosave, stepper |
| 7 | Estados | Loading, vazio, erro, sucesso, parcial, sem permissão, offline | Skeleton, empty state educativo, undo toast, optimistic UI |
| 8 | Feedback e micro-interações | Confirmações, transições, hover, atalhos | Toast, inline validation, keyboard shortcuts |
| 9 | Design system e tokens | Biblioteca (shadcn, Radix, MUI…)? Cores semânticas, tipografia, espaçamento, dark mode | Tokens semânticos, escala 4/8px |
| 10 | Acessibilidade | Teclado, foco, contraste AA, leitor de tela, prefers-reduced-motion | Skip links, focus ring, ARIA patterns |
| 11 | Conteúdo e tom | Microcopy, idioma, tom de voz, mensagens de erro | — |
| 12 | Onboarding e ativação | Primeiro uso? Dados de exemplo? | Checklist, template gallery, sample data |
Síntese
Apresente a spec preenchendo o template ui-ux-spec.md, incluindo:
- tabela Patterns adotados (pattern → onde → referência → motivo);
- tabela Referências (app → o que copiar → o que evitar);
- wireframes ASCII das telas principais;
- matriz de estados por componente;
- tokens/regras novas propostas para o design system.
E a tabela de gravações:
| Destino | Arquivo | Ação |
|---|---|---|
| wiki | wiki/ui-specs/<tela-ou-fluxo>.md | /wiki:add |
| wiki | wiki/concepts/<feature>.md (link para a spec) | /wiki:increment |
| schema | schema/design-system.md | /schema:add (1ª vez) ou /schema:increment |
Plano de Implementação de UI (Tasks / Tickets)
| Task | Vertical | Depende de | Prioridade | Ação |
|---|---|---|---|---|
wiki/tasks/<slug-da-tela>.md | ui | - | medium | /ticket:new (wiki + issue) |
Aprovação explícita (gate)
"Aprova a spec de UI/UX, as gravações no design system e a criação das tasks (+ issues no GitHub)? (sim / ajustar)" — sem aprovação inequívoca, não grave nada.
Formalização (após aprovação)
- /wiki:add →
wiki/ui-specs/<slug>.md(type: ui-spec). - /wiki:increment nas páginas de feature/entidade relacionadas.
- /schema:add ou /schema:increment →
schema/design-system.md(template design-system-rules.md). - Execute /ticket:new para cada task de UI planejada (componentes, telas, interações), com as labels
vertical:ui(ou vertical da feature) estatus:planned. - Append em
wiki/log.md:## [AAAA-MM-DD] grill-design | <tela/fluxo>com as páginas e tasks criadas. - Sugerir próximos passos:
/implement <task-de-ui>, protótipo, telas vizinhas sem spec.