Hay un momento en casi todos los proyectos en el que todo parece tranquilo. Las pantallas se ven bien. El flujo conecta. El prototipo se comporta exactamente como lo imaginaste.

Dentro de Figma, todo parece razonable.

Hacés zoom, ajustás espacios, renombrás componentes y pulís detalles. Recorrés el flujo una y otra vez hasta que se siente obvio. En ese punto es fácil creer que lo más difícil ya pasó.

La mayoría de las veces, no es así.

La primera reacción real duele más que los errores

Dos personas revisan juntas una pantalla en una ilustración a lápiz

El verdadero golpe rara vez viene de los desarrolladores o de los límites técnicos. Viene de los usuarios.

Te sentás con alguien y le mostrás el flujo. Explicás la idea, las pantallas, la lógica. Esa persona lo mira como alguien que vive ese proceso todos los días, no como un observador externo.

«En realidad, esto funciona de otra manera».

Y empieza a explicar por qué. Muestra pasos que ocurren por detrás, pequeñas decisiones, soluciones improvisadas y dependencias que nunca aparecieron en las primeras conversaciones. Cosas que pasan antes o después del flujo que diseñaste. Cosas que el cliente o quienes presentaron el proceso no veían del todo o no pensaron en mencionar.

Ese momento pega fuerte. No porque el diseño sea malo, sino porque revela lo incompleto que era el panorama.

Cuando pasa durante las pruebas con usuarios, suele ser una señal de que vas por buen camino. Significa que los vacíos aparecen temprano, mientras todavía estás diseñando y podés cambiar de dirección sin un costo enorme.

Encontrar esos problemas en esta etapa no es un fracaso. Es encontrarlos a tiempo. Es mucho mejor replantear un flujo durante el diseño que descubrir lo mismo cuando todo está construido y cada cambio duele más y avanza más lento.

Diseñar a partir de una verdad prestada

Dos personas conversan sobre un proceso en una ilustración verde a lápiz

Muchos flujos empiezan con la versión de la realidad de otra persona. Un cliente explica cómo funcionan las cosas. Alguien del negocio comparte una visión. Un documento describe un proceso.

Diseñás a partir de esa información. Conectás ideas. Tomás decisiones que parecen lógicas.

Pero esa verdad es prestada. Está filtrada por la presión, la responsabilidad y la distancia del uso cotidiano. Los clientes manejan dinero, contratos, equipos y plazos. Están cerca del producto, pero no siempre de cada detalle de cómo las personas lo usan.

Eso no significa que estén equivocados. Significa que ven el producto desde otro lugar.

Cuando un flujo se derrumba en cinco minutos

Una persona frente a un gran diagrama de pantallas conectadas

Hubo momentos en los que una sola conversación cambió todo. Un flujo que llevó días diseñar de pronto se sentía pesado. Un paso que parecía necesario era ignorado. Una funcionalidad que parecía importante se salteaba sin dudar.

A veces pasa lo contrario. Un detalle mínimo que apenas consideraste resulta ser muy importante. Algo específico, repetitivo o molesto se vuelve central para la experiencia.

Esos momentos incomodan, pero también son un regalo. Muestran la distancia entre cómo imaginamos las cosas y cómo funcionan realmente.

La mayoría de las veces esa distancia no tiene un culpable. Ni el usuario, ni el cliente, ni siquiera el diseñador. A veces nadie lo vio venir. La persona del negocio no lo detectó. El usuario no lo mencionó antes. El diseño no lo hizo visible. Y eso también es parte de construir productos reales.

Pasa seguido con MVPs, primeros prototipos y primeras versiones en producción. Tomás una decisión con la mejor información que tenés y después descubrís que era incompleta. Eso no la convierte en un error que debas esconder. La convierte en un momento para reaccionar.

Lo importante es qué tan rápido te adaptás. Hacer cambios mientras las cosas todavía son flexibles. Mantener las interfaces lo bastante simples para moverlas, ajustarlas y hacerlas crecer. Esa capacidad de reacción me salvó más proyectos que cualquier primera decisión «perfecta».

El costo de aprender demasiado tarde

Una persona entre wireframes de interfaces y una red de conexiones de colores

Cambiar un flujo mientras lo diseñás duele. Cambiarlo mientras lo construís es peor.

Hay una diferencia enorme entre replantear pantallas y rehacer lógica, código y plazos. Cuanto más tarde aprendés, más caro se vuelve el error.

Por eso las conversaciones tempranas importan tanto. No como un paso formal, sino como una forma de romper supuestos antes de que se conviertan en decisiones difíciles de deshacer.

Clientes, usuarios y el tren en movimiento

Personas que comparten un vagón de tren en una ilustración a lápiz

El trabajo de producto rara vez avanza en línea recta. Se parece más a un tren con muchas personas adentro. Diseñadores, desarrolladores, clientes, responsables y usuarios avanzan juntos, cada uno con sus prioridades.

A veces los usuarios están cerca. A veces están lejos. A veces nadie habló con ellos en un buen tiempo.

Como diseñador, terminás en el medio, traduciendo, ajustando y repensando constantemente.

Tenés que decidir sosteniendo muchas ideas, opiniones y realidades al mismo tiempo. Intentás encontrar la mejor dirección posible sabiendo que rara vez será la más linda. Pasa más de lo que se admite.

Hay momentos en los que necesitás dejar de pulir y de forzar que todo se vea bien a primera vista. Lo que funciona visualmente en una pantalla no siempre encaja con los límites técnicos, los hábitos antiguos de los usuarios o la necesidad de adaptarse con el tiempo.

Cada decisión cuesta tiempo y la mayoría también cuesta dinero. Por eso importa elegir tus batallas. A veces necesitás mantenerte flexible y ajustar. Otras veces tenés que ser firme y avanzar con una decisión. Aprender cuándo hacer cada cosa fue una de las partes más difíciles del trabajo para mí.

Figma es donde las cosas se ven bien. Los usuarios reales son donde las cosas se rompen, se ajustan y de a poco encuentran su lugar.

Dos cuadernos con distintos bocetos de interfaces