Un caso de estudio UX/UI + full-stack cada día

Cómo organizo un pipeline autónomo (ALS-2) que, cada día, investiga un sector nuevo, diseña en Paper, implementa una app Angular + NestJS + Neon + Tailwind, y publica el caso en este portafolio — sin tocar la cadena Hermes.

Los proyectos que ves en /ux salen de ese cron. Hermes vive en /hermes y es un sistema distinto.

La idea en 60 segundos

Cada jornada de diseño produce un producto vertical completo:

LOAD → BRIEF → EXECUTE → SCORE → WRITEBACK
  │       │         │         │          │
  │       │         │         │          └─ memory + registry + dashboard Neon + portafolio
  │       │         │         └─ rúbrica craft / UX / código
  │       │         └─ docs + Paper hi-fi + app runnable
  │       └─ sector, nivel, shell, anti-patrones del día
  └─ memory.md + diversity cooldowns + lecciones previas

Entregables del día:

1. Case de estudio (docs de producto, UX, IA, flujos, design system, handoff…).
2. Paper con artboards de proceso UX y UI hi-fi multi-fila (no una sola tira de pantallas).
3. App en repositorio GitHub nuevo: Angular + NestJS + Prisma + Neon + Tailwind.
4. Aprendizaje: directivas y anti-patrones actualizados para que el día siguiente no repita errores finos de UX/UI.

Stack fijo (no se improvisan frameworks)

Hermes usa su propia cadena de crons y despliegues. Esta sección UX no modifica rutas ni datos de /hermes.

Qué cambia cada día (diversidad forzada)

Para no fabricar “el mismo dashboard con otro color”:

• Sector distinto al de los últimos días (construcción, moda, energía, agro, legal…).
• Nivel de complejidad L1–L4 (compacto → multi-rol / marketplace).
• Shell de navegación y composición rotados (wizard, editorial full-bleed, bottom-nav campo, dual-panel ops…).
• Directivas de craft: mínimo de artboards UX e UI, layout multi-banda en Paper, media real, microcopy operativo.

Paper: investigación + producto, no mockups sueltos

Cada case exige:

• ≥ 12 artboards de proceso UX (personas, journeys, flujos, IA, datos, decisiones…).
• ≥ 10 artboards UI hi-fi (must-have del producto + empty/error/loading + mobile + staff).
• Layout en varias filas / bandas en el canvas (prohibido un único carril horizontal eterno).

El objetivo es legibilidad de portfolio y disciplina de producto: cada pantalla responde a un requisito documentado.

Implementación: vertical slice real

La app del día no es un stub:

• API con auth, modelo de datos y seed demo.
• UI que cubre el journey must-have de punta a punta.
• Estados empty / loading / error donde el flujo lo exige.
• README con arranque local y credenciales de demo.

Repo de ejemplo: cantera-app, pliego-app, rele-app… cada uno público en GitHub.

Autoaprendizaje (ALS-2)

Al cerrar el día:

Sin WRITEBACK honesto el día no se considera cerrado: el sistema solo mejora si registra lo que falló (p. ej. demasiados artboards finos, o una sola fila en Paper).

Cómo se publica aquí

1. Se copian o regeneran los metadatos del case en src/data/ux-projects.ts.
2. Se añade la imagen hero en public/assets/ux/<slug>.jpg.
3. Home muestra los 3 más recientes; /ux lista todos con filtros.
4. Push a main del repo Astro → deploy automático.

El flujo creativo de Hermes (/hermes/flujo-creativo) documenta su pipeline. Este documento documenta el de UX/ALS.

Principios de diseño que se repiten (a propósito)

• Craft de estudio, no plantilla genérica.
• Roles reales cuando el nivel lo pide (capataz/jefe, residente/asesor, dueño/cuidador…).
• Copy operativo (códigos de referencia, estados NEW → REVIEWED, franjas, kWh…).
• Accesibilidad y contraste en la UI hi-fi y en código.
• Separación total de Hermes: slugs, assets y rutas bajo /ux y #ux-projects.

Dónde mirar a continuación

• Catálogo: /ux
• Home (últimos 3): sección Proyectos UX
• Código de cada case: enlaces GitHub en las cards
• Paper: enlaces en las cards cuando el archivo del día está disponible