Trabajé en una transnacional, con design system multipaís y todo, en la que tenía que entregar dos archivos: uno de UI y otro de UX que era exactamente el mismo, pero en blanco y negro: un filtro de Instagram para que pareciera wireframe.
También en una financiera local en pleno proceso de transformación digital en la que hacía wireframes a mano en una pizarra con rueditas que luego paseaba por la oficina para alinear a diferentes stakeholders.
Por eso, cuando vi en Reddit esta pregunta no pude evitar sonreír:
«¿De verdad sigues haciendo wireframes… o estamos todos fingiendo?»
—UI-Pirate
El punto no es si los wireframes están vivos o muertos, sino qué revela esta discusión sobre la madurez del diseño digital en 2025: cómo exploramos, cómo validamos, y, sobre todo, si usamos las herramientas para crear valor o solo para marcar un check en Jira.
He vivido ambos extremos.
Y aunque aquí hablaré de wireframes, la reflexión aplica a todo: user personas, journeys, prototipos… ¿los usamos porque generan claridad y facilitan decisiones, o porque alguien espera verlos como entregable?
Analicé cerca de 200 comentarios en Reddit y, sumando experiencias propias, encontré tensiones y usos de los wireframes que mantienen vivo el debate.
Tensiones en la práctica actual
Explorar vs. justificar
Los wireframes nacieron como espacio de exploración, pero muchas veces son exigidos como evidencia de que ‘hicimos el proceso correcto’.
«(…) ven un diseño en alta fidelidad y asumen que no hiciste investigación, que lo armaste como un Lego, sin pensar.»
—Firm_Doughnut_1
Velocidad vs. claridad
En teoría, trabajar en baja fidelidad acelera. En la práctica, puede frenar: algunos stakeholders no entienden las cajas grises y solo ven un producto ‘incompleto’.
Pero si mostramos colores demasiado pronto, se ponen a discutir el tono de un botón en vez de la funcionalidad.
«El diseño en baja fidelidad recibe feedback de alto nivel; el diseño en alta fidelidad recibe feedback de bajo nivel.»
—bryneshrimp
El reto es mantener la flexibilidad de exploración sin romper la conversación.
Innovación vs. commodities
Cuando diseñamos algo radicalmente nuevo, los wireframes siguen aportando un valor alto. Pero si hablamos de la enésima iteración del flujo de pago, reutilizar componentes te ayuda a ser más rápido.
«Nuestro design system ha vuelto innecesarios a los wireframes. Solo los usamos para exploración rápida o cuando trabajamos en algo nuevo.»
—baummer
Pedagogía vs. práctica
En muchos bootcamps se enseña que el proceso ‘correcto’ es: sitemap → wireframes → alta fidelidad.
Al enseñar wireframes como paso obligatorio, los convertimos en ritual más que en herramienta estratégica.
Error común: estética = fidelidad
Muchos reducen la fidelidad a una cuestión visual: baja fidelidad = gris (wireframes) y alta fidelidad = color.
Pero fidelidad significa otra cosa: qué tan cerca estás de la definición final.
«Tal vez no hagas wireframes, pero encuentra un artefacto de baja fidelidad que cumpla esa función.»
—calinet6
En muchos proyectos, hago prototipos rápidos usando componentes del design system, sabiendo que esos visuales no llegarán al producto final. Sigue siendo baja fidelidad porque sirven para explorar, no para entregar.
La fidelidad no se trata de la apariencia visual, sino del momento del proyecto: ¿estás explorando o estás entregando?
4 roles actuales de los wireframes
1. Pantomima
Se producen porque el proceso lo exige, no como una decisión estratégica.
Surgen en organizaciones de baja o mediana madurez donde UX = wireframes en la mente de los stakeholders.
«Creen que el wireframe debe hacerse primero sin importar qué. Terminamos sintiendo que perdemos el tiempo.»
—Firm_Doughnut_1
Aquí no aportan valor, solo cumplen con la burocracia corporativa.
2. Filtro de feedback
Sirven para dirigir la conversación hacia lo importante: flujo, jerarquía, funcionalidad.
«Hago wireframes cuando necesito que los stakeholders se concentren en la funcionalidad y no empiecen a criticar el color de un botón.»
—leo-sapiens
Bien usados, son un artefacto táctico que protege al equipo de discusiones estériles.
3. Ausente
Cuando la organización no tiene cultura visual suficiente, los wireframes se vuelven más problema que solución.
«Dejamos de hacer wireframes (…) porque los clientes simplemente no podían concentrarse en la estructura, sin importar cuánto intentáramos guiarlos.»
—procrastinagging
En contraste, en equipos con design systems sólidos los wireframes son innecesarios en la mayoría de los casos. La iteración se hace directamente con componentes estables.
La ausencia de wireframes no significa saltarse la fase de exploración, significa que la exploración cambia de formato.
4. Catalizador de ideas
En proyectos de alta incertidumbre son una de las herramientas más potentes para explorar rápido, ya sea a la interna del equipo como en espacios de co-creación con stakeholders.
«De 0 a 1 los hago en vivo con stakeholders y lo llamo taller de co-creación, es la forma más rápida de lograr alineación.»
—dj_stock
En mi experiencia, este es su rol más productivo: wireframes como herramienta de pensamiento, no como entregable formal.
El rol de los wireframes no es fijo: depende de la madurez de la organización y de lo que necesitas decidir en cada proyecto.
Entonces, ¿hacer o no hacer wireframes?
La elección no debería ser dogmática, sino pragmática.
«Los wireframes son una forma de comunicación (…) pero como cualquier otra herramienta, tienen un momento y un lugar.»
—iamfrankstallone
El valor del wireframe no está en cómo se ve, sino en las conversaciones que provoca.
Mal usados retrasan: discusiones anodinas, retrabajo, time-to-market lento.
Bien usados aceleran: alinean stakeholders, enfocan discusiones y abren espacios de exploración.
La clave está en si cumplen un rol claro en el contexto de tu proyecto:
- Si tu equipo los usa como un espacio de exploración, aportan valor.
- Si solo lo usan para ‘marcar el check de UX’, es teatro.
- Si tus stakeholders no saben abstraer, busca otra herramienta de exploración.
Aprendizajes
Hacer wireframes no te hace diseñador estratégico. Usarlos para facilitar decisiones de negocio y experiencia, sí.
Y lo mismo aplica para cualquier herramienta de diseño: user personas, journeys, prototipos.
Para un junior
No caigas en el fetiche del entregable. Pregúntate qué vacíos necesitas cubrir en cada proyecto.
Aclara a tu audiencia qué esperar de cada artefacto antes de mostrarlo.
Para un líder
Define un marco para que tu equipo decida qué artefactos aportan valor en cada etapa. Si negocio dicta tus entregables, entonces negocio está dirigiendo diseño.
Negocia protocolos con los stakeholders para que esté claro qué se discute en qué etapa. Así tu equipo evita perder tiempo en debates de píxeles cuando aún se define la estructura.
La documentación es necesaria, pero no debería restar eficiencia.
¿Cómo deciden qué herramientas usar (o dejar de usar) en tu equipo?