Kit de marca para desarrolladores web

Las guías de marca generales cubren razonablemente la investigación, el posicionamiento, la identidad, la voz y la aplicación. El handoff para desarrolladores comienza más tarde. Su función es traducir la dirección de marca aprobada en decisiones para el sitio web, sin pedir al implementador que invente reglas de diseño o políticas faltantes.

Mantenga separados seis tipos de material. Los activos de identidad tradicionales incluyen logotipos, marcas, colores de marca, tipografías, fotografía, ilustración y guía verbal. Las decisiones de diseño del sitio web asignan esos materiales a roles semánticos, escalas, layouts, modos y reglas de uso. Los requisitos del producto definen el comportamiento, los permisos, la validación, el contenido y la recuperación. Los artefactos de entrega trasladan las decisiones de diseño aprobadas a un repositorio o herramienta. Los consumidores implementados son los componentes y superficies que leen esos artefactos. La evidencia de aceptación registra qué se comprobó y qué permanece sin resolver.

Registre cada decisión como una cadena desde la autoridad hasta la evidencia. Esto expone dos errores comunes: tratar la exportación más reciente como la fuente de verdad y tratar un valor de token correcto como prueba de que la interfaz lo utiliza correctamente.

• Artefacto: el activo, regla, grupo de tokens, archivo o referencia bajo revisión.
• Fuente de verdad: la ubicación y versión aprobada que tiene autoridad sobre la decisión.
• Propósito semántico: lo que la decisión significa en la interfaz, no simplemente su valor visual.
• Formato de entrega: cómo llega la decisión al proyecto, como guía escrita, tokens DTCG, variables CSS, un tema de Tailwind o un elemento de registro.
• Consumidor previsto: el componente, plantilla, agente, herramienta de construcción o capa de estilo de tiempo de ejecución que se espera que lo utilice.
• Responsable: la persona o equipo autorizado para resolver ambigüedades o aprobar un cambio.
• Cambios permitidos: transformaciones que el implementador puede realizar sin solicitar aprobación.
• Omisiones conocidas: roles, modos, estados, breakpoints, activos o reglas requeridos que la fuente no define.
• Evidencia de aceptación: la superficie, estado, viewport, modo y resultado observable utilizado para verificar la implementación.

artifact: ""
status: ready-to-implement | requires-decision | reference-only | outside-handoff
source_of_truth:
  location: ""
  version_or_date: ""
  approved_by: ""
semantic_purpose: ""
delivery:
  format: ""
  path_or_identifier: ""
intended_consumers:
  - ""
owner: ""
permitted_changes:
  - ""
known_omissions:
  - ""
acceptance_evidence:
  surfaces:
    - ""
  states:
    - ""
  viewports_or_containers:
    - ""
  color_modes:
    - ""
  expected_observation: ""
notes: ""

El campo de estado controla qué sucede a continuación. Evita que una imagen de referencia adquiera autoridad accidental y mantiene los requisitos no definidos fuera de la cola de implementación.

• Listo para implementar: la autoridad, el propósito semántico, el consumidor, los cambios permitidos y las condiciones de aceptación pertinentes son explícitos.
• Requiere una decisión: la entrada es relevante, pero falta al menos una regla material o es contradictoria. Asigne un responsable y bloquee solo el trabajo afectado.
• Solo referencia: el elemento comunica dirección o contexto, pero no es lo suficientemente preciso para regir la implementación. Los mood boards y las maquetas de campaña suelen pertenecer aquí.
• Fuera del handoff del sitio web: el elemento pertenece a otra disciplina o entregable, como la revisión de marcas registradas, la planificación de campañas, los permisos del producto o la redacción editorial final. Registre este límite para que su ausencia no se confunda con una tarea de desarrollo.

La clasificación es granular. Un paquete de logotipos puede estar listo para su ubicación mientras que su tamaño mínimo en anchos reducidos aún requiera una decisión. Un sistema de color puede estar listo para el modo claro mientras que el modo oscuro siga sin definirse. Dividir el registro de esta manera permite que el trabajo continúe sin ocultar la parte no resuelta.

Los colores puros son ingredientes. El código del sitio web necesita roles como fondo de página, primer plano, tarjeta, superficie tenue, borde, acción primaria, acción destructiva, anillo de enfoque y colores de estado. Cada combinación de primer plano y superficie necesita un uso previsto. Si se admiten los modos claro y oscuro, registre ambos mapeos e indique si un modo puede recurrir a otro valor.

No derive los colores de error, advertencia, éxito, selección o enfoque de un color de acento de la marca a menos que la autoridad asigne esos significados. El mismo valor hexadecimal puede ser válido como color de campaña y erróneo como rol de interfaz.

