En los propios términos del Skill
Una disciplina centrada en el oficio para construir UI de producto — dashboards, paneles de administración, aplicaciones SaaS, herramientas, páginas de configuración, interfaces de datos — con las decisiones que tomaría un equipo de diseño de primer nivel. Exige un briefing de trabajo antes de escribir código: quién es la persona, el único verbo que vino a realizar, y cómo debería sentirse la interfaz, en palabras que tengan sentido.
A partir de ahí, prescribe la exploración del dominio (dominio, mundo de color, elemento distintivo, valores por defecto rechazados), una escala tipográfica basada en una proporción en la que el peso y el color hacen el trabajo de jerarquía, una estrategia de profundidad única y comprometida, tokens semánticos en lugar de literales codificados, y los aspectos esenciales de pulido y movimiento — números tabulares, radio concéntrico, duraciones inferiores a 300ms, sin animación en acciones de alta frecuencia. Explícitamente no está pensado para landing pages, sitios de marketing, campañas o trabajo exclusivo de marca.
Qué produce
- Una propuesta de Sugerir + Preguntar que nombra Dominio, Mundo de color, Elemento distintivo, Rechazo y Dirección.
- Especímenes renderizados en línea — muestras de paleta, la escala tipográfica en la tipografía real, tarjetas de elevación apiladas, el elemento distintivo como un componente real — cuando hay una herramienta de renderizado presente; la implementación en sí sigue llegando al código base.
- Un archivo .interface-design/system.md guardado que contiene la dirección, la estrategia de profundidad, las decisiones de jerarquía y los patrones de componentes repetidos, escrito solo después de que el usuario diga que sí.
Cómo funciona
- 01Escribir el Briefing de Trabajo
Antes de escribir cualquier código, responder quién es la persona, qué verbo debe cumplir y cómo debería sentirse la interfaz — mantenido de forma compacta a menos que la dirección necesite confirmación.
- 02Explorar el Dominio del Producto
Producir cuatro resultados antes de proponer una dirección: al menos 5 conceptos de dominio, 5 o más colores del mundo físico del producto, un elemento distintivo y 3 valores por defecto obvios para rechazar.
- 03Proponer y Confirmar la Dirección
Comenzar con un bloque de Sugerir + Preguntar que nombre Dominio, Mundo de color, Elemento distintivo, Rechazo y Dirección, y luego verificar que la dirección se sienta correcta antes de construir.
- 04Renderizar Especímenes Cuando Sea Posible
Si la sesión cuenta con una herramienta de renderizado visual en línea, mostrar la paleta, la escala tipográfica, los pasos de elevación y el elemento distintivo como componentes reales en lugar de describirlos; de lo contrario, recurrir al código.
- 05Construir Sobre lo Existente y Luego Verificar
Inspeccionar la aplicación, los tokens, los patrones de componentes y el system.md, aplicar parches a la implementación, ejecutar build, typecheck o tests cuando estén disponibles, y luego verificar visualmente en anchos de escritorio y móvil.
- 06Ofrecer Guardar los Patrones
Después de una tarea, ofrecer registrar la dirección, la estrategia de profundidad, las decisiones de jerarquía y los patrones de componentes repetidos para que las sesiones posteriores se mantengan consistentes.