Designer de UX
Design system e acessibilidade.
O UX Designer é a persona que cura o design system e protege a acessibilidade. Em um SDLC AI-native, o UX Designer opera uma pilha de primitivas validadas que transformam decisões de design em tokens legíveis por máquina e gates aplicáveis.
Resumo executivo
O UX Designer produz e governa o design system, a arquitetura de informação e as garantias de acessibilidade para toda superfície voltada ao usuário. Em um SDLC AI-native, o UX Designer opera dentro da fase de Design com um conjunto fixo de primitivas: um agente de curadoria de design system, quatro slash prompts, instruções escopadas, hooks validados por schema e uma lista curada de MCPs validados. As saídas primárias são o token map, a pattern library de componentes, os relatórios de scan de acessibilidade e a arquitetura de informação contra a qual o Developer e o QA Engineer implementam.
Papel e responsabilidades
Pense no UX Designer como o editor de uma linguagem de design. Ele não entrega cada tela, mas toda tela que é entregue precisa bater com as regras de tipografia, espaçamento, cor, movimento e acessibilidade que ele escreveu. Em um SDLC AI-native, a linguagem de design vive como tokens legíveis por máquina, a pattern library é consumível por agentes e o UX Designer é responsável pelo fato de que o produto parece e se comporta de forma coerente, do primeiro sketch à página renderizada.
Responsabilidades primárias:
- Escrever e manter o mapa de design tokens em
docs/design-system/tokens/para cor, tipografia, espaçamento, radius, movimento e elevação - Governar a pattern library de componentes em
docs/design-system/patterns/com regras de uso e notas de acessibilidade - Rodar scans de acessibilidade em todo PR de front-end via Playwright MCP e integrações com axe-core
- Manter a arquitetura de informação em
docs/ia/que liga jornadas de usuário a páginas e componentes - Operar o agente Design System Curator e os prompts
/token-map,/a11y-scan,/pattern-lib,/ia-review - Alinhar decisões de design com os princípios do Enterprise Architect, a spec do Product Owner e o destino de deploy Azure Static Web Apps
- Publicar o digest de revisão de design no canal de produto no Teams para visibilidade com stakeholders
Jobs to be done
- Como UX Designer, eu quero que o token map seja a fonte da verdade, para que todo componente e página leia da mesma paleta e escala.
- Como UX Designer, eu quero que acessibilidade seja bloqueante no PR, para que violações de WCAG nunca cheguem em produção.
- Como UX Designer, eu quero que a pattern library seja consumível por agentes, para que o Copilot proponha componentes do nosso sistema, não da web aberta.
- Como UX Designer, eu quero que a arquitetura de informação ligue jornadas a páginas, para que toda tela tenha um contexto e propósito nomeados.
- Como UX Designer, eu quero que design tokens regenerem o CSS e o tema do Static Web App no merge, para que intenção e saída fiquem alinhadas.
- Como UX Designer, eu quero que o digest de revisão de design mostre violações e padrões semanalmente, para que a dívida seja gerenciada, não acumulada.
Dores antes da era AI-native
- Tokens presos em uma ferramenta de design. Cores e espaçamentos vivem em um arquivo de design e são copiados à mão para o CSS. Divergência é garantida.
- Acessibilidade verificada no release. Violações de WCAG aterrissam em produção porque os scans rodam só no ambiente de staging.
- Pattern library como PDF. Developers e agentes não conseguem consumir documentos estáticos. Eles inventam componentes fora do sistema.
- Arquitetura de informação como wireframe. Páginas e jornadas são desenhadas, não linkadas. Taggeamento de analytics acontece ad-hoc.
- Dívida de design invisível. Divergências do sistema se acumulam sem um scan que as mostre.
Fluxo diário AI-native
O UX Designer opera um loop fixo todo dia. O loop usa primitivas do GitHub Copilot dentro do Visual Studio Code e Claude Code no terminal, além de um pequeno catálogo de MCPs validados para contexto externo.
Setup da manhã
- Abra o repositório do design system no Visual Studio Code. GitHub Copilot Chat carrega o
AGENTS.mde as instruções escopadas do design system. - Puxe a última
maine revise PRs de componentes da madrugada contra a pattern library. - Rode
/a11y-scanvia Playwright MCP para produzir o relatório atual de acessibilidade nos ambientes de preview do Azure Static Web App em staging. - Revise o dashboard do design system gerado a partir da telemetria do GitHub MCP.
Execução no meio do dia
- Autoria de tokens. Invoque
/token-mapem qualquer token novo ou revisado. O agente Design System Curator produz o arquivo de token, regenera o export de CSS e atualiza o bundle de tema do Azure Static Web Apps. - Autoria de patterns. Invoque
/pattern-libem novos componentes ou regras de uso revisadas. O agente produz um documento de pattern com props, notas de acessibilidade e um exemplo preparado. - Arquitetura de informação. Invoque
/ia-reviewquando uma nova jornada ou página for proposta. O agente atualiza o mapa de IA emdocs/ia/e liga a página a componentes nomeados da pattern library. - Consulta cross-persona. Levante debates de design no canal de produto no Teams via Microsoft 365 Agents SDK MCP, com links de pattern como citação canônica.
Revisão no fim da tarde
- Invoque
/a11y-scancomo varredura final em todos os PRs de front-end abertos. Bloqueie o merge em qualquer violação crítica de WCAG detectada pelo Playwright MCP e axe-core. - Abra um pull request nas mudanças de token, pattern ou IA. O GitHub Copilot Code Review comenta sobre consistência de tokens e anotações de acessibilidade.
- Publique o digest diário de design no canal de produto no Teams via Microsoft 365 Agents SDK, resumindo novos tokens, revisões de pattern e violações abertas.
- Atualize o changelog do design system e regenere o preview do Azure Static Web App para que stakeholders possam clicar pelo estado atual.
Primitivas recomendadas
Agente
| Agente | Arquivo | Propósito |
|---|---|---|
design-system-curator | .github/agents/design-system-curator.agent.md | Escrever tokens, curar a pattern library, rodar scans de acessibilidade e governar a arquitetura de informação |
O Design System Curator usa claude-sonnet-4-6 por padrão. Ferramentas: read, edit, search, grep, glob, bash escopados a scripts de build de token. Extended thinking fica desabilitado porque tarefas de design iterativas se beneficiam de loops curtos e rápidos.
Slash prompts
| Comando | Arquivo | Propósito |
|---|---|---|
/token-map | .github/prompts/token-map.prompt.md | Escrever ou revisar tokens e regenerar o CSS e o tema do Static Web App |
/a11y-scan | .github/prompts/a11y-scan.prompt.md | Rodar checks de acessibilidade via Playwright MCP e axe-core |
/pattern-lib | .github/prompts/pattern-lib.prompt.md | Escrever ou revisar um pattern de componente com props e notas de acessibilidade |
/ia-review | .github/prompts/ia-review.prompt.md | Revisar e atualizar o mapa de arquitetura de informação para uma jornada |
Instruções escopadas
Um applyTo escopado reduz o custo em tokens em aproximadamente 68 por cento em comparação com instruções globais.
Escopo (applyTo) | Arquivo | Propósito |
|---|---|---|
docs/design-system/tokens/**/*.json | .github/instructions/tokens.instructions.md | Schema de tokens, regras de nomenclatura e contrato de regeneração |
docs/design-system/patterns/**/*.md | .github/instructions/patterns.instructions.md | Template de documento de pattern, props, anotações de acessibilidade |
docs/ia/**/*.md | .github/instructions/ia.instructions.md | Schema de arquitetura de informação, binding jornada-para-página, taggeamento de analytics |
Hooks
Hooks custam zero tokens de LLM. São a camada mais forte de governança para design.
pre-commit: rejeita qualquer arquivo de token que quebre o schema de nomenclatura ou qualquer pattern sem anotações de acessibilidadepost-commit: regenera o export de CSS, o bundle de tema do Static Web App e o índice de patternspre-merge: roda/a11y-scanno deployment de preview do PR e bloqueia o merge em violações críticas de WCAG
MCPs validados
| MCP | Propósito | Dono |
|---|---|---|
| Playwright MCP | Dirigir scans de acessibilidade e regressões visuais contra deployments de preview | Microsoft (oficial) |
| GitHub MCP Server | Ler PRs de front-end, runs do Actions e metadados de deployment de preview | GitHub (oficial) |
| Azure MCP Server | Inspecionar ambientes de preview do Azure Static Web Apps e configuração | Microsoft (oficial) |
| Microsoft Learn Docs MCP | Ancorar decisões de design no guia Microsoft Fluent e de acessibilidade | Microsoft (oficial) |
| Microsoft 365 Agents SDK MCP | Publicar digests de design no Teams e ingerir feedback de stakeholders do Outlook | Microsoft (oficial) |
Exemplos reais
Exemplo 1: nova cor primária e contraste acessível
Entrada: Um refresh de marca introduz uma nova cor primária. A cor precisa passar no contraste AA do WCAG contra a paleta neutra existente.
Invocação: /token-map seguido de /a11y-scan.
Saída esperada:
docs/design-system/tokens/color/primary.jsonatualizado com o novo valor e anotações de matriz de contraste.- Variáveis CSS regeneradas no bundle de tema do Azure Static Web App.
- Um relatório de scan de acessibilidade confirmando contraste AA em 14 superfícies interativas, com três superfícies sinalizadas que precisam de revisão de pattern.
- Um pull request com comentários do Copilot Code Review sobre nomenclatura de tokens e impacto no pattern.
Exemplo 2: gate de acessibilidade em um novo fluxo de checkout
Entrada: Uma nova jornada de checkout com cinco páginas introduzida em src/checkout/.
Invocação: /ia-review seguido de /a11y-scan.
Saída esperada:
docs/ia/checkout.mdatualizado ligando as cinco páginas a patterns nomeados e eventos de analytics.- Um run de acessibilidade do Playwright MCP contra o preview do Static Web App com zero violações críticas, dois problemas menores de label e três avisos de navegação por teclado.
- Três issues abertas via GitHub MCP para os avisos, atribuídas ao Developer com links de pattern como referência de remediação.
- Um merge bloqueado até que as violações críticas fechem, desbloqueado assim que os avisos tenham dono e issue de follow-up.
Anti-padrões
- Design tokens via copy-paste. Valores divergem entre repos e plataformas. Mitigação: arquivos de token são a fonte única, regenerados por hook.
- Acessibilidade como checklist de release. Violações aterrissam em produção antes do checklist rodar. Mitigação: hook
pre-mergeroda/a11y-scanem cada preview de PR. - Pattern library como PDF. Developers inventam componentes fora do sistema. Mitigação: a pattern library é markdown e o pack de contexto preparado linka patterns pelo nome.
- Jornadas desenhadas, não mapeadas. Páginas sobem sem contexto nomeado, analytics ou anotações de acessibilidade. Mitigação:
/ia-reviewliga cada página a referências de pattern e analytics. - Dívida de design tolerada. Divergências se acumulam sem scan. Mitigação: digest semanal de design mostra contagem de divergências com donos.
KPIs e métricas de impacto
| KPI | Linha base | Meta | Medição |
|---|---|---|---|
| Violações críticas de WCAG no release | 6 por release | 0 | Relatório de scan do Playwright MCP |
| Adoção de tokens, componentes lendo do token map | 55 por cento | 100 por cento | Auditoria de uso de variáveis CSS |
| Adoção da pattern library, componentes escritos a partir de patterns | 45 por cento | > 90 por cento | Auditoria de uso de patterns |
| Cobertura de IA, páginas com binding de jornada e analytics | 30 por cento | 100 por cento | IA linter em GitHub Actions |
| Itens de dívida de design fechados por semana | 3 | > 8 | Resumo do digest |
| Ciclo preview-para-aprovação | 3 dias | < 1 dia | Timestamps de PR do GitHub |
Maturidade em quatro níveis
| Nível | Nome | Marcadores |
|---|---|---|
| L1 | Manual | Tokens em ferramenta de design, patterns em PDF, acessibilidade no release |
| L2 | Assistido | Copilot usado para polir a prosa de patterns, tokens copiados manualmente para CSS |
| L3 | Aumentado | Agente Design System Curator, quatro slash prompts, instruções escopadas, Playwright MCP, scans de a11y no PR |
| L4 | Autônomo | Kit completo de primitivas, hooks aplicados, regeneração de tokens automatizada, bindings de IA padrão, digest semanal ativo |
Integração com outras personas
- Do Product Owner:
SPECIFICATION.mdaprovado com critérios de aceitação voltados ao usuário que a IA deve honrar - Do Enterprise Architect: princípios que restringem política visual e de acessibilidade
- Para Developer: tokens, patterns e packs de contexto preparado que tornam o trabalho de componentes determinístico
- Para QA Engineer: scans de acessibilidade como suíte de teste de primeira classe junto com testes funcionais
- Para DevOps Engineer: requisitos de ambiente de preview do Azure Static Web Apps para scans de acessibilidade
- Para Tech Writer: pattern library e token map como fonte canônica para documentação de UI
- Para DevRel: artefatos públicos de design system para audiências de desenvolvedor
Glossário
- Design token: um valor nomeado e legível por máquina para cor, tipografia, espaçamento, radius, movimento ou elevação.
- Pattern: um componente documentado com props, regras de uso e anotações de acessibilidade.
- Arquitetura de informação: o mapeamento de jornadas de usuário para páginas e componentes, com bindings de analytics e acessibilidade.
- Scan de acessibilidade: varredura automatizada via Playwright MCP e axe-core que verifica páginas contra critérios WCAG.
- Dívida de design: divergência entre superfícies entregues e o design system, medida e gerenciada semanalmente.
- Token map: o export gerado e versionado de todos os tokens consumidos pelo CSS, componentes e bundle de tema do Azure Static Web App.
Referências
- Design system Microsoft Fluent — patterns e tokens de design canônicos da Microsoft
- Documentação do Azure Static Web Apps — plataforma de deploy para scans de acessibilidade em ambiente de preview
- Documentação do Playwright — guia de testes automatizados de acessibilidade
- Documentação do GitHub Copilot — agent mode, prompts e instruções
- Web Content Accessibility Guidelines (WCAG) — especificação normativa de acessibilidade