Registre la familia para cada rol, los pesos aprobados, la escala tipográfica, las reglas de interlineado, el espaciado entre letras, las fuentes de respaldo (fallbacks) y dónde se permiten las fuentes mono o de display. El nombre de una familia tipográfica por sí solo deja que el navegador y el desarrollador elijan los pesos y las métricas. Tampoco dice nada sobre encabezados, cuerpo de texto, etiquetas, botones, tablas o datos numéricos.

La entrega de fuentes es una decisión de implementación independiente. El kit de marca puede aprobar familias y roles mientras que el proyecto aún necesite una estrategia de carga, archivos disponibles, fallbacks y comprobaciones de rendimiento. Esas elecciones técnicas deben preservar los roles aprobados sin fingir que el handoff visual resolvió cada compromiso de entrega.

Especifique la escala de espaciado, los márgenes de página, los anchos de contenido, el ritmo de sección, el comportamiento de la cuadrícula, los radios de esquina, los bordes, las sombras y los motivos recurrentes que hacen que el sistema sea reconocible. Nombre las excepciones. Si un motivo es decorativo, indique dónde puede aparecer y cómo se comporta en contenedores restringidos.

Para los logotipos, registre las variantes aprobadas, el espacio libre, el tamaño mínimo útil, las restricciones de fondo y si se permite el recorte o el cambio de color. Para la fotografía e ilustración, incluya reglas de selección y tratamiento en lugar de solo una carpeta de ejemplos. El texto alternativo y el significado del contenido siguen dependiendo del contexto real de la página; una biblioteca de activos de marca no puede suministrarlos de forma universal.

Los breakpoints, el comportamiento del contenedor, el reflow, el truncamiento, los cambios de navegación, la densidad y los objetivos táctiles son decisiones del sitio web. Los estados de hover, enfoque, presionado, seleccionado, deshabilitado, carga, éxito, vacío y error necesitan requisitos donde el producto pueda alcanzarlos. Un tablero de marca estático no define esos comportamientos.

El handoff puede definir el tratamiento visual de botones, inputs, tarjetas, navegación, tablas, gráficos y diálogos. No define automáticamente qué hacen esos componentes. Los permisos, la validación, la confirmación, la cancelación, el manejo de datos y la recuperación pertenecen a los requisitos del producto. Mantenga esa autoridad separada incluso cuando ambos tipos de reglas aparezcan en la misma interfaz.

El kit público de Ambient Sage muestra cómo se pueden conectar varias capas de handoff. Asigna Plus Jakarta Sans a los roles de encabezado y cuerpo, con pesos 400, 500, 600 y 700. JetBrains Mono llena el rol mono en los pesos 400, 500 y 700. La escala publicada es compact-product. Su sistema de color incluye roles semánticos para los modos claro y oscuro, mientras que la guía escrita describe un lienzo warm-sage, un tratamiento de tarjeta tonal, un acento amarillo restringido y valores numéricos sobredimensionados.

Esto es más útil que una lista de fuentes porque vincula familias con roles y pesos, y más útil que una paleta porque proporciona mapeos semánticos y guías de uso. El mismo kit está disponible a través de DESIGN.md, JSON de tokens DTCG, variables CSS, salidas de Tailwind, JSON del registro de shadcn, una ruta de instalación del registro, la CLI de Identity Forge y acceso MCP.

El ejemplo tiene límites firmes. No demuestra que Plus Jakarta Sans y JetBrains Mono sean la mejor combinación para otro producto. No establece el comportamiento de los componentes, las reglas responsivas, los requisitos de contenido, la conformidad de accesibilidad o la preparación para producción de otro producto. Esas decisiones aún necesitan responsables locales y evidencia.

Un artefacto de entrega debe transportar una decisión aprobada sin convertirse silenciosamente en la autoridad que la creó. Registre qué fuente produjo el artefacto, cuándo se generó y qué consumidor lo lee. Si una exportación y su fuente discrepan, resuelva la fuente o la ruta de regeneración antes de parchear el componente visible.

