FORMA Design System / UX + Design Critique
Nielsen's 10 Heuristics — 0-4 por heurística. Bandas: 36-40 Excellent, 28-35 Good, 20-27 Acceptable, <20 Needs Work.
| # | Heurística | Score | Hallazgo |
|---|---|---|---|
| 1 | Visibility of System Status | 3 | aria-current="page" correcto en nav. Sin estados de carga. Página activa sin indicación en sidebar al navegar con JS. |
| 2 | Match System / Real World | 4 | Nombres de tokens coinciden exactamente con Figma. Componentes con nomenclatura estándar de la industria. Perfecto para el público técnico. |
| 3 | User Control and Freedom | 3 | ✓ Sidebar convertido en barra horizontal scrollable en mobile — secciones accesibles. Kbd overlay es descubrimiento pasivo. Sin breadcrumbs en páginas internas. |
| 4 | Consistency and Standards | 4 | ✓ Tokens de animación unificados (--dur-fast, --ease-expo). Lenguaje visual coherente en todas las páginas. |
| 5 | Error Prevention | 3 | ✓ Enlace a auditoría funciona correctamente (auditoria/). Sin validación en inputs del demo. Demos interactivos sin feedback de error. |
| 6 | Recognition Rather Than Recall | 4 | ✓ Navegación siempre visible en desktop. En mobile sidebar → barra horizontal scrollable con todos los anchors. El usuario ya no tiene que recordar la estructura de la página. |
| 7 | Flexibility and Efficiency | 3 | ✓ Skip-link funcional en todas las páginas (header.js + id="main"). Panel kbd-overlay sin shortcuts documentados. Copy-to-clipboard en tokens es eficiente. |
| 8 | Aesthetic and Minimalist Design | 4 | Genuinamente limpio. Cada elemento decorativo es también informacional (el cubo muestra el sistema; el grid de fondo refuerza la metáfora de layout). Nada superfluo. |
| 9 | Error Recovery | 2 | Copy toast confirma éxito correctamente. Sin mensajes de error en links rotos (silent 404). Sin feedback en demos de formulario con estado de error. |
| 10 | Help and Documentation | 2 | Sistema en sí es una docs site — irónico que carezca de tooltips explicativos en demos de componentes. Sin search. Sin "quickstart" path para nuevos usuarios. |
| Total | 32/40 | Good → approaching Excellent — Atender H9, H10 y el onboarding path para cruzar 36 |
✓ PASA — Diseño intencional, no genérico
LLM Assessment: FORMA no parece AI-generated. La paleta —dark neutral con un único blue accent— es exactamente lo documentado en .impeccable.md. El cubo 3D rotante que exhibe sus propias faces (tipografía, colores, spacing, motion, grid) es un momento de diseño genuinamente memorable: el sistema explicándose a sí mismo en 3D. Sin gradient text. Sin glassmorphism. Sin border-left decorativo. La triada tipográfica (Bebas Neue + Barlow + JetBrains Mono) tiene jerarquía de roles estricta — nunca mezclados.
Riesgo borderline detectado: El .stat-row en hero.css (big numbers + labels en grid) roza el "hero metrics layout" anti-pattern. En contexto de una design system docs page es defensible, pero si prolifera en más páginas pierde legitimidad.
Scan determinístico (code review): 1 patrón pendiente — hardcoded hex colors en inline styles del bento grid de index.html (~8 instancias). Resueltos: font loading (Bebas Neue en <head>), aria en hero SVG (role="img" + aria-label). Ninguno de estos invalida el aesthetic — son issues de implementación, no de diseño.
"El hero de index.html es la mejor pantalla del sistema.
Todo lo demás no está a su altura."
FORMA tiene una identidad visual nítida y ejecutada con rigor en index.html. El cubo animado, el wordmark en blanco masivo, la banda de navegación monocromática — todo comunica "este sistema fue construido con cuidado deliberado."
El problema es que las páginas internas (components.html, guidelines.html) se sienten como una transición brusca: de un hero cinematográfico a una interfaz de documentación funcional pero relativamente plana. La promesa del hero no se sostiene en la experiencia de uso real. El usuario que llega al sistema de componentes puede sentirse como si hubiera entrado por la puerta equivocada.
La mayor oportunidad única: conectar la teatralidad del hero con la funcionalidad de las páginas internas. Las secciones de componentes necesitan su propio momento editorial — no otro cubo 3D, pero sí una voz visual que recuerde al usuario que está dentro de un sistema diseñado con intención.
Qué pasa: Index.html tiene un hero de ~100vh con el cubo, la animación del logo, y el wordmark masivo. Cuando el usuario hace click en "Components →" llega a una página con un hero textual genérico (hero-title + hero-lead + stat-row) que se siente intercambiable con cualquier documentación técnica.
Por qué importa: La señal de calidad del hero crea una expectativa que las páginas internas no confirman. Los usuarios técnicos (el audience exacto de FORMA) son hipersensibles a inconsistencias de craft — si el primer contacto promete rigor y el segundo lo rompe, genera desconfianza subconsciente hacia el sistema.
Fix: Las páginas internas necesitan al menos un momento de personalidad distintiva — un elemento tipográfico, un tratamiento del stat-row que use la identidad visual de FORMA, o un header hero que muestre las métricas del sistema de una manera única al sistema (no un 3×1 grid genérico). La solución no necesita ser el cubo — pero necesita tener el mismo nivel de intención.
/overdriveQué pasa: La banda de navegación ahora tiene un item "Start here" con acento visual que apunta a guidelines.html. Esta es una mejora real — ya hay un entry point diferenciado. Sin embargo, guidelines.html no es una página de "Getting Started" — es la referencia completa de color, tipografía y motion. El nuevo usuario llega a una página densa, no a un quickstart guiado.
Lo que falta: Una "Getting Started" page real con un path de 3–5 pasos (instalar, ver tokens, usar un componente), o una sección introductoria al inicio de guidelines.html que explique el flujo recomendado de adopción. El bento grid tampoco tiene jerarquía de entrada clara.
Fix: Crear una landing de onboarding, o agregar un bloque "New to FORMA?" al inicio de guidelines.html con 3–4 pasos concretos antes del contenido de referencia.
/clarifyQué pasa: En components.html y el bento de index.html, los badges, botones y alerts se muestran en su estado default. No hay demos de hover, focus, active, disabled, o error states. La documentation más importante de un componente es precisamente cómo se comporta en estados no-default.
Por qué importa: Un engineer que consulta si usar .btn--ghost vs .btn--secondary necesita ver el hover state y el active state — los dos estados en que se diferencian más. Sin eso, están tomando decisiones a ciegas.
Fix: Agregar una fila de "States" por componente que muestre: default, hover (con CSS :hover o un wrapper .is-hover), focus, active, disabled. No requiere JavaScript — solo clases CSS aplicadas estáticamente.
/delightQué pasa: .band { display: none } en 768px. El nav overlay del header tiene links de primer nivel pero no los links de sección. En mobile el usuario tiene: header con logo y burger → overlay con ~6 links → sin estructura interna.
Por qué importa: Design system docs se consultan en cualquier dispositivo — un designer en iPad haciendo referencia rápida durante una reunión. Sin navegación de sección, la página es lineal y el usuario tiene que hacer scroll para encontrar lo que busca.
Fix: El nav overlay debería incluir los links de sección agrupados por página. Alternativamente, un "sticky section picker" dropdown al top de cada página en mobile.
/layout✓ RESUELTO 04 Jun 2026 — sidebar.css: display:none reemplazado por barra horizontal sticky scrollable en mobile. Todos los section anchors visibles debajo del header.
Qué pasa: El .kbd-overlay y el trigger button existen en shared.css con diseño correcto. Sin embargo, en el código analizado no se ve qué shortcuts están implementados — solo el panel visual. Si los shortcuts no tienen handlers JS correspondientes, el panel es decorativo.
Por qué importa: Para el usuario power (engineers que usan el sistema daily), shortcuts reales como ⌘K para search, / para saltar a sección, o C para copiar el token seleccionado serían diferenciadores de UX reales.
Fix: Implementar al menos 3 shortcuts funcionales o remover el panel. Un panel de shortcuts vacío baja la credibilidad del sistema.
/delight8-item checklist. 0-1 fallos = baja (bien); 2-3 = moderada; 4+ = crítica. Resultado: 2 fallos — carga moderada.
Tres personas relevantes para FORMA — dos estándar, uno específico del proyecto.
:focus-visible del input component antes de usarlo. La demo no lo muestra — tiene que escribir código de prueba para verificar.
--duration-fast / --easing-standard fue corregido — las referencias en components.css ahora usan --dur-fast / --ease-expo. Pero sin un lint report automatizado, el próximo drift seguirá siendo invisible hasta que alguien lo reporte manualmente.
cell__num con links a about.html. Mejora real. Pendiente: algunas celdas aún no tienen link (07, 09) y los links apuntan todos a about.html — podrían ser más específicos por sección.
.cell { padding: 40px } en todas las celdas. Las celdas con contenido pequeño (color system, token reference) se sienten con demasiado aire; las celdas con contenido largo se sienten apretadas. Padding variable por contenido mejoraría el ritmo.
.forma-footer__inner que duplican el layout del footer compartido en shared.css. Dos definiciones de la misma cosa pueden divergir si una se actualiza sin la otra.
--dim. cards.html, charts.html, slot.html siguen sin visibilidad en la navegación principal. Dos artículos publicados (viewport units, vibe coding) — considerar listar también cards.html.
[P0] Elevar el tratamiento visual de páginas internas (components, guidelines) para que la calidad del hero de index se mantenga — un elemento editorial distintivo en cada hero interno que no sea el stat-row genérico.
[P1] Agregar jerarquía de onboarding en la banda de navegación — diferenciar entry points de referencia advanced, agregar un "start here" path claro para nuevos usuarios.
[P1] Agregar demos de estados interactivos (hover, focus, active, disabled) para cada componente en components.html. Implementar al menos 3 keyboard shortcuts funcionales o remover el kbd panel.
[P1] Diseñar navegación mobile para páginas con sidebar — integrar section anchors en el nav overlay, o crear un sticky section picker en mobile.
[P2] Conectar cell numbers del bento a sus secciones correspondientes. Agregar link a las páginas huérfanas (articles, charts) en la navegación. Limpiar footer duplicado.
Puedes ejecutar estos comandos uno por uno, todos de una, o en cualquier orden que prefieras.
Vuelve a ejecutar /critique después de los fixes para ver tu score mejorar.