Wireframing y prototipado que sobrevive a ingeniería

La primera vez que me ocurrió, casi lo dejo.

Había dedicado tres semanas a un flujo de configuración. Un archivo de Figma impecable. Cada pantalla. Hasta un estado de hover en el cargador de avatar porque me importaba. Ingeniería lo construyó. El estado vacío era un cuadro gris sin vida con la palabra "Vacío" en Arial de 12px. El toast de error era la barra roja predeterminada del navegador. La carga era un spinner genérico que aparecía al instante, incluso en desarrollo local donde la petición tardaba 40ms. ¿El mensaje de validación? Un tooltip nativo de <input> HTML que decía "please match the requested format."

Le envié un mensaje al ingeniero. Dijo, con calma, "no lo especificaste." Me enfadé. Volví al archivo de Figma. Tenía razón. No lo había hecho.

Esa conversación es el motivo completo por el que existe esta guía. Ingeniería no es el enemigo. Las brechas en las especificaciones lo son. Y las brechas en las especificaciones son un problema de UX, no de ingeniería.

Por qué esto importa ahora

Haga los cálculos sobre un solo trabajo rehecho. Un feature. Un sprint. El estado vacío está mal, la gestión de errores falta, ingeniería tiene que refactorizar el componente porque las variantes no estaban desde el principio. En mis últimos cuatro empleos, el coste medio de uno de estos retrabajos es de unos 40 horas de diseñador y 60 horas de ingeniero. Eso son 100 horas-persona, con un coste combinado de aproximadamente $12.000-$15.000 según su equipo. Un retrabajo por trimestre y habrá quemado $50.000 al año en trabajo rehecho que un mejor documento de entrega habría evitado.

Y eso solo son los costes económicos. El coste en confianza es peor. Tras el segundo retrabajo, ingeniería deja de confiar en sus especificaciones y empieza a construir lo que cree que usted quiso decir. Tras el tercero, su PM deja de creer en sus plazos porque "el diseño siempre necesita otra ronda." La entrega no es una entrega. Es un contrato. Trátela como tal y la mayor parte de esto desaparece.

Baja vs. alta fidelidad: cuándo cada una justifica su uso

El mayor error que veo cometer a los diseñadores junior es saltar a la alta fidelidad demasiado pronto. Maquetas perfectas al píxel antes de que el flujo esté cerrado. Ingeniería las ve, se entusiasma, empieza a construir. Luego llega la investigación y el flujo cambia. Ahora ingeniería ha lanzado la mitad de algo incorrecto en código de producción y alguien tiene que explicarle al PM por qué el sprint se retrasó.

La baja fidelidad es para la lógica del flujo y el consenso de los stakeholders. Bocetos en papel, Balsamiq, frames de Figma en bruto con rectángulos de marcador de posición. La pregunta que se responde es "¿es esto siquiera la idea correcta?" No pula al píxel una pantalla que puede tirar mañana. El entregable es un prototipo en el que se puede hacer clic que demuestra que el camino de A a B tiene sentido, más un diagrama de flujo. Eso es todo.

La alta fidelidad es para la construcción. Perfecta al píxel, texto real (nada de lorem ipsum, nunca, porque ingeniería lo copiará y pegará y usted encontrará "Lorem ipsum dolor" en la página de inicio de sesión en producción, confíe en mi experiencia), formas de datos reales, todos los estados. Solo cuando el flujo esté cerrado. Si se encuentra corrigiendo detalles de maquetación en una pantalla cuyo flujo aún está en debate, pare. Vuelva a la baja fidelidad. Cierre el flujo primero.

La prueba honesta: si un stakeholder sigue preguntando "espera, ¿por qué va el usuario aquí?" no está listo para la alta fidelidad. No importa lo bonitos que sean los rectángulos.

Las brechas de especificación que ingeniería le va a preguntar (y que no diseñó)

