UX Designer

El UX Designer es la persona que cura el design system y resguarda la accesibilidad. En un SDLC AI-native, el UX Designer opera un stack de primitivas validadas que convierten decisiones de diseño en tokens legibles por máquina y compuertas aplicables.

Resumen ejecutivo

El UX Designer produce y gobierna el design system, la arquitectura de información y las garantías de accesibilidad para cada superficie cara al usuario. En un SDLC AI-native, el UX Designer opera dentro de la fase de Design con un conjunto fijo de primitivas: un agente de curaduría del design system, cuatro slash prompts, instrucciones con alcance, hooks validados por esquema y una lista curada de MCPs validados. Las salidas principales son el mapa de tokens, la librería de patrones de componentes, los reportes de escaneo de accesibilidad y la arquitectura de información contra la cual el Developer y el QA Engineer implementan.

Rol y responsabilidades

Piensa en el UX Designer como el editor de un lenguaje de diseño. No envían cada pantalla, pero cada pantalla que se envía tiene que coincidir con la tipografía, el espaciado, el color, el motion y las reglas de accesibilidad que escribieron. En un SDLC AI-native, el lenguaje de diseño vive como tokens legibles por máquina, la librería de patrones es consumible por agentes, y el UX Designer es responsable de que el producto se vea y se sienta coherente desde el primer sketch hasta la página renderizada.

Responsabilidades principales:

• Redactar y mantener el mapa de design tokens bajo docs/design-system/tokens/ para color, tipografía, espaciado, radius, motion y elevación
• Gobernar la librería de patrones de componentes bajo docs/design-system/patterns/ con reglas de uso y notas de accesibilidad
• Correr escaneos de accesibilidad sobre cada PR de front-end vía Playwright MCP e integraciones con axe-core
• Mantener la arquitectura de información bajo docs/ia/ que amarra journeys de usuario a páginas y componentes
• Operar el agente Design System Curator y los prompts /token-map, /a11y-scan, /pattern-lib, /ia-review
• Alinear las decisiones de diseño con los principios del Enterprise Architect, el spec del Product Owner y el target de despliegue de Azure Static Web Apps
• Publicar el digest de design review al canal de producto en Teams para visibilidad de stakeholders

Jobs to be done

1. Como UX Designer, quiero que el mapa de tokens sea la fuente de verdad, para que cada componente y página lea de la misma paleta y escala.
2. Como UX Designer, quiero que la accesibilidad esté con compuerta en PR, para que las violaciones WCAG nunca lleguen a producción.
3. Como UX Designer, quiero que la librería de patrones sea consumible por agentes, para que Copilot proponga componentes desde nuestro sistema, no desde la web abierta.
4. Como UX Designer, quiero que la arquitectura de información amarre journeys a páginas, para que cada pantalla tenga un contexto y propósito nombrado.
5. Como UX Designer, quiero que los design tokens regeneren el CSS y el theme de Static Web App al hacer merge, para que la intención y la salida permanezcan alineadas.
6. Como UX Designer, quiero que el digest de design review afloran violaciones y patrones semanalmente, para que la deuda se gestione, no se acumule.

Puntos de dolor antes de la era AI-native

1. Tokens atrapados en una herramienta de diseño. Los colores y espaciados viven en un archivo de diseño y se copian a mano al CSS. La deriva está garantizada.
2. Accesibilidad chequeada en release. Las violaciones WCAG aterrizan en producción porque los escaneos solo corren en el ambiente de staging.
3. Librería de patrones como PDF. Los developers y agentes no pueden consumir documentos estáticos. Inventan componentes fuera del sistema.
4. Arquitectura de información como wireframe. Las páginas y journeys se dibujan, no se enlazan. El tagging de analytics ocurre ad-hoc.
5. Deuda de diseño invisible. Las divergencias del sistema se acumulan sin un escaneo que las afloran.

Flujo diario AI-native

El UX Designer opera un loop fijo cada día. El loop usa primitivas de GitHub Copilot dentro de Visual Studio Code y Claude Code en la terminal, además de un pequeño catálogo de MCPs validados para contexto externo.

Setup de la mañana

1. Abrir el repositorio del design system en Visual Studio Code. GitHub Copilot Chat carga AGENTS.md y las instrucciones del design system con alcance.
2. Hacer pull del último main y revisar PRs nocturnos de componentes contra la librería de patrones.
3. Ejecutar /a11y-scan vía Playwright MCP para producir el reporte de accesibilidad actual a través de los ambientes de preview de Azure Static Web App.
4. Revisar el dashboard del design system generado a partir de la telemetría del MCP de GitHub.

Ejecución al mediodía

