Wireframe vs mockup vs prototipo: qué estás aprobando

Una fundadora con la que trabajamos el año pasado pasó tres semanas de reuniones de diseño asintiendo con cortesía ante cajas grises. Creía que el estudio le mostraba un producto sin terminar y que iba lento. Lo que en realidad miraba era un wireframe, y su tarea en esas reuniones era detectar un problema estructural que costaría cinco cifras corregir dos meses después. No detectó ninguno, porque nadie le dijo que esa era la tarea. El flujo de checkout tenía el paso de pago en el lugar equivocado. Salió a producción así, y el arreglo llegó en la semana nueve en vez de la semana uno.

Esa brecha es de lo que trata este artículo. La cuestión wireframe vs mockup parece un problema de diseñador, pero si estás pagando a un estudio para construir software a medida y no escribes código, es tuya: una vez que la fase de discovery define qué vas a construir, vas a recibir wireframes, luego mockups, luego un prototipo, normalmente en ese orden, y tendrás que aprobar cada uno. Saber para qué sirve cada uno es la diferencia entre dar feedback que ahorra un mes y dar feedback que desperdicia la tarde de todos.

Esta es la versión corta de wireframe vs mockup vs prototipo, las tres palabras que más vas a oír. Un wireframe es el plano: cajas grises y etiquetas que muestran qué va dónde y cómo se conectan las pantallas, sin color ni marca. Un mockup son esas mismas pantallas con el diseño visual real aplicado: tus colores, tipografías, espaciado, logo, el aspecto de verdad. Un prototipo es el mockup conectado para que puedas hacer clic y navegar como en una app real, aunque todavía nada detrás de los botones funcione. El wireframe responde “¿la estructura está bien?”. El mockup responde “¿se parece a nosotros?”. El prototipo responde “¿el flujo funciona de verdad?”. Tres artefactos, tres preguntas, tres trabajos distintos para ti.

Wireframe vs mockup vs prototipo: por qué el estudio los muestra en ese orden

El orden no es arbitrario, y no es que el estudio vaya lento. Es el estudio gastando tu dinero en la secuencia más barata posible.

Cambiar un wireframe lleva minutos. Alguien arrastra una caja, cambia una etiqueta, mueve un botón de arriba a abajo de la pantalla. Cambiar un mockup lleva más tiempo, porque ahora hay diseño visual real que rehacer: el espaciado, el tratamiento del color, cómo se ve el componente en tres estados. Cambiar un prototipo lleva todavía más. Y cambiar el software ya construido, eso que corre sobre código real, es el cambio más caro de todos, a veces por un orden de magnitud.

Así que un estudio competente pone por delante las decisiones fáciles de revertir y empuja el trabajo caro y difícil de revertir hacia el final. Resuelve la estructura primero, cuando la estructura es libre de moverse. Resuelve el diseño visual después. Confirma el flujo al final, antes de que se escriba una línea de código de producción. Toda la secuencia existe para encontrar tus objeciones mientras todavía son baratas. Es también donde el alcance abstracto que escribiste en un documento de requisitos que el estudio puede cotizar por fin se vuelve algo que puedes ver y a lo que puedes reaccionar.

Por eso también “sáltate los wireframes y muéstrame ya cómo va a quedar” es una petición tentadora que suele salir mal. Cuando saltas directo a un mockup pulido, tú y el estudio empiezan a discutir el tono de azul y las esquinas redondeadas, y nadie nota que todo el modelo de navegación está mal. El pulido esconde problemas estructurales. Las cajas grises existen precisamente porque no tienen nada bonito que te distraiga.

Qué estás aprobando en realidad en cada etapa

Los artefactos son fáciles de definir. La parte difícil, la que los blogs de herramientas de diseño nunca cubren, es qué se supone que tú hagas cuando uno llega a tu bandeja de entrada. Este es el trabajo en cada etapa.

