Designer MCP — Diseño basado en investigación

¿Qué hace Designer MCP — Diseño basado en investigación?

Fundamenta cada diseño en evidencia real de producto antes de la implementación. Esta habilidad combina una metodología de investigación primero con una biblioteca local y gratuita de 1,342 sistemas de diseño extraídos.

La biblioteca de investigación tiene una capa:

1. Estilos — dirección visual y gusto, extraídos de páginas web de marketing/producto reales.

Las pantallas y flujos existen en el producto Refero de pago pero no están en esta implementación. Para preguntas a nivel de pantalla o flujo de usuario, utiliza las referencias de oficio incluidas y el material propio del usuario, y dilo claramente en lugar de inventar precedentes.

Innegociables

• Investiga antes de diseñar. Cada diseño debe estar fundamentado en referencias antes de la implementación. No confíes en el gusto genérico de diseño del modelo.
• Usa los estilos primero para el trabajo visual. Si el servidor MCP no está disponible, utiliza las referencias de oficio incluidas y mantén el mismo flujo de trabajo de bloqueo por referencias.
• No copies una sola referencia. Estudia varias referencias sólidas y sintetiza una nueva dirección para el producto del usuario.
• No hagas un promedio de referencias hacia un término medio seguro. Cuando las referencias entren en conflicto, elige una dirección dominante y preserva sus rasgos definitorios. Las referencias secundarias solo pueden añadir detalles concretos y limitados.
• No cambies los significados de los tokens. Si una referencia dice que un color, tipografía, radio, sombra, degradado o componente es para un rol específico, úsalo solo para ese rol u omítelo.
• Respeta las guías de imágenes. Si un estilo depende de fotografía, ilustración, tomas de producto o gráficos, preserva el rol del medio. Utiliza activos reales/generados/de stock cuando estén disponibles; de lo contrario, crea un marcador de posición intencional con dirección artística. No finjas imágenes complejas con CSS débil, texto o cajas decorativas.
• No uses habilidades genéricas de diseño frontend/producto como una autoridad de diseño paralela cuando esta habilidad esté disponible. Esta es la metodología de diseño; las habilidades genéricas de diseño tienden a llevar el trabajo de vuelta al diseño genérico de IA.
• El resultado de la investigación debe ser específico. Nombra las referencias, describe las elecciones concretas y explica qué se adaptará.
• Nada de diseño desde la 'vibra' de la memoria. Cada decisión importante de visual, diseño, contenido o interacción debe remitirse a la investigación, al brief del usuario o a una referencia de oficio.
• Sintetiza antes de implementar. Convierte la investigación en un concepto, una dirección de tokens y un registro de decisiones concreto antes de dibujar o codificar.
• Un brief no es un objetivo de construcción. Antes de la implementación, fija una fuente visual proporcionada por el usuario, un producto/sistema de diseño existente, un mockup generado seleccionado o una dirección explícitamente bloqueada por referencias y aprobada para la construcción directa.
• Usa la generación de imágenes solo cuando cambie el resultado. La generación de imágenes puede ser lenta y puede que no exista en todos los entornos de codificación. Úsala para exploración visual, mockups, imágenes, ilustraciones, texturas y activos difíciles; omítela para correcciones pequeñas, ediciones de producción obvias o trabajo de UI nativo en código.
• Valida después de construir trabajo visual. Compara la implementación renderizada con el objetivo/referencia bloqueada antes de la entrega. Corrige la desviación de diseño accionable en lugar de tratar la investigación como suficiente.

Configuración de MCP

Esta habilidad es útil por sí sola como metodología de diseño basada en investigación y referencia de oficio. La investigación es obligatoria en cualquier caso — usa las herramientas MCP para investigación de estilos en vivo cuando estén disponibles, de lo contrario investiga con las referencias de oficio incluidas y cualquier referencia proporcionada por el usuario.

El servidor local se ejecuta en Docker:

