El manual dice «cercanos, claros, sin postureo». En la web el titular suena a manifiesto. En el producto, el error de pago dice «Ha ocurrido un problema inesperado. Inténtelo de nuevo más tarde». Tres voces. Una sola marca, en teoría.
El tono de marca digital no es un adjetivo en la página 40. Es cómo habla el empty state, el email de «tu sesión caducó» y el botón que no puede hacer lo que promete. Si solo vive en la home, no tienes tono: tienes copy de campaña.
Este artículo es cómo pasarlo del trabajo de branding a la interfaz —web y producto— sin que cada pantalla improvise un personaje distinto.
Qué es el tono de marca digital (más allá del adjetivo)
Tono de marca digital es el registro que usas cuando no hay un copywriter encima: el microcopy, el estado vacío, el mail transaccional, el permiso del sistema. No es «personalidad». Es una política de voz. Qué dices, qué no dices, cómo te disculpas y cómo pides el siguiente paso.
El manual sigue haciendo falta para relato y territorio. Eso ya lo desglosamos en manual de marca vs sistema vivo: el PDF explica el porqué; el sistema ejecuta el cómo. El tono es la parte verbal de ese sistema. Si no tiene ejemplos de interfaz, es literatura.
En Truman no entregamos «cercano / profesional» y nos vamos. Entregamos frases de verdad: cómo se llama un error de pago, cómo se despide un email de entrada agotada, cómo se habla cuando el usuario no ha hecho nada todavía. Sin esas frases, el diseño UX/UI rellena con el default del kit. Y el default no es tu marca.
De la web al producto: dónde se oye de verdad
La home es el sitio más fácil. Hay tiempo, hay titular, hay revisión. El tono se pone a prueba en los sitios feos. Un formulario que no valida. Un listado sin resultados. Un mail que dice que la sesión caducó a las 23:40. Ahí no hay storytelling. Hay una persona atascada.
Pasar el tono de la web al producto no es copiar el manifiesto en un modal. Es traducir la misma actitud a piezas cortas. La web puede permitirse un párrafo. El producto, a menudo, una línea y un botón. Si tu tono solo funciona en 80 palabras, no es tono de producto. Es tono de landing.
| Superficie | Riesgo si improvisas | Qué tiene que quedar escrito |
|---|---|---|
| Home y páginas de servicio | Bajo si hay revisión | Promesa, para quién, siguiente paso |
| Errores de formulario y de sistema | Alto | Qué pasó, qué puede hacer, sin jerga |
| Empty states | Medio-alto | Por qué está vacío y la primera acción útil |
| Emails transaccionales | Alto | Asunto honesto, cuerpo corto, un CTA |
| Permisos y legales en UI | Medio | Claro, no infantil; no esconder el coste |
El copy de conversión de la web y el microcopy del producto no son disciplinas enemigas. El primero invita. El segundo acompaña cuando ya estás dentro. Si quieres el criterio de la página que pide el paso, está en copywriting web y conversión. Este artículo es el día después: cuando el usuario ya hizo clic y la marca tiene que seguir hablando.
Error, empty state y email: las tres pruebas
El error es la prueba más dura. El usuario acaba de fallar —o el sistema ha fallado— y no quiere un chiste ni un código. Quiere saber qué ha pasado y qué hacer. «Error 422» no es honesto: es perezoso. «No hemos podido cobrar. Tu tarjeta no se ha tocado. Prueba otra o escríbenos» es tono. Dice la verdad, quita miedo y da salida.
El empty state es la prueba de si la marca sabe enseñar. Una caja vacía con una ilustración y «aún no hay nada» abandona. Un empty state con tono dice para qué sirve esa pantalla y cuál es el primer gesto útil. No vende features futuras. No finge datos. Invita a empezar.
El email transaccional es la marca en la bandeja, sin hero ni vídeo. Asunto que no miente. Cuerpo que se lee en el preview del móvil. Un enlace que hace lo que dice. Si tu tono de web es cálido y el mail de «pedido confirmado» parece un ticket de impresora fiscal, has roto la marca en el momento de más confianza.
Si mañana un error de pago lo escribe alguien de backend a las diez de la noche, ¿suena a vuestra marca o al framework de turno?
Cómo pasarlo del manual a la interfaz
No hace falta un brandbook verbal de 30 páginas. Hace falta un documento corto que se use. En Truman cabe en una sesión y un fichero que diseño y desarrollo tienen abierto.
Principios: cuatro, no doce. Por ejemplo: decimos qué ha pasado; no culpamos al usuario; no hacemos humor con dinero, salud o datos; el siguiente paso va en la misma frase. «Lo que no decimos»: palabrejas de consultora, anglicismos de relleno, urgencia falsa, «oopsie».
Frases reales: un error de red, un error de pago, un vacío de listado, un vacío de primera vez, un mail de bienvenida, un mail de caducidad. No plantillas abstractas. Frases que se pueden pegar. Luego viven en el repo —no en un Notion que nadie abre— junto a los componentes. El tono que no está en código es tono opcional.
Tip técnico: el string no es un leftover del front
Trata los textos de UI como parte del sistema, no como TODO: copy. Un fichero de strings (o un CMS de microcopy) con claves semánticas: error.payment.card_declined, empty.orders.first_time. El diseñador propone, alguien con criterio de marca firma, el front no inventa. Si el componente tiene variantes (error, warning, success), el tono también. Una microinteracción sin voz es un gesto mudo: se ve, no se entiende.
Cómo se oye en Klapper y en Pulso Studio
Klapper no puede hablar igual en la campaña de un festival, en el checkout de la entrada y en el aviso de «este código ya se usó» en puerta. El tono de marca digital aquí es una sola actitud —directa, de operación, sin teatro— aplicada a piezas distintas. Si el mail de confirmación suena a newsletter y el error de acceso suena a log, el organizador y el asistente no viven la misma marca. El producto es el sitio donde eso se nota.
Pulso Studio es el caso inverso en apariencia: una identidad de estudio, web y piezas que tienen que sonar a criterio, no a plantilla de agencia. El tono no se resuelve con un claim. Se resuelve cuando la página de proyecto, el contacto y los estados de la web hablan igual: menos adjetivo, más trabajo visible. Si la home promete oficio y el formulario responde como un plugin, la marca se desmiente sola.
El tono no se demuestra en el manifiesto. Se demuestra en la frase que sale cuando algo falla. Si esa frase no está escrita, tu marca es la del framework.
En València lo vemos cada vez que un rebrand «cierra» y la web o la app se desarrollan en paralelo con otro proveedor de copy. El logo encaja. La voz no. El arreglo no es otra ronda de adjetivos. Es sentarse con las pantallas feas y escribirlas.
Antes de dar el tono por cerrado, verifica esto
- ¿Hay cuatro principios que se pueden aplicar a una línea de UI, no solo a un manifiesto?
- ¿Están escritos el error de pago, el error de red y un 500 con salida útil?
- ¿Cada empty state dice por qué está vacío y cuál es el primer gesto?
- ¿Los emails transaccionales suenan a la misma marca que la home?
- ¿Existe una lista corta de «esto no lo decimos» (humor con dinero, jerga, urgencia falsa)?
- ¿Los strings viven en el repo (o en un CMS) con claves semánticas, no en un hilo?
- ¿Diseño y desarrollo saben quién firma un texto nuevo de interfaz?
- ¿La web y el producto comparten las mismas reglas, aunque las piezas sean más cortas?
Preguntas frecuentes sobre el tono de marca digital
¿Qué es el tono de marca digital?
Es cómo habla la marca en pantallas y correos, no solo en la campaña. Incluye microcopy, errores, empty states y mails transaccionales. Si solo existe como adjetivo en el manual, no es tono digital: es una intención sin frases.
¿El tono de la web y el del producto tienen que ser idénticos?
La misma actitud, distinta longitud. La web puede explicar. El producto tiene que resolver en una línea. Si cambian los valores —una es cercana y la otra burocrática— no es «adaptación al canal»: es una marca partida.
¿Quién debe escribir el microcopy: diseño, marketing o desarrollo?
Quien tenga criterio de marca, con diseño en la mesa. Marketing suele dominar la web; desarrollo no debería inventar el 500. En un estudio pequeño, como el nuestro, lo firmamos en el mismo sprint que el componente. El dueño es uno. El hilo de Slack no es un sistema.
¿Hace falta un brandbook verbal aparte del manual visual?
Hace falta un documento corto y ejemplos de interfaz. No hace falta un PDF de 40 páginas de «personalidad». Principios, prohibiciones y diez frases reales bastan para que el equipo no improvise. El resto es mantenimiento: cada pantalla nueva añade un ejemplo, no un capítulo.