Esta es la parte que nadie enseña en la escuela de diseño. Cada pantalla tiene aproximadamente ocho estados. Probablemente diseñó dos de ellos. Aquí está la lista que ingeniería le va a devolver en el momento en que se siente a construir:

Los ocho estados que necesita cada pantalla

1. Por defecto / con datos. El camino feliz. Este lo diseñó.
2. Vacío. Cero elementos, cero resultados, usuario primerizo. ¿Qué ve el usuario cuando no hay nada que ver? "Sin elementos aún" no es un diseño. Muéstreme la ilustración, el copy del CTA y la acción secundaria.
3. Carga. Skeleton, spinner, UI optimista. Y la regla de tiempo: ¿cuánto tarda en aparecer el spinner? (200ms es el umbral estándar; no muestre nada por debajo de ese tiempo.)
4. Error. Fallo de API, validación, permiso denegado, red sin conexión. Cada uno es diferente. El error 500 no tiene el mismo aspecto que el 403, que no tiene el mismo aspecto que "su contraseña es demasiado corta."
5. Parcial / degradado. La mitad de los datos cargados, algunas imágenes rotas, widget de terceros caído. Los sistemas reales se topan con esto constantemente.
6. Variante de permisos. Administrador, miembro, espectador, invitado. ¿Qué está oculto, qué está desactivado y qué se muestra con tooltip?
7. Datos extremos. Nombres largos que se desbordan, números cero, nulos o negativos, 47 elementos en una lista diseñada para 5, un número de identificación fiscal con 32 caracteres.
8. Móvil / breakpoints. Si el diseño es desktop-first, ¿qué ocurre a 768px y a 375px? "Responsive" no es una especificación.

Tengo esta lista fijada junto al monitor. Antes de cualquier entrega, reviso cada pantalla contra los ocho estados. Si un estado es "igual que el por defecto," lo anoto. Si es "fuera del alcance de este sprint," también lo anoto. El objetivo no es diseñar los ocho siempre. El objetivo es decidir sobre los ocho, de forma deliberada, y registrar la decisión en el archivo.

La brecha de los ocho estados es el fallo más común que observo. Corrija este único punto y habrá eliminado quizás el 60% de los momentos de "no lo especificaste."

Disciplina con Auto-Layout en Figma

Auto-Layout no es opcional. Si su archivo no está construido sobre él, ingeniería no puede ver qué es un componente y qué es un frame, no puede distinguir padding de margin, no puede predecir qué ocurre cuando el texto crece. Adivina. Adivina mal. Y luego es culpa suya.

Cuatro reglas que me han ahorrado horas:

1. Componentes, no frames desvinculados. Cada elemento reutilizable es un componente con un nombre que ingeniería puede leer. Un botón es Button/Primary/Default, no Rectangle 47. Si ingeniería no puede ver el nombre del componente en el inspector, está adivinando.
2. Tokens de espaciado reales, no márgenes a ojo. 4, 8, 12, 16, 24, 32. Eso es todo. Si se encuentra escribiendo padding: 13px lo está haciendo mal. Elija uno y avance.
3. Constraints configurados para que el redimensionamiento funcione de verdad. Pruebe cada componente al tamaño más grande y más pequeño posible. Si una tarjeta se rompe cuando el título tiene 80 caracteres, ingeniería llegará a ese bug en producción.
4. Variantes para el estado. Por defecto, hover, activo, desactivado, cargando, error. Todo en un componente, conmutable mediante una propiedad. Ingeniería conecta la variante a la máquina de estados y el archivo se convierte en autodocumentado.

Una prueba de olfato útil: abra su archivo, haga clic en cualquier elemento y observe el panel derecho. Si no puede ver de un vistazo qué componente es, en qué variante se encuentra y qué token de espaciado usa, ingeniería tampoco puede. Corríjalo antes de la entrega.

Design tokens: el contrato con ingeniería