1. Autoría de tokens. Invocar /token-map sobre cualquier token nuevo o revisado. El agente Design System Curator produce el archivo de token, regenera el export de CSS y actualiza el bundle de theme de Azure Static Web Apps.
2. Autoría de patrones. Invocar /pattern-lib sobre nuevos componentes o reglas de uso revisadas. El agente produce un documento de patrón con props, notas de accesibilidad y un ejemplo preparado.
3. Arquitectura de información. Invocar /ia-review cuando se proponga un nuevo journey o página. El agente actualiza el mapa de IA bajo docs/ia/ y amarra la página a componentes nombrados de la librería de patrones.
4. Consulta entre personas. Levantar debates de diseño en el canal de producto en Teams a través del MCP del Microsoft 365 Agents SDK, con enlaces a patrones como cita canónica.

Revisión al final de la tarde

1. Invocar /a11y-scan como barrida final sobre todos los PRs abiertos de front-end. Bloquear el merge en cualquier violación WCAG crítica detectada por Playwright MCP y axe-core.
2. Abrir un pull request sobre cambios de tokens, patrones o IA. GitHub Copilot Code Review comenta sobre consistencia de tokens y anotaciones de accesibilidad.
3. Publicar el digest diario de diseño al canal de producto en Teams a través del Microsoft 365 Agents SDK, resumiendo nuevos tokens, revisiones de patrones y violaciones abiertas.
4. Actualizar el changelog del design system y regenerar el preview de Azure Static Web App para que los stakeholders puedan navegar el estado actual.

Primitivas recomendadas

Agente

Agente	Archivo	Propósito
design-system-curator	.github/agents/design-system-curator.agent.md	Redactar tokens, curar la librería de patrones, correr escaneos de accesibilidad y gobernar la arquitectura de información

El Design System Curator usa claude-sonnet-4-6 por defecto. Herramientas: read, edit, search, grep, glob, bash con alcance a scripts de build de tokens. El extended thinking está deshabilitado porque las tareas iterativas de diseño se benefician de loops cortos y rápidos.

Slash prompts

Comando	Archivo	Propósito
/token-map	.github/prompts/token-map.prompt.md	Redactar o revisar tokens y regenerar el CSS y el theme de Static Web App
/a11y-scan	.github/prompts/a11y-scan.prompt.md	Correr chequeos de accesibilidad vía Playwright MCP y axe-core
/pattern-lib	.github/prompts/pattern-lib.prompt.md	Redactar o revisar un patrón de componente con props y notas de accesibilidad
/ia-review	.github/prompts/ia-review.prompt.md	Revisar y actualizar el mapa de arquitectura de información para un journey

Instrucciones con alcance

El applyTo con alcance reduce el costo en tokens en aproximadamente 68 por ciento comparado con instrucciones globales.

Alcance (applyTo)	Archivo	Propósito
docs/design-system/tokens/**/*.json	.github/instructions/tokens.instructions.md	Esquema de token, reglas de naming y contrato de regeneración
docs/design-system/patterns/**/*.md	.github/instructions/patterns.instructions.md	Plantilla de documento de patrón, props, anotaciones de accesibilidad
docs/ia/**/*.md	.github/instructions/ia.instructions.md	Esquema de arquitectura de información, vinculación journey-a-página, tagging de analytics

Hooks

Los hooks cuestan cero tokens de LLM. Son la capa de gobierno más fuerte para diseño.

• pre-commit: rechazar cualquier archivo de token que rompa el esquema de naming o cualquier patrón sin anotaciones de accesibilidad
• post-commit: regenerar el export de CSS, el bundle de theme de Static Web App y el índice de patrones
• pre-merge: correr /a11y-scan sobre el preview deployment del PR y bloquear el merge en violaciones WCAG críticas

MCPs validados

MCP	Propósito	Dueño
Playwright MCP	Manejar escaneos de accesibilidad y regresiones visuales contra preview deployments	Microsoft (oficial)
GitHub MCP Server	Leer PRs de front-end, corridas de Actions y metadata de preview deployment	GitHub (oficial)
Azure MCP Server	Inspeccionar ambientes de preview de Azure Static Web Apps y configuración	Microsoft (oficial)
Microsoft Learn Docs MCP	Anclar decisiones de diseño en la guía de Microsoft Fluent y de accesibilidad	Microsoft (oficial)
Microsoft 365 Agents SDK MCP	Publicar digests de diseño a Teams e ingerir feedback de stakeholders desde Outlook	Microsoft (oficial)

Ejemplos reales

Ejemplo 1: nuevo color primario y contraste accesible

Entrada: Un brand refresh introduce un nuevo color primario. El color debe pasar contraste WCAG AA contra la paleta neutra existente.

Invocación: /token-map seguido de /a11y-scan.

Salida esperada:

1. Un docs/design-system/tokens/color/primary.json actualizado con el nuevo valor y anotaciones de matriz de contraste.
2. Variables CSS regeneradas en el bundle de theme de Azure Static Web App.
3. Un reporte de escaneo de accesibilidad confirmando contraste AA a través de 14 superficies interactivas, con tres superficies marcadas que necesitan revisión de patrón.
4. Un pull request con comentarios de Copilot Code Review sobre el naming de tokens e impacto de patrón.

Ejemplo 2: compuerta de accesibilidad sobre un nuevo flujo de checkout

