La distancia entre Figma y el navegador

Un archivo de Figma es una imagen fija de una intención. Enseña una pantalla, quieta, en un tamaño concreto, con un texto de ejemplo que siempre cabe y una fuente que se ve perfecta porque la está pintando un motor de diseño, no un navegador. El navegador es otra cosa: un medio vivo que tiene tiempo, entrada del usuario, red intermitente, un viewport que nunca es el que dibujaste y un motor de render con sus propias reglas. Entre la fotografía y la película hay una distancia. En Sors hemos aprendido a medirla, porque es exactamente ahí donde se decide si un producto se siente bien o solo se ve bien.

Esta reflexión no va de renegar de Figma. Figma es insustituible para pensar en sistemas, para ordenar una jerarquía, para discutir una dirección antes de gastar una línea de código. El problema aparece cuando tratamos la maqueta como si fuera el producto y no como lo que es: un plano. Un plano no es la casa. Y hay decisiones —de motion, de estados, de rendimiento, de responsive de verdad— que no existen en el plano y que, sin embargo, son el 80% de lo que el usuario percibe con el cuerpo. Por eso en el estudio diseñamos y prototipamos cada vez más en el propio navegador.

El handoff no es una entrega: es una traducción

Solemos hablar del handoff como si fuera pasar un paquete de una mano a otra. En realidad es una traducción de un idioma a otro, y como toda traducción, pierde. Lo que se pierde no es menor. Se pierden las curvas de easing, porque en la maqueta la transición es una flecha entre dos frames y en el navegador es una función del tiempo que el usuario puede interrumpir a la mitad. Se pierde el comportamiento del texto real, que se desborda, se parte en dos líneas y descoloca el botón que en Figma estaba centrado con un texto de tres palabras. Se pierde el render tipográfico verdadero: el hinting, el antialiasing, el peso que a 14 píxeles se ve más fino de lo que parecía en una pantalla Retina a 200%. Y se pierden los estados, que en la maqueta se dibujan si te acuerdas y en el navegador existen aunque no los dibujes: hover, focus, active, disabled, loading, vacío, error.

El último 20%

Llamamos «el último 20%» a todo lo que separa una pantalla que se ve terminada de un producto que se siente terminado. Y casi nunca es un 20% de esfuerzo: suele ser la mitad del tiempo del proyecto. El motion es la parte más visible. No es «que tenga animaciones»; es que cada transición tenga una duración honesta —lo bastante rápida para no estorbar, lo bastante lenta para explicar de dónde viene cada elemento—, una curva que no sea la lineal por defecto, y sobre todo que sea interrumpible. Una animación que no puedes cortar a la mitad no es motion, es un vídeo que te retiene. Eso no se decide en Figma; se decide sintiéndolo con el dedo sobre la pantalla.

Debajo del motion está lo menos glamuroso y lo más determinante: el rendimiento y el responsive real. Rendimiento es que la primera pantalla pinte antes de que el usuario dude, que el hilo principal no se bloquee mientras cargamos un shader precioso, que el scroll vaya a 60 fps en el móvil de gama media que tiene la mayoría, no en el portátil del estudio. Responsive real no son tres breakpoints: es un continuo. Es aceptar que el diseño lo dicta el contenido y no un ancho mágico, usar container queries cuando el componente debe reaccionar a su contenedor y no a la ventana, y probar en el rango incómodo —esa tablet en vertical, ese móvil plegado— donde ninguna maqueta llegó a existir. Todo esto es invisible en una imagen fija y evidente en dos segundos de uso.

Diseñar con el material real

Un carpintero no diseña una silla sin tocar la madera, porque la madera tiene veta, se astilla en una dirección y no en otra, pesa. La web también tiene veta: la caja del CSS, la cascada, el modelo de eventos, el coste de repintar. Prototipar en código es diseñar tocando el material en vez de dibujar una idea de ese material. Cuando movemos un componente en el navegador sentimos la latencia de verdad, vemos cómo reflowea el texto de un cliente que escribe títulos de nueve palabras, descubrimos que la sombra preciosa cuesta 12 milisegundos por frame y decidimos con esa información encima de la mesa. La decisión de diseño y la restricción técnica dejan de ser dos conversaciones separadas —una en Figma, otra en el pull request— y pasan a ser la misma.

Una maqueta perfecta produce una confianza falsa. El navegador no te miente: si algo se siente mal, es que está mal.

— Sors

El coste oculto de la fidelidad falsa

Hay una trampa concreta en las maquetas muy pulidas: cuanto más pixel-perfect se ve una pantalla, más confianza genera y menos preguntas provoca. Todo el mundo aprueba, el cliente firma, y la distancia con el navegador se descubre tarde, cuando ya cuesta cara. Entonces llega la conversación que todos conocemos: «¿por qué no se ve como en Figma?». La respuesta honesta es que en Figma nunca se vio, porque en Figma no había texto real, ni un móvil de verdad, ni una animación que se pudiera interrumpir, ni una red lenta. La fidelidad de la maqueta era una promesa que el navegador no había firmado. Ese malentendido no se arregla con más pulido en la imagen fija; se previene enseñando lo antes posible algo que se mueva y se pueda tocar, aunque sea feo.

Cómo cerramos la brecha

No cerramos la distancia con una herramienta nueva, sino con cuatro hábitos. El primero: bajar al navegador pronto, con un prototipo en código en cuanto la dirección está clara, para que las decisiones de motion, estados y rendimiento se tomen con el material delante y no de memoria. El segundo: un vocabulario compartido entre diseño y código —tokens de color, espaciado, tipografía y tiempo— para que un valor signifique lo mismo en la maqueta y en la hoja de estilos, y el handoff sea una conversación y no un lanzamiento por encima del muro. El tercero: tratar el motion y los estados como entregables de primera, no como un detalle que se resuelve al final; si un estado de error no está diseñado, no está terminado. El cuarto, el más barato y el que más ahorra: revisar en dispositivos reales, no en el simulador cómodo del escritorio.

Al final, la distancia entre Figma y el navegador no se elimina: se administra. Figma seguirá siendo donde pensamos la forma y el sistema; el navegador seguirá siendo donde el producto por fin existe, con su peso y su temperatura. Nuestro trabajo como estudio de diseño, código y motion es reducir el tramo que los separa hasta que el salto deje de sorprender a nadie. Cuando ese salto es corto, el cliente no pregunta por qué no se ve como en la maqueta, porque la maqueta ya se movía. Y esa es, para nosotros, la diferencia entre un diseño bonito y un producto que se siente bien en la mano.