Los tokens son lo que un Diseñador UX puede lanzar con mayor apalancamiento. Colores, escala tipográfica, espaciado, radios, sombras, duraciones de animación: todos con nombre, todos definidos una vez, todos referenciados por nombre en cada componente.

El contrato es sencillo. Cuando un token cambia (pongamos que la marca actualiza de #0066FF a #0052CC), ingeniería cambia una variable, no 40 componentes. Lo mismo aplica a la escala tipográfica, los radios, cada sombra.

La infraestructura ha mejorado genuinamente. Figma Variables como fuente de verdad. Tokens Studio (o la exportación nativa de Variables) para convertir a JSON. El JSON se importa en la configuración de Tailwind, las variables de CSS o una compilación de Style Dictionary. Ingeniería nunca escribe un valor hexadecimal a mano. Usted nunca vuelve a elegir un color de memoria.

Si aún no trabaja con tokens, esta es la inversión con mayor ROI que puede hacer este trimestre. La primera migración lleva una semana. Cada entrega posterior es más barata.

El documento de entrega: Loom más anotaciones

El documento de entrega es un contrato. Las entregas verbales no lo son. "Ya hablaré con ingeniería" es el atajo más caro del diseño. Las conversaciones en el pasillo son estupendas para aclarar. Son pésimas para especificar, porque tres semanas después, cuando QA encuentre la brecha, nadie recuerda lo que se dijo.

Aquí está el aspecto de un documento de entrega, en tres partes.

Parte 1: un Loom de 5 minutos recorriendo el flujo. Abra Figma, comparta pantalla, pulse grabar. Recorra el flujo al ritmo de un desarrollador que nunca lo ha visto. Señale: el punto de entrada, cada pantalla, el comportamiento no obvio ("observe que el toast se desliza, no aparece en fade, 200ms ease-out"), y toda la lógica de cambio de estado ("esto queda vacío cuando el usuario tiene cero facturas, pero si tenía facturas y las borró todas, mostramos la variante 'todo borrado', no el estado vacío de primera vez"). Mantengo una estructura de 3 minutos: 30 segundos de contexto, 2 minutos de recorrido del flujo, 30 segundos de puntos clave y 30 segundos de preguntas para ingeniería.

Parte 2: frames de Figma con anotaciones. Notas numeradas en cada pantalla. No notas adhesivas rojas. Anotaciones numeradas reales que se leen como un contrato. "1: Avatar. Al hacer clic, abre el modal de cargador. El modal se cierra con Escape, con clic en la superposición y tras una carga correcta." Cada interacción. Cada tiempo de animación. Cada caso extremo que reveló el recorrido de los ocho estados.

Parte 3: criterios de aceptación en el idioma de ingeniería. Esta es la parte que los diseñadores omiten y no deberían. Los criterios de aceptación tienen este aspecto:

Cuando el usuario hace clic en "Guardar" con un correo electrónico inválido, entonces en menos de 200ms aparece un error inline bajo el campo con el texto "Por favor, introduce una dirección de correo electrónico válida," el campo obtiene un borde rojo (token: border-error) y el foco permanece en el campo.

Eso son tres hechos de comportamiento (tiempo, texto, estado de foco) que QA puede verificar e ingeniería puede construir. Escriba entre cinco y diez de estos por pantalla para cualquier interacción no trivial. Sí, es lento. Es lento a propósito. La parte lenta es donde mueren las brechas de especificación.

Una última regla: enlace a un único frame de Figma como fuente de verdad. No 12 archivos. No "ver exploración v3 y v5 pero no v4." Un frame. Una URL. Si tiene que señalar varios archivos, ingeniería elegirá el equivocado y lo habrá merecido.

El modo de fallo de "ya hablaré con ingeniería"

Conozco diseñadores que se enorgullecen de sus relaciones estrechas con ingeniería y tratan las entregas escritas como sobrecarga. Lo entiendo. Yo fui una de ellas. La relación es real y vale la pena invertir en ella. Pero la relación no sustituye al documento.

Tres problemas con la entrega verbal:

1. Sin registro. Seis semanas después, cuando QA encuentre la brecha, usted e ingeniería recordarán a medias una conversación de forma diferente. Quien tenga más capital político gana. Así no debería funcionar un equipo de diseño.
2. Sin comprensión compartida. Ingeniería sale de la llamada con su interpretación. Usted sale con la suya. Se solapan quizás en un 70%. El 30% de brecha es donde viven los bugs.
3. Sin forma de verificar tras el lanzamiento. Cuando se siente a hacer QA de la construcción, no hay nada contra lo que comprobarlo. Está haciendo QA de intuiciones.

La regla por la que me rijo ahora: si no está escrito, no ha ocurrido. El Loom está escrito (es una grabación). Las anotaciones están escritas. Los criterios de aceptación están escritos. Las conversaciones en el pasillo de "oye, ¿puedes hacer también X?" se siguen por escrito en una hora, o X no se construye.

Revisión post-lanzamiento

La entrega no termina cuando ingeniería hace el merge. Termina cuando ha hecho QA de la construcción en vivo contra el Figma, juntos, y ha registrado las brechas.

Cómo lo ejecuto: reunión de 30 minutos en un entorno de sandbox o staging. Diseñador e ingeniero comparten pantalla. Se recorre cada pantalla y cada estado. Para cada uno, tres resultados posibles:

• Coincidencia. Continúe.
• Brecha, corregir en este sprint. Regístrela, archive el bug, ingeniería se compromete a corregirlo. Habitualmente 1-2 de estas por feature.
• Brecha, aceptar y actualizar Figma. A veces la versión de ingeniería es mejor, o la brecha es demasiado pequeña para merecer un sprint. Actualice el Figma para reflejar la realidad. No deje el archivo mintiendo sobre lo que hay en producción.

El pecado capital es la corrección silenciosa. No actualice pasivamente la siguiente versión sin decírselo a ingeniería. No finja que la brecha no existe. Regístrela, decidan juntos, avancen. Después de algunos ciclos de esto, ingeniería empieza a confiar en que el QA es colaborativo, no adversarial. Comenzarán a señalar sus propias preocupaciones antes durante la construcción.

Un objetivo razonable: no más de 3 brechas registradas por feature lanzado, con tendencia decreciente a medida que la disciplina de los ocho estados se consolida.

Cómo medir el éxito

Tres señales indican que la disciplina de entrega está funcionando.

1. Cero momentos de "no lo especificaste" por sprint. Este es el indicador retrasado. Si los está recibiendo, el recorrido de los ocho estados no se hizo.
2. Ingeniería cita nombres de frames de Figma en los PRs. "Implementa Settings/Profile/Avatar-Upload v2." Cuando ingeniería escribe mensajes de commit y descripciones de PR que referencian sus frames por nombre, su archivo se ha convertido en la fuente de verdad. Ese es el objetivo.
3. La revisión post-lanzamiento registra no más de 3 brechas por feature. Y las brechas tienden hacia el pulido visual menor, no hacia estados faltantes o comportamiento incorrecto.

Si los tres son ciertos, ha resuelto el problema de entrega. Su rol pasa de defender el diseño a extenderlo. Que es, finalmente, el trabajo que se supone que debería hacer UX.

El archivo de Figma no es arte. Es un contrato. Escríbalo todo. Recorra los ocho estados. Grabe el Loom. Anote los frames. Escriba los criterios de aceptación en el idioma de ingeniería. Ejecute la revisión post-lanzamiento. Haga esto cinco veces seguidas y su tasa de retrabajos cae casi a cero, y dejará de temer el viernes de entregas.

, Camellia

Aprenda más

• Rol complementario: plantilla de JD de Product Designer
• Cómo trabajar con PMs sin perder el alma de diseñador
• Un día en la vida de un Diseñador UX
• Investigación de usuarios que mueve el roadmap