# Registrar el servidor MCP (Hermes / cualquier cliente MCP stdio)
hermes mcp add designer \
  --command docker \
  --args run --rm -i -v "$HOME/.refero-cache:/cache:ro" \
         designer-mcp:latest node scripts/mcp-entry.mjs

Luego reinicia el gateway (o /reload-mcp) para que las herramientas se registren.

Para una galería en el navegador de los mismos datos — miniaturas, muestras, escalas tipográficas:

cd designer-mcp-docker && docker compose up -d   # http://127.0.0.1:8787

Para obtener los detalles completos de las herramientas, lee references/mcp-tools.md.

Descubrimiento

Antes de investigar, forma un breve brief de diseño. Pregunta solo por la información faltante que cambiaría materialmente el resultado; de lo contrario, haz suposiciones razonables y continúa.

Aclara:

• qué se está diseñando
• plataforma: web, iOS o ambas
• audiencia y nivel técnico
• objetivo principal del usuario
• sensación deseada o dirección de marca
• objeciones/riesgos comerciales o del usuario a superar
• restricciones: marca existente, framework, plazo, accesibilidad, contenido
• si la tarea necesita dirección visual, patrones concretos de UI, lógica de flujo o una combinación
• si la tarea debe ir directamente a código, producir primero opciones visuales, o crear activos generados durante la implementación

Formato del brief:

Diseñando [QUÉ] para [QUIÉN] en [PLATAFORMA].
Objetivo: [OBJETIVO PRINCIPAL DEL USUARIO].
Tono: [SENSACIÓN DESEADA].
Principal objeción/riesgo: [OBJECIÓN].
Debe recordar: [GANCHO O IDEA DISTINTIVA].
Restricciones: [RESTRICCIONES].
Investigación necesaria: [estilos/pantallas/flujos].
Ruta: [construcción directa / exploración visual / auditoría / generación de activos].

Enrutamiento del Flujo de Trabajo

Elige el flujo de trabajo más ligero que pueda producir un resultado de alta calidad.

• Construcción directa: úsalo para pequeñas correcciones de UI, ediciones de producción claras, trabajo en sistemas de diseño existentes o tareas con una fuente concreta que coincidir. Investiga y bloquea la dirección, luego codifica.
• Exploración visual: úsalo cuando el usuario solicite variantes, un nuevo lenguaje visual, un rediseño importante, una página de aterrizaje u otra superficie de alta visibilidad con varias direcciones plausibles. Por defecto, ofrece tres opciones bloqueadas por referencias y pide al usuario que elija; consulta references/visual-workflow.md.
• Auditoría: usa capturas de pantalla o referencias de estilo como evidencia antes de la crítica.
• Generación de activos: usa imágenes generadas solo cuando el bloqueo de referencia requiera medios de mapa de bits que el código, los iconos o los activos existentes no puedan proporcionar fielmente; consulta references/visual-workflow.md.

Enrutamiento de Herramientas

Usa los Estilos Primero para el Trabajo Visual

Usa refero_search cuando el usuario pida diseñar, rediseñar, mejorar, pulir o crear cualquier cosa con un componente visual.

Un estilo es una referencia de diseño semántica extraída de una página web de marketing/producto real. No es una captura de pantalla ni una biblioteca de componentes. Los resultados de búsqueda ofrecen vistas previas; las referencias de estilo completas de refero_get proporcionan guías de diseño como tesis visual, tokens, tipografía, diseño/composición, ritmo de sección, espaciado, elevación, superficies, componentes, tratamiento de imágenes, notas de implementación y reglas de hacer/no hacer.

Cobertura: páginas web de marketing/producto — páginas de aterrizaje, páginas de precios, sitios de marketing de productos, sitios editoriales de marca y sitios web SaaS. Los paneles internos de la aplicación, las pantallas de autenticación, las pantallas de configuración y las pantallas de aplicaciones iOS no están cubiertos como sistemas de estilo. Para tareas de UI de producto, establece el lenguaje visual a partir de los estilos, luego usa las referencias de oficio para la lógica del producto.

