Sistema de diseño de Framer: qué incluir en estilos, componentes y DESIGN.md

Una decisión de sistema de diseño puede aparecer en varias partes de Framer. Su página oficial de IA indica que el canvas puede refinar la tipografía, los componentes, los breakpoints, el espaciado, el color, los efectos y los layouts. La página también describe componentes de código generados por IA y conexiones con agentes externos. En toda la plataforma, el diseño, el código, la colaboración y la publicación comparten un único entorno de trabajo.

Esas capacidades le indican qué se puede editar. Por sí solas, no deciden dónde debe originarse una regla ni qué prevalece cuando dos capas discrepan. El modelo de responsabilidad y precedencia que se presenta a continuación es un contrato de trabajo para equipos, no un estándar nativo de Framer.

Elija la autoridad basándose en el alcance de la decisión. Una regla que deba prevalecer tras un cambio de página, agente o herramienta de implementación pertenece a una guía portable como DESIGN.md. Implemente un valor reutilizable dentro del proyecto de Framer como un estilo compartido. Cuando una decisión defina una unidad recurrente con estructura o comportamiento, integre dicha implementación en un componente.

Un mapeo no es una segunda autoridad. Por ejemplo, DESIGN.md puede especificar que el texto atenuado utiliza un rol semántico de primer plano. Un estilo de texto de Framer puede implementar ese rol bajo un nombre específico del proyecto. La regla escrita define el significado, mientras que el estilo de Framer define el valor reutilizable local. El registro de entrega (handoff) es lo que los conecta.

Cuando dos capas discrepen, no acepte la que se renderice al final. Rastreé la decisión hasta su autoridad declarada, compruebe si el mapeo derivado está actualizado y clasifique cualquier desviación como una excepción aprobada o un defecto.

1. Compruebe la decisión de autoridad y su alcance.
2. Compruebe el mapeo registrado para el estilo, componente, breakpoint o componente de código de Framer.
3. Compruebe si se permitió explícitamente una excepción más específica.
4. Si la autoridad es ambigua, pause el cambio y asígnelo antes de editar más superficies.
5. Actualice primero la capa propietaria, luego actualice los mapeos afectados y registre la evidencia observada.

Un agente necesita algo más que una solicitud de diseño. Proporcione un registro de aceptación breve que nombre la decisión de autoridad, los consumidores previstos, las superficies sin cambios y la evidencia necesaria para la revisión.

change_id: nav-muted-text
objective: Align secondary navigation text with the declared muted-text role.

source:
  authority: DESIGN.md > Color roles > Muted content
  owner: Design systems owner
  decision: Secondary navigation labels use the muted foreground role.

targets:
  framer_styles:
    - Secondary / Navigation
  components:
    - Site Header
    - Footer Navigation
  representative_pages:
    - Home
    - Pricing
  breakpoints:
    - Desktop
    - Smallest supported phone width

allowed_exceptions:
  - Active navigation item uses the primary foreground role.

must_remain_unchanged:
  - Primary navigation labels
  - Button labels
  - CMS article body text
  - Header spacing and interaction behavior

agent_context:
  include:
    - Relevant DESIGN.md color-role section
    - Target text style
    - Site Header and Footer Navigation components
    - Home and Pricing pages
  exclude:
    - Unrelated pages, CMS content, and global layout changes

evidence:
  intended_change:
    - Before and after capture for each representative page and breakpoint
  unrelated_drift:
    - Comparison of named unchanged surfaces
  unresolved:
    - Record any mapping or behavior that could not be inspected

disposition: pass | revise | block
reviewer:
reviewed_at:

El registro separa la intención de la observación. Se espera que un objetivo listado bajo framer_styles cambie. Su presencia allí no es evidencia de que el mapeo exista o de que el resultado coincida con el origen. Complete la sección de evidencia solo después de la inspección.

Las páginas representativas deben ejercer un uso real de la reutilización. Elija al menos una página donde el objetivo sea prominente y otra donde aparezca en una composición diferente. Para los breakpoints, cubra la condición responsiva con mayor probabilidad de cambiar el componente en lugar de comprobar cada ancho de canvas arbitrario.

Framer describe el contexto del proyecto, los estilos y assets editables, las conexiones con agentes externos y los cambios realizados por el agente. Más contexto no significa automáticamente que sea mejor. Un contexto delimitado facilita la comprobación de si el agente siguió la regla prevista y si se ha colado trabajo no relacionado en la rama.

1. 1

   Seleccione la decisión de origen

   Proporcione la sección pertinente de DESIGN.md u otra autoridad declarada. No envíe una librería completa cuando solo un rol de color o una regla de componente esté dentro del alcance.

