Hooka Design
System
Sistema de diseño listo para ingeniería. Tokens, componentes, estados, accesibilidad WCAG 2.2 AA y checklist de QA. Stack: React + Tailwind CSS.
Contexto e intención de diseño
Hooka es una plataforma de automatización de outreach para equipos B2B. El sistema de diseño debe transmitir energía y precisión técnica — una interfaz que se siente rápida, confiable y moderna. IBM Plex Mono como fuente principal refuerza la identidad técnica y monoespaciada. La paleta centrada en el rosa intenso (#db2777) crea diferenciación en el mercado SaaS gris.
Tokens de color
Usar siempre tokens semánticos, nunca valores hexadecimales en componentes. Los tokens son la fuente única de verdad.
Escala tipográfica
IBM Plex Mono en todos los niveles. La escala monoespaciada refuerza la identidad técnica. Usar siempre los tokens de tamaño, nunca px directos en componentes.
Escala de espaciado
Base 4px. Seis pasos semánticos. Nunca usar valores intermedios no definidos en la escala.
Botones
El botón es el elemento de acción principal. Cada variante tiene un uso semántico concreto — no combinar colores por estética.
aria-label si el texto solo es ícono.:focus-visible visible a 3px de ring.aria-disabled + disabled juntos cuando inactivo.aria-busy="true" en loading.Inputs de texto
Los campos de formulario siguen una anatomía fija: label + input + hint. Nunca omitir el label visible.
for vinculado al id.rgba(219,39,119,0.18).aria-describedby.aria-invalid="true" en estado error.aria-describedby apuntando al hint en todos los estados.Badges de estado
Las etiquetas de estado comunican el ciclo de vida de las campañas. Son solo informativas — nunca usar como botones.
role="status" si cambia dinámicamente.prefers-reduced-motion.Card de campaña
La card es la unidad de información primaria del dashboard. Contiene estado, métricas clave y acciones contextuales.
role="article" o ser un <article>.aria-label descriptivo.Accesibilidad WCAG 2.2 AA
Criterios de aceptación testables. Cada punto debe verificarse en code review antes de merge.
var(--color-focus-ring), offset 2px.aria-label obligatorio en icon-buttons.aria-live="polite" para cambios de estado dinámicos.role="status" en badges que cambian en tiempo real.aria-describedby vincula hints de error a inputs.prefers-reduced-motion en todas las animaciones.@media (prefers-reduced-motion: reduce).Anti-patrones prohibidos
Implementaciones que deben rechazarse en code review. Cada anti-patrón incluye la alternativa correcta.
Usar font-family: Arial o estilos del navegador en lugar de var(--font-primary).
El botón rompe la coherencia tipográfica y los tests de screenshot.
Siempre font-family: var(--font-primary) y tamaño desde tokens.
Fuente consistente. Tamaño desde --text-sm. Border-radius desde --radius-md.
Badge con color rojo pero sin texto de estado — falla WCAG 1.4.1.
Usuarios con daltonismo no pueden distinguir el estado.
Siempre combinar indicador de color con texto descriptivo explícito.
El texto "Error" es suficiente sin depender del color.
Usar solo placeholder como label — desaparece al escribir, invisible para lectores de pantalla.
Label visible siempre presente. Placeholder es ayuda opcional, no sustituto.
QA Checklist
Ejecutar antes de cada merge que afecte componentes UI. Todos los items deben estar marcados.
var(--color-*)), sin hex directos.var(--text-*)).var(--space-*)).var(--radius-*)).for/id.aria-describedby.aria-invalid="true" en estado error.prefers-reduced-motion.aria-label descriptivo.