Usa los estilos para:

• apariencia y sensación
• dirección de marca
• páginas de aterrizaje y páginas de marketing
• tipografía, paleta, diseño, estructura de sección, espaciado, radio, elevación, superficies
• tratamientos de componentes y, a veces, ejemplos de componentes/código
• tratamiento de imágenes y capturas de pantalla de producto
• inspiración para sistemas de diseño
• hacer que una interfaz genérica se sienta más refinada

Después de encontrar estilos sólidos:

• usa refero_get para obtener los detalles completos
• usa refero_design_md para renderizar un artefacto DESIGN.md portátil
• usa refero_facets para ver qué tipografías, colores, temas e industrias contiene realmente el catálogo antes de comprometerse con una dirección

Para Patrones de Producto y Flujos de Usuario

Esta implementación no tiene capa de pantallas o flujos. Cuando la tarea necesite patrones concretos de UI (un tipo de pantalla específico, un estado de formulario, un diseño de página de precios) o lógica de flujo (incorporación, proceso de pago, cancelación):

• usa las referencias de oficio incluidas — cubren formularios, enfoque, estados vacíos, patrones de incorporación y oficio de conversión
• usa el producto existente del usuario, capturas de pantalla o su sistema de diseño cuando se proporcionen
• sé explícito de que estos están fundamentados en el oficio, no en referencias

No fabriques precedentes que no hayas consultado.

Usa el Flujo de Trabajo Visual para Imágenes y QA

Para generación de imágenes, opciones visuales, activos generados y QA visual, lee references/visual-workflow.md cuando la tarea lo necesite.

Flujo de Trabajo de Investigación

1. Investiga la Dirección Visual con Estilos

Para cualquier tarea de diseño visual, comienza aquí.

Bucle recomendado:

1. Busca 3-5 ángulos visuales diferentes.
2. Incluye una consulta estética amplia.
3. Incluye una consulta de dominio/categoría.
4. Incluye una consulta de marca conocida o producto fuerte cuando sea relevante.
5. Recupera 3-4 estilos sólidos con refero_get; los estilos completos son grandes, así que divide la investigación más grande en varios lotes.
6. Compara lo que cada estilo aporta.
7. Elige una base primaria y toma prestados 1-2 detalles específicos de otros estilos.
8. Bloquea los rasgos distintivos de la referencia primaria antes de la implementación.

Las buenas consultas de estilo y la lista de verificación de extracción completa (qué extraer de cada estilo: tesis, tipo, roles de color, espaciado, diseño, componentes, imágenes, estrategia de medios, reglas de hacer/no hacer) se enumeran en references/research-playbook.md.

Regla de síntesis:

• Estilo primario: estado de ánimo general, densidad y estructura.
• Estilos secundarios: detalles específicos tomados prestados.
• Contexto del usuario: adapta todo al producto, audiencia y tarea.
• No uses el promedio/intersección de todas las referencias. Si una referencia es oscura, una es ácida y una tiene serifa, la respuesta no es crema cálida + naranja apagado + serifa educada.

Nunca presentes el resultado como "copiar X". Preséntalo como una nueva dirección inspirada por varias referencias.

Antes de la implementación, crea un bloqueo de referencia:

Referencia/dirección primaria: [una fuente dominante]
Preservar: [3-5 rasgos que deben sobrevivir: lienzo, tipo, acento, diseño, densidad, medios]
Tomar prestado solo: [1-2 detalles secundarios específicos]
Reglas de rol: [significados de tokens/componentes de origen a preservar, ej. solo CTA, solo código, solo decorativo]
Estrategia de medios: [real/generado/stock/nativo en código/marcador de posición, con relación de aspecto y dirección artística]
Rechazar: [valores predeterminados/promedios que colapsarían la dirección]
Compromisos de token: [fondo, tipo, acento, radio, borde/sombra, tratamiento de imágenes, con roles]