2. 2

   Nombre los consumidores de Framer

   Identifique los estilos compartidos, componentes, páginas, capas y breakpoints que se espera que implementen la decisión. Marque los mapeos desconocidos como desconocidos en lugar de adivinar sus nombres.

3. 3

   Indique los objetivos no deseados

   Enumere las superficies cercanas que el agente no debe rediseñar, renombrar, reestructurar o reestilizar. Incluya componentes no relacionados que compartan la página.

4. 4

   Defina la aceptación observable

   Describa lo que un revisor debe ver en las páginas representativas y en breakpoints pequeños. Nombre las superficies no relacionadas que deben permanecer sin cambios.

5. 5

   Abrir un cambio de rama delimitado

   Solicite solo el cambio con nombre. Si el agente encuentra un mapeo faltante o una autoridad ambigua, requiera que informe de la brecha en lugar de inventar un nuevo sistema.

Un lienzo de escritorio con buen aspecto no es evidencia suficiente. Revise el cambio previsto en cualquier lugar donde se reutilice, inspeccione un breakpoint más pequeño y compruebe que no haya desviaciones en superficies no relacionadas. El objetivo es la trazabilidad, no afirmar que una sola revisión certifica todo el sitio.

1. 1

   Confirmar el origen y el mapeo

   Verifique que el resumen de la rama apunte a la decisión autoritativa actual y a los consumidores de Framer previstos. Si falta alguno de los dos, revise el resumen antes de juzgar el renderizado.

2. 2

   Inspeccionar la página representativa principal

   Compruebe el estilo o componente previsto en la página donde su efecto sea más evidente. Registre qué ha cambiado en lugar de confiar en la memoria.

3. 3

   Inspeccionar otro consumidor real

   Abra una segunda página o composición representativa que utilice el mismo estilo o componente. Una discrepancia suele revelar un valor local desvinculado o un componente duplicado.

4. 4

   Comprobar la adaptación responsiva

   Inspeccione el breakpoint nombrado más pequeño y cualquier breakpoint donde la disposición, visibilidad o tamaño cambien intencionadamente. Confirme que la regla base se mantenga, a menos que el resumen permita una adaptación.

5. 5

   Buscar desviaciones no relacionadas

   Compare las superficies enumeradas en must_remain_unchanged. Compruebe los valores de estilo, la estructura del componente, el diseño, el contenido y las interacciones relevantes para el alcance de la rama.

6. 6

   Asignar una disposición

   Aprobar (Pass) cuando los mapeos previstos coincidan y no queden desviaciones dentro del alcance. Revisar cuando haya una discrepancia corregible. Bloquear cuando la autoridad sea ambigua, la evidencia requerida no esté disponible o la rama modifique objetivos no permitidos (non-goals) protegidos.

Cuando una página de Framer parece inconsistente, lanzar otro prompt general a menudo dificulta la interpretación de la evidencia. Recorra las capas en orden de propiedad y deténgase en el primer mapeo no compatible o contradictorio.

1. Decisión de origen: ¿Es el rol o la regla prevista explícita, actual y tiene un propietario?
2. Contexto seleccionado: ¿Recibió el agente la regla, los objetivos, las excepciones y los non-goals pertinentes?
3. Mapeo de estilo compartido: ¿Utiliza el elemento objetivo el estilo de Framer mapeado al rol de origen?
4. Uso de componentes: ¿Está la página utilizando el componente compartido y la variante prevista, o una copia desvinculada?
5. Adaptación de breakpoint: ¿Cambia un override responsivo intencionadamente el valor o la estructura?
6. Código generado: ¿Contiene un componente de código un valor o comportamiento duplicado que entre en conflicto con el origen?
7. Override a nivel de página: ¿Existe un valor local que enmascare la implementación compartida?

Corrija la capa propietaria, no el primer síntoma visible. Si un componente utiliza el estilo compartido incorrecto, corrija el mapeo del componente. Si la regla de origen es realmente errónea, cámbiela a través del proceso normal del sistema de diseño del equipo y actualice entonces cada consumidor afectado. No reescriba el origen simplemente para legitimar un valor local accidental.

El kit público Ambient Sage sirve como ejemplo ya que sus datos de origen son inspeccionables. Su página publicada incluye un DESIGN.md, design tokens semánticos para modo claro y oscuro, una paleta de 31 colores y roles tipográficos. Se utiliza Plus Jakarta Sans para los encabezados y el cuerpo, mientras que JetBrains Mono cumple la función de fuente monoespaciada. El kit también describe superficies en tono sage cálido, tarjetas tonales y un acento amarillo discreto.