Wireframe: revisa la plomería. ¿Existe de verdad cada pantalla que el usuario necesita? ¿Se puede ir del registro hasta aquello a lo que la persona vino sin un callejón sin salida? ¿La acción más importante de cada pantalla es la más obvia? ¿Pides la información en el momento correcto, o pides una tarjeta de crédito antes de que el usuario entienda qué está comprando? Son preguntas estructurales, y el wireframe es la única etapa en la que responderlas es barato. Si algo del flujo se siente mal aquí, dilo fuerte. Esta es la reunión que más importa y la que los fundadores se toman menos en serio, porque parece sin terminar.

Mockup: revisa la identidad y la jerarquía. Ahora hay diseño de verdad, así que ahora tu juicio visual sirve. ¿Esto parece un producto al que tu cliente le confiaría su dinero o sus datos? ¿Lo que más quieres que la gente toque está visualmente más fuerte que lo que no quieres? La pantalla densa, esa con la tabla o el dashboard, ¿sigue siendo legible? Aquí “haz que el botón principal resalte más” es una observación útil. Habría sido inútil en el wireframe, donde todo es gris a propósito.

Prototipo: recórrelo como un usuario confundido. Haz clic en lo equivocado a propósito. Intenta hacer la tarea principal como si nunca hubieras visto la app. Pásasela a alguien que se parezca a tu cliente real y obsérvalo trabarse sin ayudarlo. El prototipo es la última oportunidad barata de descubrir que un flujo que tenía sentido en una imagen estática se cae en el momento en que una persona real intenta atravesarlo. El Nielsen Norman Group, el nombre más citado en investigación de usabilidad, lleva décadas mostrando que hasta los prototipos toscos detectan la mayoría de los problemas de flujo que un build real terminaría lanzando sin resolver. No necesitas un prototipo perfecto para aprender lo importante. Necesitas uno que se pueda clicar y un tester honesto.

El error de feedback que cuesta un mes

El error más común y más caro que cometen los fundadores no técnicos en la revisión de diseño es dar el tipo equivocado de feedback en la etapa equivocada. En concreto: dar feedback cosmético en un wireframe y feedback estructural en un mockup.

Cuando le dices al diseñador que la tipografía del wireframe es fea, no le has dicho nada, porque el wireframe no tiene tipografía real. También has señalado que crees que tu trabajo es reaccionar a cómo se ven las cosas, lo que te entrena a seguir reaccionando al aspecto justo en las etapas donde la estructura es lo único que importa. Mientras tanto, el problema de navegación sigue ahí, sin que nadie lo mencione.

Lo contrario es igual de caro. Cuando esperas al mockup pulido para decir “en realidad, los usuarios deberían poder hacer todo esto en una pantalla en vez de tres”, acabas de pedir un cambio estructural después de que la estructura ya debía estar cerrada. El estudio ahora rehace un diseño que ya aprobaste, y el plazo que te prometieron se escurre en silencio. Todos los estudios han vivido esto. Es la causa principal de que un build llegue tarde mientras, técnicamente, todos hicieron su trabajo.

El arreglo es simple de decir y exige disciplina para seguir. Empareja tu feedback con el artefacto. Plomería en el wireframe. Identidad y jerarquía en el mockup. Flujo en el prototipo. Cuando te descubras queriendo hablar de color en una pantalla gris, anota la observación y guárdala para el mockup. Cuando te descubras queriendo reorganizar las pantallas en un mockup terminado, detente y pregunta por qué eso no salió en la etapa del wireframe, porque detectarlo ahora cuesta dinero de verdad.

¿Figma es un wireframe?

No, y vale la pena aclarar la confusión porque vas a oír la palabra “Figma” todo el tiempo. Figma es la herramienta que la mayoría de los estudios usa para dibujar los tres: wireframes, mockups y prototipos clicables viven todos dentro del mismo archivo de Figma. Así que “estamos en Figma” no te dice nada sobre qué etapa estás mirando. Pregunta directo: ¿esto es un wireframe, un mockup o un prototipo? La respuesta te dice qué feedback necesita de ti el estudio ahora mismo.