Si la implementación se desvía del bloqueo, detente y corrígelo. No suavices los rasgos distintivos en colores más seguros, tipografías más seguras, radios más suaves o diseños de sección genéricos. El bloqueo de referencia no es clonación; preserva rasgos seleccionados mientras adapta el contenido, la marca y los detalles de interacción al producto del usuario.

Al combinar estilos, asigna a cada fuente un trabajo delimitado. Por ejemplo: una fuente puede ser dueña del lienzo/tipo, otra del tratamiento de la ventana de código y otra del CTA principal. Nunca muevas un token fuera de su rol de origen: los colores de CTA siguen siendo solo para CTA, los colores de sintaxis se quedan dentro del código, los degradados decorativos siguen siendo decorativos, y las reglas de tarjeta/botón mantienen su radio, sombra y comportamiento de estado especificados.

Si el estilo primario está liderado por imágenes, no lo reemplaces con un diseño solo de texto. Si no puedes producir la imagen o gráfico necesario, preserva el espacio con dimensiones estables, relación de aspecto, título/texto alternativo y una breve nota de dirección artística. Construye diagramas simples, iconos, ventanas de código o primitivas geométricas solo cuando coincidan con el estilo de origen.

Para exploración visual sustancial, mockups generados, activos de mapa de bits o QA visual posterior a la construcción, sigue references/visual-workflow.md.

2. Patrones de Producto Sin una Capa de Pantallas

Usa las referencias de oficio cuando la tarea necesite saber qué debe contener una interfaz o cómo los productos reales resuelven un problema específico de UI.

Necesidad	Referencia
Diseño de formularios, estados de enfoque, estados vacíos, tablas, patrones de incorporación	references/craft-details.md
Texto de CTA, señales de confianza, manejo de objeciones, estructura de conversión	references/copywriting.md
Selección de componentes/iconos	references/icons.md
Roles de tipo y decisiones de jerarquía	references/typography.md
Roles de color, contraste, disciplina de paleta	references/color.md

Extrae de estos:

• estructura de diseño
• jerarquía de información
• elecciones de componentes
• patrones de CTA
• patrones de contenido/copia
• estados y casos límite
• tácticas de confianza o conversión
• detalles concretos que vale la pena adaptar

3. Lógica de Flujo Sin una Capa de Flujos

Cuando la tarea tenga múltiples pasos o un usuario cambie de estado a lo largo del tiempo, razona desde el patrón de interacción en lugar de reclamar precedentes:

• punto de entrada y estado de salida
• número de pasos
• decisiones que toma el usuario
• reductores de fricción
• confirmaciones requeridas
• estados de guardado/recuperación
• manejo de errores
• momentos de retención o persuasión
• respuesta del sistema en cada paso

Profundidad de Investigación y Síntesis

Iguala la profundidad al riesgo de la tarea, luego separa los hallazgos en tres grupos: dirección visual (de los estilos), patrón de producto (de las referencias de oficio y del material del usuario) y lógica de flujo (del razonamiento de interacción).

Para la escalera de profundidad por tipo de tarea, los formatos de salida para cada grupo, la plantilla de resumen de investigación y la tabla de registro de decisiones, lee references/research-playbook.md.

Ofimática de Diseño

Después de la investigación, ejecuta como un diseñador de producto senior. Usa las referencias incluidas solo cuando sea relevante; no cargues cada archivo por defecto.

• Tipografía: references/typography.md
• Color: references/color.md
• Movimiento: references/motion.md
• Iconos: references/icons.md
• Formularios, enfoque, imágenes, táctil, rendimiento, accesibilidad: references/craft-details.md
• Copywriting y persuasión: references/copywriting.md
• Comprobaciones anti slop de IA: references/anti-ai-slop.md

...

[truncado para traducción]