El PDF del manual de marca tiene 80 páginas, versión 3.2, carpeta de Drive «_FINAL_usar_este». El último story de Instagram lo ha montado alguien con el logo estirado y un color que no está en la guía. Nadie ha abierto el PDF desde el kickoff.
No es un problema de disciplina. Es un problema de formato. Un manual estático describe la marca el día que se entregó. La marca se usa el martes siguiente, en Figma, en un banner, en un componente de la web y en una presentación que alguien duplicó. Si la fuente de verdad es un archivo, ya llegó tarde.
Este artículo distingue el trabajo de branding que sí necesita un documento de lo que tiene que vivir en un sistema: tokens, componentes y reglas que se actualizan. Qué va a Figma, qué va a código, y cómo hacer que el manual de marca se use de verdad.
Por qué el manual de marca en PDF se queda obsoleto
El manual clásico nació para imprenta y para un mundo en el que la marca salía cuatro veces al año. Hoy sale cuatro veces al día. Un PDF captura decisiones. No las ejecuta. En cuanto hay un componente nuevo —un chip, un estado de error, un dark mode— el documento miente o se vuelve un apéndice que nadie mantiene.
Eso no significa tirar el manual. Significa dejar de pedirle que sea el sistema. El PDF (o un Notion bien hecho) sigue siendo útil para relato, territorio, tono de voz y lo que no cabe en un token: por qué existe la marca, qué no es, cómo se firma un comunicado. Lo que es color, tipo, espacio y componente tiene que vivir donde se trabaja.
En Truman lo vemos en rebrands que llegan «cerrados» y se abren el primer sprint de web. El sistema de diseño no es un extra de moda: es el sitio donde la identidad deja de ser lámina y empieza a ser producto. Si quieres el marco de cómo se construye una identidad visual, este artículo es el día después: cuando esa identidad tiene que sobrevivir al uso.
Qué debe vivir en Figma (y no en un PDF)
Figma es la fuente de verdad visual mientras se diseña y se entrega a perfiles que no tocan código: marketing, producto, partners. Ahí van librerías, no láminas. Variables de color, tipografía y spacing. Componentes con variantes (botón, input, card, tag). Ejemplos de layout que se pueden duplicar, no capturas.
En Klapper la marca no podía quedarse en una guía de evento: había web, producto, app y piezas de venta de entradas que se diseñan cada semana. Si el color de «entradas disponibles» vive solo en un PDF, el siguiente banner lo inventa quien llega tarde. En ECO de Teruel y Zaragoza la identidad de un medio se usa en portada, en social y en piezas rápidas. El sistema tiene que dejar hacer, no solo prohibir.
| Pieza de marca | Dónde vive | Por qué |
|---|---|---|
| Relato, tono, territorio | Documento corto | Se lee; no se implementa |
| Color, tipo, grid, logo | Figma + tokens | Se usa al diseñar y al desarrollar |
| Componentes UI | Figma ↔ código | Si solo está en uno, diverge en un mes |
| Plantillas social / ads | Figma o Brandkit | Quien publica no abre el repo |
| Manual de 80 páginas | Solo archivo | Se entrega y se olvida |
Regla práctica: si un diseñador nuevo tarda más de diez minutos en encontrar el botón correcto, la librería no existe. Tienes un archivo de trabajo. La librería se publica, se nombra y se versiona. El PDF no se versiona: se reenvía.
Qué debe vivir en código
La web es el sitio donde más gente ve la marca sin que un diseñador esté encima. Si los tokens no están en código —CSS variables, tokens de Style Dictionary, tema de Tailwind, da igual el stack— la marca de producción es la que un front interpretó una vez. Esa interpretación se fosiliza.
Mínimo viable de sistema en repo: paleta semántica (no solo brand-500), escala tipográfica, radios, sombras, y los cuatro o cinco componentes que salen en todas las páginas. Semántica significa color-danger, no #E23 copiado. El día que cambias el rojo, cambias un token. Si no hay token, cambias 40 archivos y te dejas el estado hover.
El puente: tokens, nombres y alguien que gobierna
El fallo clásico es tener librería en Figma y CSS suelto. El puente son nombres iguales. space-4 es 16 px en los dos sitios. color-text-muted no se llama grey-body en el repo. Sin ese contrato, el «sistema» es una foto.
¿Quién puede cambiar un token de color sin pedir permiso a cinco personas y sin romper la campaña de la semana que viene? Si no hay respuesta, no hay sistema: hay opiniones.
Gobernanza no es un comité semanal. Es una persona (o un dúo diseño + front) con permiso para decir no, un changelog corto y una regla: los atajos de campaña no se cuelan en la librería. La campaña puede ser ruidosa. El componente no. Si cada story inventa un botón, a los seis meses tienes un manual nuevo… otra vez.
Tip técnico: tokens semánticos antes que paleta bonita
Empieza por roles, no por la rampa de 10 verdes. Necesitas bg-page, bg-surface, text-primary, text-muted, border-subtle, action, action-hover, danger. La rampa (50–900) es implementación. Si publicas solo la rampa, cada persona elige un peldaño distinto y la marca se deslavaza con «criterio». En Figma, variables alias que apuntan a primitivos. En código, lo mismo. El PDF, si existe, enseña los alias. Nadie necesita memorizar un hex.
Cómo se usa de verdad (el test del martes)
Un sistema vive si el siguiente encargo se resuelve sin reinventar. El test es vulgar: llega un banner, una landing o una ficha nueva. ¿Se monta con componentes existentes en menos de un día? ¿O se abre un archivo en blanco «porque este caso es especial»? El caso especial es el default si el sistema no cubre el 80% del trabajo sucio.
Formación de una hora con quien va a publicar. Accesos. Un kit de social que no sea un ZIP de 3 GB. Y la norma incómoda: si no está en la librería, no es marca todavía. Se propone, se decide, se entra. El atajo de «ya lo subo y luego lo alineamos» es el PDF del siglo XXI: una excepción que se vuelve estilo.
Cuándo el PDF todavía tiene sentido
Tiene sentido como resumen ejecutivo y como entrega a proveedores que no van a entrar en tu Figma: imprenta tradicional, un partner puntual, un medio que pide «manual en PDF». Diez a veinte páginas. Relato, logo (espacio, usos prohibidos), color, tipo, tono. El resto es lastre.
Un manual de 80 páginas no demuestra rigor. Demuestra miedo a decidir qué es sistema y qué es adorno. La marca seria cabe en una librería y en un documento que se lee en un café.
Si estás en un rebranding, no esperes a «cerrar el manual» para empezar la web. Empieza el sistema en el mismo sprint. El PDF se genera al final, como export, no como origen. Y si el rebrand es solo un logo nuevo con la misma web de siempre, no has cambiado la marca: has cambiado un archivo.
Antes de dar por cerrado un manual, verifica esto
- ¿El documento de relato se lee en menos de 20 minutos?
- ¿Color, tipo y spacing existen como variables en Figma?
- ¿Esos mismos nombres existen como tokens en el repo?
- ¿Hay librería publicada, no solo un archivo de trabajo?
- ¿Un diseñador nuevo encuentra el botón correcto en diez minutos?
- ¿Quién puede cambiar un token y quién no?
- ¿El kit de social y ads sale del mismo sistema, no de un ZIP suelto?
- ¿El PDF, si existe, es un export y no la fuente de verdad?
Preguntas frecuentes sobre manual de marca y sistema vivo
¿Sigue haciendo falta un manual de marca si tienes Figma?
Sí, pero corto. Relato, tono, usos prohibidos del logo y criterios que no son componente. Lo que es color, tipo y UI vive en la librería. El manual no sustituye al sistema; lo explica.
¿Cuál es la diferencia entre un manual de marca y un sistema de diseño?
El manual describe. El sistema ejecuta: tokens, componentes y gobernanza. Un manual puede existir sin producto digital. Un sistema de diseño existe porque hay pantallas que se repiten. Confundirlos es cómo acabas con 80 páginas y una web incoherente.
¿Cuándo hay que actualizar el sistema y no «hacer una excepción»?
Cuando el mismo atajo aparece dos veces. La primera puede ser una campaña. La segunda es una pieza que faltaba. Se entra en librería y en código, se nombra, se documenta en un changelog de tres líneas. Si no, la excepción se vuelve la marca real.
¿Quién debe mantener el sistema: diseño o desarrollo?
Los dos, con un dueño. Diseño propone y cuida la librería. Desarrollo mantiene los tokens y los componentes en producción. Si solo lo tiene uno, diverge. En estudios pequeños, como el nuestro en València, suele ser un dúo explícito, no un comité.
