08 product · Design

Designer de UX

Design system e acessibilidade.

Atualizado: 2026-04-24 14 seções Baixar .zip

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

  1. 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.
  2. Como UX Designer, eu quero que acessibilidade seja bloqueante no PR, para que violações de WCAG nunca cheguem em produção.
  3. 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.
  4. 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.
  5. 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.
  6. 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

  1. 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.
  2. Acessibilidade verificada no release. Violações de WCAG aterrissam em produção porque os scans rodam só no ambiente de staging.
  3. Pattern library como PDF. Developers e agentes não conseguem consumir documentos estáticos. Eles inventam componentes fora do sistema.
  4. Arquitetura de informação como wireframe. Páginas e jornadas são desenhadas, não linkadas. Taggeamento de analytics acontece ad-hoc.
  5. 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ã

  1. Abra o repositório do design system no Visual Studio Code. GitHub Copilot Chat carrega o AGENTS.md e as instruções escopadas do design system.
  2. Puxe a última main e revise PRs de componentes da madrugada contra a pattern library.
  3. Rode /a11y-scan via Playwright MCP para produzir o relatório atual de acessibilidade nos ambientes de preview do Azure Static Web App em staging.
  4. Revise o dashboard do design system gerado a partir da telemetria do GitHub MCP.

Execução no meio do dia

  1. Autoria de tokens. Invoque /token-map em 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.
  2. Autoria de patterns. Invoque /pattern-lib em novos componentes ou regras de uso revisadas. O agente produz um documento de pattern com props, notas de acessibilidade e um exemplo preparado.
  3. Arquitetura de informação. Invoque /ia-review quando uma nova jornada ou página for proposta. O agente atualiza o mapa de IA em docs/ia/ e liga a página a componentes nomeados da pattern library.
  4. 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

  1. Invoque /a11y-scan como 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.
  2. 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.
  3. 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.
  4. 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

AgenteArquivoPropósito
design-system-curator.github/agents/design-system-curator.agent.mdEscrever 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

ComandoArquivoPropósito
/token-map.github/prompts/token-map.prompt.mdEscrever ou revisar tokens e regenerar o CSS e o tema do Static Web App
/a11y-scan.github/prompts/a11y-scan.prompt.mdRodar checks de acessibilidade via Playwright MCP e axe-core
/pattern-lib.github/prompts/pattern-lib.prompt.mdEscrever ou revisar um pattern de componente com props e notas de acessibilidade
/ia-review.github/prompts/ia-review.prompt.mdRevisar 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)ArquivoPropósito
docs/design-system/tokens/**/*.json.github/instructions/tokens.instructions.mdSchema de tokens, regras de nomenclatura e contrato de regeneração
docs/design-system/patterns/**/*.md.github/instructions/patterns.instructions.mdTemplate de documento de pattern, props, anotações de acessibilidade
docs/ia/**/*.md.github/instructions/ia.instructions.mdSchema 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 acessibilidade
  • post-commit: regenera o export de CSS, o bundle de tema do Static Web App e o índice de patterns
  • pre-merge: roda /a11y-scan no deployment de preview do PR e bloqueia o merge em violações críticas de WCAG

MCPs validados

MCPPropósitoDono
Playwright MCPDirigir scans de acessibilidade e regressões visuais contra deployments de previewMicrosoft (oficial)
GitHub MCP ServerLer PRs de front-end, runs do Actions e metadados de deployment de previewGitHub (oficial)
Azure MCP ServerInspecionar ambientes de preview do Azure Static Web Apps e configuraçãoMicrosoft (oficial)
Microsoft Learn Docs MCPAncorar decisões de design no guia Microsoft Fluent e de acessibilidadeMicrosoft (oficial)
Microsoft 365 Agents SDK MCPPublicar digests de design no Teams e ingerir feedback de stakeholders do OutlookMicrosoft (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:

  1. docs/design-system/tokens/color/primary.json atualizado com o novo valor e anotações de matriz de contraste.
  2. Variáveis CSS regeneradas no bundle de tema do Azure Static Web App.
  3. 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.
  4. 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:

  1. docs/ia/checkout.md atualizado ligando as cinco páginas a patterns nomeados e eventos de analytics.
  2. 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.
  3. Três issues abertas via GitHub MCP para os avisos, atribuídas ao Developer com links de pattern como referência de remediação.
  4. 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

  1. Design tokens via copy-paste. Valores divergem entre repos e plataformas. Mitigação: arquivos de token são a fonte única, regenerados por hook.
  2. Acessibilidade como checklist de release. Violações aterrissam em produção antes do checklist rodar. Mitigação: hook pre-merge roda /a11y-scan em cada preview de PR.
  3. 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.
  4. Jornadas desenhadas, não mapeadas. Páginas sobem sem contexto nomeado, analytics ou anotações de acessibilidade. Mitigação: /ia-review liga cada página a referências de pattern e analytics.
  5. 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

KPILinha baseMetaMedição
Violações críticas de WCAG no release6 por release0Relatório de scan do Playwright MCP
Adoção de tokens, componentes lendo do token map55 por cento100 por centoAuditoria de uso de variáveis CSS
Adoção da pattern library, componentes escritos a partir de patterns45 por cento> 90 por centoAuditoria de uso de patterns
Cobertura de IA, páginas com binding de jornada e analytics30 por cento100 por centoIA linter em GitHub Actions
Itens de dívida de design fechados por semana3> 8Resumo do digest
Ciclo preview-para-aprovação3 dias< 1 diaTimestamps de PR do GitHub

Maturidade em quatro níveis

NívelNomeMarcadores
L1ManualTokens em ferramenta de design, patterns em PDF, acessibilidade no release
L2AssistidoCopilot usado para polir a prosa de patterns, tokens copiados manualmente para CSS
L3AumentadoAgente Design System Curator, quatro slash prompts, instruções escopadas, Playwright MCP, scans de a11y no PR
L4AutônomoKit 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.md aprovado 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