• DESIGN.md contiene la intención, las reglas de uso, la guía de diseño, los motivos, los tratamientos de componentes y las restricciones que son difíciles de expresar como valores de token.
• Los tokens DTCG proporcionan una representación estructurada que puede alimentar herramientas o transformaciones mientras conservan los nombres y valores de los tokens.
• Las variables CSS exponen los valores del tema directamente a los estilos y componentes. Su presencia no demuestra que cada componente haga referencia al rol correcto.
• La salida de Tailwind mapea las decisiones en las convenciones de utilidad y tema del proyecto. Las utilidades locales aún pueden anular o omitir el mapeo.
• Un elemento del registro de shadcn empaqueta valores para una ruta de instalación compatible. Sigue siendo un mecanismo de entrega, no una evidencia de que los componentes instalados satisfagan cada regla de marca.
• El acceso por CLI aplica o escribe artefactos en un proyecto. El acceso MCP permite que un agente compatible descubra, lea o aplique la información del kit. En cualquier caso, el proyecto receptor sigue necesitando una autoridad declarada y un registro de aceptación.

Elija superficies que ejerciten diferentes roles en lugar de revisar cada ruta superficialmente. Incluya los modos, estados y anchos de contenedor que el producto realmente soporta.

• Navegación: tratamiento del logotipo, estado activo, jerarquía, enfoque y comportamiento en anchos reducidos.
• Encabezados y cuerpo de texto: mapeo de roles, pesos permitidos, longitud de línea, ajuste de texto y ritmo vertical.
• Formularios: etiquetas, inputs, texto de ayuda, validación, controles deshabilitados, enfoque y estados de recuperación que estén dentro del alcance.
• Botones y enlaces: tratamientos primarios, secundarios, destructivos, presionados, deshabilitados y de enfoque donde sea necesario.
• Tarjetas y superposiciones: roles de superficie, combinaciones de primer plano, bordes o separación tonal, radio, espaciado y apilamiento.
• Tablas o métricas: jerarquía de encabezados, tratamiento numérico, alineación, densidad, valores largos y estados vacíos.
• Estados de estado: roles de éxito, advertencia, error, selección y carga, sin inventar significados a partir de colores decorativos.
• Modos claro y oscuro: paridad semántica, legibilidad, anulaciones locales y componentes que conservan un valor bruto de modo claro.
• Contenedores estrechos: ajuste de línea, reflujo, recorte, cambios de navegación y motivos que compiten con el contenido.

Una captura de pantalla puede revelar una discrepancia, pero rara vez identifica al responsable. Rastree una decisión aprobada a través de la cadena completa. Un cambio controlado hace visibles las capas obsoletas o ignoradas.

1. 1

   Elegir una decisión aprobada de bajo riesgo

   Utilizar un token reversible o un mapeo de tipografía que tenga un origen claro y un consumidor representativo. Registrar la versión actual del origen y las superficies previstas.

2. 2

   Confirmar el registro autoritativo

   Verificar el propósito semántico, los modos permitidos, el responsable y el valor o regla prevista. Si la autoridad es ambigua, detener la prueba y resolver primero esa ambigüedad.

3. 3

   Regenerar o actualizar el artefacto de entrega seleccionado

   Utilizar la ruta de entrega normal. Registrar la versión del artefacto o el cambio resultante para poder distinguir una exportación obsoleta de una implementación incorrecta.

4. 4

   Inspeccionar el consumidor previsto

   Confirmar que el componente o la capa de estilo pertinente lee el rol semántico. Buscar valores brutos, alias, constantes copiadas, valores predeterminados del framework y anulaciones locales.

5. 5

   Comprobar superficies representativas

   Inspeccionar el estado, el viewport, el contenedor y el modo de color aplicables. Registrar tanto el cambio previsto como cualquier superficie que no haya cambiado.

6. 6

   Clasificar cada discrepancia por capa

   Una decisión de origen errónea vuelve al responsable del diseño. Una exportación obsoleta vuelve al proceso de entrega. Un mapeo incorrecto pertenece a la integración del consumidor. Una anulación local pertenece a la implementación. Un cambio en otro lugar puede ser una deriva no relacionada y no debe incluirse en la corrección de marca sin pruebas.

7. 7

   Restaurar o aprobar el valor controlado

   Volver al valor aprobado, a menos que la prueba en sí fuera una actualización autorizada. Conservar el registro de evidencias en cualquier caso.

Finalizar la recepción con una decisión explícita. La aprobación debe limitarse a las decisiones y superficies respaldadas por la evidencia, no redactarse como una afirmación general de que la marca o el sitio web están completos.

decision: approve | revise | block
scope:
  decisions: []
  consumers: []
  surfaces: []
  modes: []
  viewports_or_containers: []
resolved_evidence:
  - decision: ""
    source_of_truth: ""
    delivery_artifact: ""
    observed_result: ""
unresolved:
  - issue: ""
    classification: missing-decision | stale-artifact | consumer-mapping | local-override | unrelated-drift
    owner: ""
    required_evidence: ""
    next_action: ""
    blocks: ""
permitted_implementation_step: ""
reviewed_by: ""
reviewed_on: ""