Entrada: Un nuevo journey de checkout con cinco páginas introducido bajo src/checkout/.

Invocación: /ia-review seguido de /a11y-scan.

Salida esperada:

1. Un docs/ia/checkout.md actualizado que amarra las cinco páginas a patrones nombrados y eventos de analytics.
2. Una corrida de accesibilidad de Playwright MCP contra el preview de Static Web App con cero violaciones críticas, dos issues menores de label y tres warnings de navegación por teclado.
3. Tres issues presentados vía el MCP de GitHub para los warnings, asignados al Developer con enlaces a patrones como referencia de remediación.
4. Un merge bloqueado hasta que cierren las violaciones críticas, desbloqueado una vez que los warnings tengan dueño y un issue de seguimiento.

Anti-patrones

1. Copy-paste de design tokens. Los valores divergen a través de repos y plataformas. Mitigación: los archivos de token son la fuente única, regenerados por hook.
2. Accesibilidad como checklist de release. Las violaciones aterrizan en producción antes de que el checklist corra. Mitigación: el hook pre-merge corre /a11y-scan en cada preview de PR.
3. Librería de patrones como PDF. Los developers inventan componentes fuera del sistema. Mitigación: la librería de patrones es markdown y el paquete de contexto preparado enlaza patrones por nombre.
4. Journeys dibujados, no mapeados. Las páginas se envían sin contexto, analytics o anotaciones de accesibilidad nombrados. Mitigación: /ia-review amarra cada página a referencias de patrón y analytics.
5. Deuda de diseño tolerada. Las divergencias se acumulan sin un escaneo. Mitigación: el digest semanal de diseño afloran conteos de divergencia con dueños.

KPIs y métricas de impacto

KPI	Línea base	Meta	Medición
Violaciones WCAG críticas en release	6 por release	0	Reporte de escaneo de Playwright MCP
Adopción de tokens, componentes que leen del mapa de tokens	55 por ciento	100 por ciento	Auditoría de uso de variables CSS
Adopción de librería de patrones, componentes redactados desde patrones	45 por ciento	> 90 por ciento	Auditoría de uso de patrones
Cobertura de IA, páginas con vinculación de journey y analytics	30 por ciento	100 por ciento	Linter de IA en GitHub Actions
Ítems de deuda de diseño cerrados por semana	3	> 8	Resumen del digest
Tiempo de ciclo preview-a-aprobación	3 días	< 1 día	Timestamps de PR de GitHub

Madurez en cuatro niveles

Nivel	Nombre	Marcadores
L1	Manual	Tokens en una herramienta de diseño, patrones en PDF, accesibilidad en release
L2	Asistido	Copilot usado para pulir prosa de patrón, tokens copiados-pegados al CSS
L3	Aumentado	Agente Design System Curator, cuatro slash prompts, instrucciones con alcance, Playwright MCP, escaneos de a11y en PR
L4	Autónomo	Kit completo de primitivas, hooks forzados, regeneración de tokens automatizada, vinculaciones de IA estándar, digest semanal en vivo

Integración con otras personas

• Desde Product Owner: SPECIFICATION.md aprobado con criterios de aceptación cara al usuario que la IA debe honrar
• Desde Enterprise Architect: principios que restringen la política visual y de accesibilidad
• Hacia Developer: tokens, patrones y paquetes de contexto preparado que vuelven determinístico el trabajo de componentes
• Hacia QA Engineer: escaneos de accesibilidad como suite de prueba de primera clase junto a las pruebas funcionales
• Hacia DevOps Engineer: requisitos del ambiente de preview de Azure Static Web Apps para escaneos de accesibilidad
• Hacia Tech Writer: librería de patrones y mapa de tokens como fuente canónica para la documentación de UI
• Hacia DevRel: artefactos públicos del design system para audiencias de developers

Glosario

• Design token: un valor nombrado y legible por máquina para color, tipografía, espaciado, radius, motion o elevación.
• Patrón: un componente documentado con props, reglas de uso y anotaciones de accesibilidad.
• Arquitectura de información: el mapeo de journeys de usuario a páginas y componentes, con vinculaciones de analytics y accesibilidad.
• Escaneo de accesibilidad: barrida automatizada vía Playwright MCP y axe-core que chequea páginas contra criterios WCAG.
• Deuda de diseño: divergencia entre superficies enviadas y el design system, medida y gestionada semanalmente.
• Mapa de tokens: el export generado y versionado de todos los tokens consumidos por CSS, componentes y el bundle de theme de Azure Static Web App.

Referencias

• Microsoft Fluent design system — patrones y tokens de diseño canónicos de Microsoft
• Azure Static Web Apps documentation — plataforma de despliegue para escaneos de accesibilidad en ambiente de preview
• Playwright documentation — guía de testing automatizado de accesibilidad
• GitHub Copilot documentation — agent mode, prompts e instructions
• Web Content Accessibility Guidelines (WCAG) — especificación normativa de accesibilidad