Escala tipográfica para UI de producto: tamaños que aguantan en cada pantalla

Una escala tipográfica es un conjunto fijo de tamaños de fuente, cada uno derivado de un tamaño base mediante una razón elegida, que da a una UI de producto una sola jerarquía en lugar de decenas de valores improvisados. Al terminar esta guía tendrás una escala de siete a nueve tamaños, nombrados como tokens, que aguanta del móvil de 320px al monitor de 1440px y supera el zoom del 200% sin que el layout se rompa.

La razón para hacerlo no es orden estético. Es que los tamaños de fuente puestos al azar son la forma más común en que una UI empieza a parecer sin terminar. Un botón a 15px junto a una etiqueta a 14px junto a un título a 22px se lee como ruido, porque el ojo no distingue si las diferencias son intencionadas. Una escala convierte cada tamaño en una decisión ya tomada una vez, así la interfaz habla con una sola voz.

Qué necesitas antes de empezar

• Un tamaño base para el cuerpo de texto. Usa 16px. La web convergió en él hacia 2010 porque un texto más pequeño perjudica la legibilidad a distancia de monitor, y Safari en iOS hace zoom en cualquier campo de formulario por debajo de 16px.
• Una razón. Un solo número entre 1,2 y 1,333 que separa los tamaños.
• Un lugar donde guardar los valores como tokens (custom properties de CSS, una colección de variables de Figma, o ambos mantenidos en sincronía).
• Diez minutos y la disposición a ajustar a mano el extremo pequeño, porque la matemática pura de la razón se rompe ahí.

Paso 1: fija la base en 16px en rem

Declara el tamaño del cuerpo una sola vez, en rem, y deja que todo lo demás lo referencie. rem es relativo al tamaño de fuente de la raíz, así que respeta la configuración del navegador del usuario y crece correctamente bajo zoom. Un tamaño en px ignora esa configuración por completo. Es la mayor diferencia de accesibilidad de toda la escala: las WCAG no imponen un mínimo en píxeles, pero sí exigen que el texto se redimensione al 200% sin pérdida de contenido, y el texto basado en rem lo hace sin esfuerzo.

Paso 2: elige una razón y luego deja de confiar en ella en el extremo pequeño

La razón decide cuánto contraste hay entre tamaños adyacentes. La tercera menor (1,2) mantiene los pasos cerca y encaja en herramientas B2B densas, con muchos datos. La tercera mayor (1,25) es el valor por defecto seguro para la mayoría de las UI de producto. La cuarta justa (1,333) abre una separación más amplia y se lee de forma más editorial, mejor en páginas de marketing que dentro de una app. La referencia Imperavi UI Typography explica bien por qué lo que eliges de verdad es la razón, no los tamaños individuales.

Hay una trampa. Aplicada al pie de la letra, una razón colapsa en el extremo pequeño. Desde una base de 16px, una razón de 1,2 da 13,3px, luego 11,1px, luego 9,3px para los dos pasos por debajo del cuerpo. En una interfaz real son ilegibles. Así que usas la razón para generar el extremo grande y ajustas a mano los dos tamaños por debajo del cuerpo hacia valores legibles. No es hacer trampa. Es lo que hace todo design system maduro.

Paso 3: nombra los tamaños como tokens, nunca como píxeles

La escala de abajo es una tercera mayor en torno a 1,25 ajustada a mano, con una base de 16px. Guarda cada fila como token semántico, no como su valor en píxeles, así un componente referencia --font-size-body y nunca el número literal.

• caption: 13px, interlineado 18px
• small: 14px, interlineado 20px
• body: 16px, interlineado 24px
• body-lg: 18px, interlineado 28px
• title-sm: 20px, interlineado 28px
• title: 24px, interlineado 32px
• heading: 30px, interlineado 36px
• display: 38px, interlineado 44px

Ocho tamaños cubren casi cualquier producto. Si te descubres buscando un noveno, añádelo a propósito arriba para un hero, no en medio para tapar un problema de espaciado. Nombrar por rol en lugar de por tamaño es lo que te permite recalibrar toda la escala más adelante sin tocar un solo componente. La misma idea que el resto de tu arquitectura de design system: el componente pide un trabajo, el sistema responde con un valor.