Un traspaso (handoff) podría mapear el rol de fondo del kit a un estilo de color de Framer, su rol de cuerpo a un estilo de texto que use Plus Jakarta Sans y su guía de tonal-card a un componente de tarjeta reutilizable. Estos son ejemplos de mapeos, no hechos sobre un proyecto de Framer existente. El propietario del proyecto debe elegir los nombres reales y verificar las páginas resultantes.

El mapa de responsabilidades y el registro de ramas mejoran la trazabilidad. No sustituyen la revisión de un especialista ni prueban que el resultado sea bueno. Una implementación consistente puede seguir aplicando una decisión de diseño errónea de manera consistente.

• No certifica la conformidad de accesibilidad, incluyendo el contraste, el comportamiento del teclado, el tratamiento del foco, la semántica o el soporte para tecnologías asistivas.
• No prueba que cada página, estado de contenido, locale o viewport sea responsivo.
• No evalúa la calidad del código generado, el comportamiento en tiempo de ejecución, el rendimiento, la seguridad o la mantenibilidad fuera del cambio declarado.
• No prueba que un artefacto de origen se haya importado automáticamente o se haya reproducido con paridad visual.
• No autoriza la publicación. La rama aún requiere el proceso normal de revisión y lanzamiento del proyecto.

Mantenga pistas de evidencia separadas cuando el riesgo lo requiera. La conformidad con el sistema de diseño cuestiona si la implementación sigue su fuente declarada. La accesibilidad, la resiliencia, el comportamiento y la preparación para producción requieren sus propias comprobaciones.

Elija una decisión existente que aparezca en más de una página de Framer, como el texto de navegación atenuado o el color de superficie de una tarjeta. Declare su fuente autoritativa, registre el estilo exacto de Framer o el mapeo del componente, nombre dos páginas representativas y un breakpoint pequeño, y luego pruebe un cambio delimitado en una rama. Amplíe el sistema solo cuando el registro sea lo suficientemente claro como para que otro revisor pueda reproducirlo.

• AI Website Builder for Designers & Teams | Framer: Framer documenta páginas editables creadas por IA y la capacidad de refinar diseños, tipografía, componentes, breakpoints, espaciado, color, efectos y componentes de código dentro del proyecto.
• Framer: AI website builder for professional sites: Framer presenta los agentes, el diseño, el código, la colaboración y la publicación como partes de la misma plataforma de creación de sitios web.
• Web Design Tools in Framer: La descripción general del diseño capturada describe el estilo de capas, cuadrículas, stacks, adaptación responsiva de pantalla, fuentes integradas y superficies de colaboración orientadas a breakpoints.
• Kit de diseño Ambient Sage: El kit público Ambient Sage incluye un archivo DESIGN.md, design tokens semánticos para modo claro y oscuro, tipografía Plus Jakarta Sans, JetBrains Mono y varios formatos de exportación para desarrolladores.
• Cómo generar un DESIGN.md (y qué es): Identity Forge define el DESIGN.md como un brief de diseño escrito que abarca la intención, los design tokens, la tipografía, el layout, el tratamiento de los componentes, los motivos y las reglas de uso explícitas para los agentes de código.
• AI UI review checklist: test generated interfaces before you ship: La guía de revisión separa la evidencia de tareas, sistema de diseño, resiliencia y accesibilidad, y recomienda probar estados representativos y cambios controlados antes del lanzamiento.

• AI Website Builder for Designers & Teams | Framer: Framer documenta páginas editables creadas por IA y la capacidad de refinar diseños, tipografía, componentes, breakpoints, espaciado, color, efectos y componentes de código dentro del proyecto.
• Framer: AI website builder for professional sites: Framer presenta los agentes, el diseño, el código, la colaboración y la publicación como partes de la misma plataforma de creación de sitios web.
• Web Design Tools in Framer: La descripción general del diseño capturada describe el estilo de capas, cuadrículas, stacks, adaptación responsiva de pantalla, fuentes integradas y superficies de colaboración orientadas a breakpoints.
• Ambient Sage Design Kit: El kit público Ambient Sage incluye un archivo DESIGN.md, design tokens semánticos para modo claro y oscuro, tipografía Plus Jakarta Sans, JetBrains Mono y varios formatos de exportación para desarrolladores.
• How to generate a DESIGN.md (and what it is): Identity Forge define DESIGN.md como un brief de diseño escrito que abarca la intención, los design tokens, la tipografía, el layout, el tratamiento de los componentes, los motivos y las reglas de uso explícitas para los agentes de código.
• AI UI review checklist: test generated interfaces before you ship: La guía de revisión separa la evidencia de tareas, sistema de diseño, resiliencia y accesibilidad, y recomienda probar estados representativos y cambios controlados antes del lanzamiento.