Por qué una interfaz parece poco profesional: 9 detalles

Una interfaz parece poco profesional cuando sus pequeñas decisiones no encajan entre sí: tres radios de esquina distintos en la misma pantalla, iconos sacados de dos colecciones, un precio que se desplaza hacia un lado cada vez que se actualiza. Ninguno de estos detalles es un bug. Juntos le dicen a quien usa el producto que nadie lo revisó, y esa impresión se forma antes de probar una sola función.

Esa impresión se ha medido. En un estudio de Stanford en el que varias personas comparaban la credibilidad de webs reales, el aspecto visual fue el factor que más se mencionó, en el 46,1 % de los comentarios, por delante de cómo estaba estructurada la información. El estudio es de 2002 y la web ha cambiado desde entonces. El resultado, en cambio, coincide con lo que vemos en las revisiones: el cuidado en los detalles se lee como atención, y la atención como señal de que el producto va a funcionar.

Esta lista es la revisión que hacemos en una pantalla antes de darla por terminada. Los temas más amplios tienen su propio artículo: la escala tipográfica, la jerarquía sin color y la alineación óptica. Los nueve detalles de abajo son los que se escapan cuando todo eso ya está bien.

Cómo elegimos los nueve detalles

Cada detalle cumple tres condiciones. Alguien de fuera del equipo lo nota en pocos segundos, aunque no sepa ponerle nombre. Se puede comprobar en una pantalla terminada, a ojo o con las herramientas de desarrollo del navegador. Y se corrige con una regla, un token o una propiedad CSS, de modo que sigue corregido una vez que el componente lo incorpora. Cuando un estándar público fija un umbral (WCAG 2.2, Core Web Vitals), damos la cifra y la fuente.

¿Qué detalles hacen que una interfaz parezca sin terminar?

1. Espaciados fuera de escala

Si se miden los huecos de una pantalla en borrador, es habitual encontrar 13, 14, 15 y 18 píxeles haciendo el mismo trabajo. Cada valor parecía correcto cuando alguien lo escribió. Juntos crean un ritmo que el ojo percibe como irregular, aunque no sepa explicar por qué.

La solución es una escala de espaciado, normalmente sobre una base de 4 u 8 píxeles, expuesta como tokens para que nadie escriba un número a mano. Encima, una regla: los elementos relacionados van más juntos que los que no lo están. Una etiqueta pertenece a su campo, así que va más cerca de él que del campo de arriba. Cuando un hueco necesita una excepción para verse bien, es una corrección óptica: se escribe en el componente, no en un margen suelto.

2. Radios de esquina que no encajan

Un botón con un radio de 16 píxeles dentro de una tarjeta con el mismo radio, a 8 píxeles del borde, tiene unas esquinas que chirrían. Las dos curvas no van en paralelo y la forma interior parece hinchada.

La regla que usan los diseñadores: el radio exterior es igual al radio interior más el padding que los separa. Un botón de 12 píxeles con 8 píxeles de padding pide una tarjeta de 20. La fórmula es un punto de partida que conviene revisar a ojo, porque con radios interiores muy pequeños el resultado puede quedar demasiado redondo. La otra mitad de la solución es una escala corta, de tres o cuatro valores, para que una pantalla no acabe acumulando seis.

3. Iconos que no casan con el texto

Los iconos sacados de dos librerías traen dos grosores de trazo, dos estilos de esquina y dos ideas distintas de cuánto deben ocupar dentro de su caja. Junto al texto, la diferencia salta a la vista. Un icono de 24 píxeles al lado de un texto de 14 grita. Un trazo de 2 píxeles junto a una tipografía ligera pesa demasiado.

Hay que usar una sola colección de iconos. El tamaño del icono se ajusta a la altura de línea del texto que acompaña, y el trazo al peso de ese texto. Después, la alineación vertical se revisa a ojo: el icono está centrado en su caja y el texto en su altura de x, así que un icono centrado según los números suele verse un píxel demasiado alto. Es el mismo tipo de ajuste que tratamos en el artículo sobre alineación óptica.

4. Números que bailan

La mayoría de las tipografías para interfaz usan cifras proporcionales por defecto: el 1 es más estrecho que el 8. Dentro de una frase no pasa nada. En una columna de tabla, en un total que se actualiza o en una cuenta atrás sí es un problema. Las cifras no se alinean y un número que cambia en su sitio se desplaza hacia un lado con cada actualización.

Basta con una propiedad CSS. font-variant-numeric: tabular-nums cambia a cifras del mismo ancho, y funciona en todos los navegadores principales desde enero de 2020. Se aplica a tablas, precios, temporizadores y a cualquier número que cambie mientras alguien lo mira. Luego, las columnas numéricas se alinean a la derecha para que las unidades queden bajo las unidades. Es una línea de código, y gracias a ella un dashboard parece terminado.

5. Estados de interacción que faltan

Un borrador suele diseñar cada control en reposo y quedarse ahí. Un control listo para producción necesita más: hover, pulsado, foco desde el teclado, desactivado, cargando. Un botón que no responde al clic parece roto. Un formulario que pierde el indicador de foco parece a medias para cualquiera que navegue con el teclado.

WCAG 2.2 marca el mínimo. El foco del teclado tiene que verse, y el elemento que lo recibe no puede quedar tapado del todo por contenido de la propia página, como una cabecera fija o un banner de cookies. Los objetivos táctiles o clicables deben medir al menos 24 por 24 píxeles CSS, o tener alrededor espacio suficiente para que un círculo de 24 píxeles centrado en cada uno no toque a los vecinos. Los dos criterios son de nivel AA. Los estados se diseñan dentro del componente, así cada instancia los hereda.