El siguiente paso de implementación debe derivarse directamente de este registro. Aplicar el artefacto aprobado cuando la cadena esté completa. Solicitar una decisión nominal cuando falte la autoridad. Corregir la capa de entrega o del consumidor identificada cuando el origen ya sea correcto. Esto evita que el desarrollador convierta una duda de marca no resuelta en una convención local permanente.

• How To Build a Brand From Scratch (2026): Shopify presenta el kit de marca y la guía de estilo dentro de un proceso más amplio que también cubre la investigación de la audiencia, la voz, el naming, la historia, la creación del logotipo, la aplicación y la medición.
• What is a Brand? Definition and Examples: Ramotion describe los componentes de marca a través de la identidad visual, la identidad verbal, las experiencias de interacción, los valores y el posicionamiento, demostrando que una marca va más allá de un logotipo.
• What is Branding? Understanding Its Importance: HubSpot cubre la estrategia de marca, los activos visuales, la voz y la aplicación en sitios web y otros canales como parte de un proceso de branding más amplio.
• Kit de diseño Ambient Sage: El kit público de Ambient Sage documenta Plus Jakarta Sans para los roles de encabezado y cuerpo, JetBrains Mono para el rol mono, design tokens semánticos claros y oscuros, guías escritas y varios formatos de entrega para desarrolladores.
• Cómo generar un DESIGN.md (y qué es): Identity Forge describe el DESIGN.md como un brief de diseño escrito que contiene la intención, los sistemas de color y tipografía, las reglas de diseño y espaciado, el tratamiento de los componentes, los motivos y las restricciones de uso explícitas.
• Explicación de los design tokens de color semánticos: Identity Forge explica que los tokens semánticos nombran los colores según su propósito —como fondo, primer plano, primario, borde y anillo— en lugar de por su tono bruto.
• Lista de verificación para la revisión de UI con IA: pruebe las interfaces generadas antes del lanzamiento: La guía de revisión separa los requisitos del producto, la autoridad de diseño, los artefactos de entrega, la evidencia de implementación y la evidencia de accesibilidad, y recomienda rastrear los cambios controlados hasta la capa responsable de cualquier discrepancia.
• Generadores de sistemas de diseño de shadcn/ui: ¿necesita un tema, un sistema o un handoff para un agente?: Identity Forge distingue un tema visual de un sistema de diseño más amplio y de un handoff para un agente, y recomienda inspeccionar el significado de los tokens, la paridad de modos, la tipografía, las guías de diseño, las rutas de instalación y las lagunas conocidas.

• How To Build a Brand From Scratch (2026): Shopify presenta el kit de marca y la guía de estilo dentro de un proceso más amplio que también abarca la investigación de la audiencia, la voz, el naming, la narrativa, la creación del logotipo, la aplicación y la medición.
• What is a Brand? Definition and Examples: Ramotion describe los componentes de marca a través de la identidad visual, la identidad verbal, las experiencias de interacción, los valores y el posicionamiento, demostrando que una marca va más allá de un logotipo.
• What is Branding? Understanding Its Importance: HubSpot cubre la estrategia de marca, los activos visuales, la voz y la aplicación en sitios web y otros canales como parte de un proceso de branding más amplio.
• Ambient Sage Design Kit: El kit público de Ambient Sage documenta Plus Jakarta Sans para los roles de encabezado y cuerpo, JetBrains Mono para el rol mono, design tokens semánticos claros y oscuros, guías escritas y varios formatos de entrega para desarrolladores.
• How to generate a DESIGN.md (and what it is): Identity Forge describe el DESIGN.md como un brief de diseño escrito que contiene la intención, los sistemas de color y tipografía, las reglas de diseño y espaciado, el tratamiento de los componentes, los motivos y las restricciones de uso explícitas.
• Semantic color tokens explained: Identity Forge explica que los tokens semánticos nombran los colores según su propósito —como fondo, primer plano, primario, borde y anillo— en lugar de por su tono bruto.
• AI UI review checklist: test generated interfaces before you ship: La guía de revisión separa los requisitos del producto, la autoridad de diseño, los artefactos de entrega, la evidencia de implementación y la evidencia de accesibilidad, y recomienda rastrear los cambios controlados hasta la capa responsable de cualquier discrepancia.
• Shadcn design system generators: do you need a theme, a system, or an agent handoff?: Identity Forge distingue un tema visual de un sistema de diseño más amplio y de un handoff para un agente, y recomienda inspeccionar el significado de los tokens, la paridad de modos, la tipografía, las guías de diseño, las rutas de instalación y las lagunas conocidas.