Lo mismo vale para las otras herramientas que puedas oír nombrar. Balsamiq está hecho para wireframes de baja fidelidad, a propósito, con un aspecto de boceto a mano para que nadie lo confunda con trabajo terminado. Sketch y Figma cubren todo el rango. La herramienta no es el punto. La fidelidad es el punto, y fidelidad es solo una palabra elegante para cuán terminado parece algo. Baja fidelidad significa cajas grises. Alta fidelidad significa que podría pasar por la app de verdad. La razón por la que los diseñadores recurren a la baja fidelidad temprano es la misma por la que el estudio te muestra wireframes primero: te mantiene enfocado en la decisión que de verdad está sobre la mesa.

¿Necesitas los tres?

No siempre, y un buen estudio te dirá cuándo no. El número correcto depende de qué estés construyendo.

Si estás validando una idea todavía cruda y las pantallas son simples, wireframes más un prototipo ligero pueden bastar, y el mockup visual puede ir junto con el build. Si estás construyendo algo donde la confianza y el acabado son el producto, el portal del paciente de una clínica premium, un dashboard de fintech moviendo dinero de verdad, quieres los tres y quieres gastar atención real en el mockup, porque la capa visual está haciendo un trabajo que sostiene el resto. Si estás extendiendo un producto que ya existe y ya tiene un design system, puedes ir directo a los mockups, porque las decisiones estructurales y visuales se cerraron hace mucho y reutilizarlas es justo el objetivo.

De lo que debes desconfiar es de un estudio que quiere saltarse el wireframe por completo en un build desde cero e ir directo a pantallas pulidas. A veces está bien, para un alcance diminuto. Muchas veces significa que se está saltando el pensamiento estructural, y vas a pagar ese salto después, en el build, donde los cambios son más caros. El orden existe para proteger tu presupuesto. Comprimirlo es una decisión, no un accidente, y tienes derecho a preguntar por qué.

Nada de esto exige que aprendas diseño. Exige que sepas qué pregunta te están haciendo y que respondas esa pregunta en vez de la que por casualidad te llamó la atención. Acierta eso y la fase de diseño se vuelve lo que debe ser: el lugar más barato para estar equivocado antes del build, donde estar equivocado se vuelve caro. Esa es toda la razón de que existan estos tres artefactos, y la razón de que un estudio te lleve por ellos en orden. El plan, luego el aspecto, luego la prueba de que funciona, cada uno una oportunidad de cambiar de opinión mientras cambiarla todavía cuesta casi nada.

FAQ

¿Cuál es la diferencia entre un mockup y un wireframe?
Un wireframe es el plano estructural: cajas grises y etiquetas que muestran qué va dónde y cómo se conectan las pantallas, sin color ni marca. Un mockup son las mismas pantallas con el diseño visual real aplicado, incluyendo colores, tipografías, espaciado y tu logo. El wireframe resuelve la estructura; el mockup resuelve el aspecto. Los estudios hacen el wireframe primero porque los cambios estructurales son baratos ahí y caros en todas las etapas siguientes.

¿Cuál es la diferencia entre un wireframe y un prototipo?
Un wireframe es una maqueta estática que lees. Un prototipo es interactivo: pantallas conectadas para que puedas hacer clic por el producto y sentir el flujo, aunque los botones todavía no hagan nada real. El wireframe te muestra la estructura de una pantalla a la vez. El prototipo te muestra si pasar de una pantalla a otra tiene sentido para una persona real que intenta completar una tarea.

¿Figma es un wireframe?
No. Figma es una herramienta de diseño que produce wireframes, mockups y prototipos clicables, todos dentro del mismo archivo. Así que oír “está en Figma” no te dice qué etapa estás revisando. Pregunta directo al estudio si estás viendo un wireframe, un mockup o un prototipo, porque cada uno necesita un tipo distinto de feedback.

¿Cuáles son los tipos de prototipo?
Los prototipos suelen describirse por fidelidad, es decir, cuán terminados parecen. Un prototipo de baja fidelidad navega por pantallas grises de wireframe para probar el flujo; uno de alta fidelidad navega por los mockups pulidos y puede pasar por la app de verdad en una demo. Para la mayoría de los fundadores, la distinción útil es simplemente baja versus alta fidelidad: usa uno de baja para probar si el flujo funciona y uno de alta cuando necesites una demo que parezca real para un inversor o un cliente.