6. Texto que salta de línea mal

Un titular que deja una sola palabra en la segunda línea. El título de una tarjeta que en inglés ocupa una línea y en alemán tres. El nombre largo de un cliente que empuja fuera de la tarjeta el botón de al lado. Los borradores usan textos de la longitud que eligió el diseñador. Los textos reales llegan con cualquier longitud.

Para los titulares, text-wrap: balance iguala la longitud de las líneas, y lo admiten todos los navegadores principales. Para los párrafos, text-wrap: pretty evita la última palabra suelta; donde el navegador no lo admite, el texto se corta igual que antes, así que añadirlo no rompe nada. Para todo lo que viene de los datos, la regla se decide de antemano: truncar con puntos suspensivos y mostrar el valor completo al pasar el ratón, permitir dos líneas o dejar que el layout crezca. Después se prueba con el valor real más largo que haya, nunca con el medio.

7. Un layout que salta mientras carga

La página aparece, alguien va a pulsar un botón, encima se carga una imagen y el botón se mueve. Pocas cosas hacen que un producto parezca tan barato. Google lo mide como Cumulative Layout Shift, y una buena puntuación es 0,1 o menos en el percentil 75 de las cargas.

Casi siempre hay tres causas: imágenes sin dimensiones, contenido que se inserta encima de lo que ya está en pantalla y fuentes web que entran con otro tamaño. A cada imagen y vídeo hay que darle los atributos width y height, o un aspect ratio, para que el navegador reserve el espacio. Los estados de carga deben tener el tamaño de lo que van a contener, por ejemplo una fila esqueleto tan alta como una fila real. El espacio para los banners se reserva antes de que lleguen. Nuestra guía de Core Web Vitals en Next.js entra en los detalles del framework.

8. Texto gris que nadie puede leer

Un texto secundario gris claro parece elegante en una herramienta de diseño, sobre un monitor calibrado. En un portátil a plena luz del día desaparece. Lo mismo pasa con los bordes de los campos tan suaves que cuesta encontrar el campo.

WCAG da cifras para los dos casos. El texto normal necesita un contraste de al menos 4,5:1 con su fondo, y el texto grande 3:1. Las partes visuales que identifican un control, como el borde de un campo o el contorno de una casilla, necesitan 3:1 respecto a los colores de al lado. La escala de grises se construye con esas proporciones decididas desde el principio, así el token del texto secundario las cumple por diseño. También ayuda tener menos grises: una pantalla con siete grises casi iguales parece improvisada, y tres o cuatro pasos bastan para casi cualquier interfaz.

9. Textos y datos de relleno

"Sin título", lorem ipsum, un botón que dice "Enviar", una tabla en la que cada fila tiene un nombre ordenado y tres elementos exactos. Los borradores están llenos de contenido que nunca debía publicarse, y parte de él se publica. Los datos son el caso más sutil: el diseño muestra 3 elementos y en producción llegan 0, 1 y 4.000.

Antes de cerrar una pantalla, hay que probarla con los casos límite: sin datos, un solo elemento, una lista muy larga, un nombre muy largo, una imagen que falta, un error. Cada uno necesita una respuesta diseñada, que es el tema del artículo sobre estados vacíos. Luego se relee cada etiqueta como la leería el usuario. "1 elementos" y un "Enviar" genérico son detalles pequeños, y los dos se notan. Para los recuentos, Intl.PluralRules elige la forma plural correcta en cada idioma en el que sale el producto.

¿Por qué correcciones conviene empezar?

Los nueve detalles no cuestan lo mismo. Agrupados según cuánto cambian la impresión por cada hora de trabajo:

• Una línea de CSS: cifras tabulares, titulares equilibrados, dimensiones de las imágenes. Se pueden publicar hoy.
• Un token: la escala de espaciado, la escala de radios, una escala de grises con el contraste ya calculado. Cuando los componentes leen los tokens, mejoran todas las pantallas a la vez.
• Un componente: estados de interacción, tamaño de los iconos, reglas de truncado. Se corrigen una vez en el componente y cada instancia los hereda.
• Un hábito de revisión: datos en casos límite y textos reales. El código no lo resuelve: va en la definición de "terminado" del equipo.

La lógica detrás de la agrupación: un detalle que se corrige a mano en una pantalla vuelve a aparecer en la siguiente. Un detalle corregido en un token o en un componente se queda corregido. Por eso estos problemas se acumulan con el tiempo en los productos sin un sistema, el component drift del que ya hemos escrito.

¿Cómo se revisa una pantalla en diez minutos?

Hacemos esta revisión en cada pantalla antes de publicarla. Solo hace falta un navegador.

1. Se reduce el zoom al 50 % y se entornan los ojos. Los huecos irregulares y los radios fuera de sitio aparecen antes que el contenido.
2. Se hace clic en la barra de direcciones y se recorre toda la página con la tecla Tab. Cada control debe mostrar el foco, y ninguno debe desaparecer detrás de un elemento fijo.
3. En las herramientas de desarrollo se limita la red con un perfil móvil lento y se recarga. Hay que fijarse en todo lo que se mueve.
4. Se cambia un nombre por el valor real más largo de la base de datos, y una lista por una vacía.
5. Se mide el contraste del texto más claro y del borde más suave.
6. Se leen en voz alta todas las etiquetas de los botones.

Seis comprobaciones llevan unos diez minutos, y detectan casi todos los nueve detalles antes de que los detecte un usuario.