Paso 4: haz fluidos con clamp() solo los tamaños display

La tipografía fluida con clamp() escala un tamaño de forma continua entre un mínimo y un máximo a medida que cambia el viewport, sin breakpoints. La sintaxis es clamp(MIN, PREFERIDO, MAX), y el valor preferido debe mezclar una unidad de viewport con un término en rem, por ejemplo clamp(1.9rem, 1rem + 3vw, 2.75rem). La parte en rem es lo que mantiene vivo el zoom: un valor solo en vw queda anclado al viewport y se niega a crecer cuando un usuario hace zoom, un fallo de accesibilidad real documentado a fondo por LogRocket y Smashing Magazine.

Aplica el dimensionamiento fluido solo a heading y display. El texto del cuerpo y el de la UI se quedan fijos. Un tamaño de cuerpo fluido deriva mientras la ventana se redimensiona, y en un móvil estrecho puede caer por debajo del umbral legible antes de que lo notes. Los usuarios leen el cuerpo de texto. Le echan un vistazo al texto display. La fluidez pertenece donde está el vistazo, no donde está la lectura.

Paso 5: empareja cada tamaño con un interlineado

El interlineado es parte de la escala, no una decisión aparte. La regla que se sostiene: el texto grande quiere un multiplicador más ajustado, el texto pequeño uno más holgado. El cuerpo a 16px quiere cerca de 1,5 (24px). Un display a 38px quiere alrededor de 1,15 (44px), porque a ese tamaño un multiplicador de 1,5 abre una separación que parte el titular en líneas desconectadas. Guarda el interlineado junto a cada token de tamaño, así el emparejamiento viaja unido y nadie tiene que adivinar.

Paso 6: haz cumplir los límites

Bajo cada escala de producto hay dos límites duros.

• 14px es el mínimo práctico para cualquier texto que un usuario deba leer en escritorio. Los captions a 13px sirven para timestamps y metadatos, no para el contenido.
• 16px es el mínimo para los campos de formulario en móvil. Safari y Chrome en iOS hacen zoom automático en cualquier input con fuente por debajo de 16px al enfocarlo, lo que desplaza el viewport y desorienta al usuario. El arreglo es una línea: pon los inputs a 16px. No recurras a maximum-scale=1 ni a user-scalable=no para suprimir el zoom, porque desactiva del todo el pinch-zoom y viola las WCAG, como CSS-Tricks explicó hace años.

¿Cómo verificas que la escala aguanta?

Tres comprobaciones, en orden. Primero, lleva el zoom del navegador al 200% y confirma que el layout se reorganiza sin recortes ni scroll horizontal. Segundo, abre la misma página a 320px de ancho y confirma que ningún texto del cuerpo ha bajado de 14px y ningún input de 16px. Tercero, entorna los ojos frente a una pantalla real: si no distingues al instante un título de un subtítulo del cuerpo, la razón es demasiado ajustada y los pasos necesitan más contraste. La prueba de entornar los ojos capta lo que las medidas en píxeles no ven.

Errores comunes y cómo resolverlos

• La escala se ve plana. Los tamaños adyacentes están demasiado cerca. O subes la razón o quitas un paso intermedio, para que los tamaños restantes queden más separados.
• Los títulos se sienten holgados y desconectados. El interlineado es uniforme en toda la escala. Ajusta el multiplicador en todo lo que esté por encima de title.
• Los formularios en móvil hacen zoom al tocar. Un input está por debajo de 16px. Súbelo. Es el bug tipográfico más común en el SaaS en producción.
• Los tamaños vuelven con el tiempo a valores arbitrarios. Los componentes escriben píxeles a mano en lugar de referenciar los tokens. Haz lint de los valores font-size crudos que no sean una referencia a un token.

Adónde llevarla después

La escala es una capa de un sistema tipográfico. El peso, el espaciado entre letras y la relación entre font-size y los tokens de espaciado se apoyan todos sobre ella. Si estás decidiendo dónde deben vivir estos valores, los compromisos están en nuestro repaso de las categorías de un design system. La escala es la parte que decide de forma más directa si una UI se lee como terminada, y por eso vale la pena dejarla exacta antes que cualquier otra cosa.