Los wireframes son dibujos en 2D que usamos en lugar de construir una versión completa del producto, eliminando así la arquitectura de nivel de producción como la seguridad o el código. De esta forma, los wireframes permiten que el equipo de desarrollo de productos comprenda el diseño, la arquitectura de la información, el flujo de usuarios y la funcionalidad antes de entregar los diseños al equipo de ingeniería.
Los marcos son una oportunidad para que los desarrolladores prueben sus hipótesis. En otras palabras, al trabajar con los usuarios y las partes interesadas, los equipos de productos pueden aprender lo que son. Creo es importante de hecho en tono rimbombante.
¿Cuáles son los tipos de marcos?
- Marcos de baja precisión son lo más simples posible, a menudo usando solo líneas y círculos.
- Marcos de alta precisión utilizará identificadores como el color para proporcionar una mayor claridad de las características y la funcionalidad.
¿Cuáles son las ventajas de los marcos?
Los wireframes ayudan a los equipos de productos a comunicar visualmente problemas y soluciones a los clientes y partes interesadas clave en toda la organización. Los marcos también brindan alineación interfuncional al proporcionar un artefacto compartido que todos pueden entender antes de que el equipo invierta en crear un producto o característica.
Hacer que los marcos sean una parte regular de su práctica tiene los siguientes efectos.
- El equipo recibirá más comentarios. temprano en el proceso porque hay poco en juego. Dado que el producto aún está en pañales, los cambios son mucho más económicos.
- El equipo se relacionará con los clientes desde el principio.. Esto significa que se sentirán cómodos pidiendo comentarios y realizando cambios que los usuarios realmente quieren ver.
- El equipo creará un producto más fácil de usar. porque los problemas de interacción y flujo del usuario surgen antes de que el equipo invierta en la creación de la aplicación.
¿Cuáles son las desventajas de los marcos?
- Los marcos no tienen en cuenta las consecuencias técnicas. Si el diseño no funciona con los ingenieros sobre lo que es posible, las partes interesadas y los equipos pueden emocionarse demasiado, solo para descubrir que los cambios o las características adicionales no son posibles.
- Es posible que su cliente no entienda por qué está utilizando una estructura alámbrica. Si su equipo no ha capacitado adecuadamente a las partes interesadas o los clientes, un marco puede crear una falta de confianza. Quiere asegurarse de que los clientes no se sorprendan cuando vean los wireframes. Si esperan un programa completo, se sentirán muy decepcionados cuando solo obtengan cajas y líneas.
- Puede dejarse llevar demasiado por sus primeros borradores. Si dedica demasiado tiempo a crear esquemas, perderá el punto. Hermosos wireframes pueden hacer que el equipo sienta que necesita avanzar, incluso si aún necesita hacer cambios, o incluso comenzar desde cero. Al diseñar wireframes, la frase clave es «suficiente».
¿Cuándo usas Wireframes?
Debe usar wireframes cuando el equipo de desarrollo de productos necesite información sobre los clientes y las partes interesadas al principio del proceso de creación. En otras palabras: todo el tiempo.
Los marcos deben ser una parte regular del proceso de diseño y desarrollo de su producto porque nos permite entender cómo funciona nuestro producto terminado sin aplicación de trabajo para crear un producto terminado.
Volvamos al ejemplo de arquitectura anterior. Si estuviera tratando de construir un edificio y necesitara un inspector para verificar que estoy planeando el edificio según el código, sería mucho más fácil (¡y más barato!) mostrarles el plano con el diseño planificado en lugar de construir un edificio completo. estructura solo para que me dijeran que tenía que empezar de nuevo.
El desarrollo de software sigue el mismo principio. Es mucho más fácil obtener comentarios de un miembro del equipo o de un cliente potencial usando una versión abreviada de nuestra aplicación, en lugar de crear una versión completa para (potencialmente) comenzar desde cero.
2 tipos de marcos
1. Marcos de baja precisión
Los wireframes de baja fidelidad son lo más simples posible y, a menudo, solo usan líneas y círculos. Utilice esta forma de estructura alámbrica cuando desee probar rápidamente nuevas ideas y obtener una mejor comprensión del panorama general. Idealmente, debería poder crear y eliminar rápidamente estructuras alámbricas de baja fidelidad.
2. Marcos de alta precisión
Los wireframes de alta calidad utilizarán identificadores como el color para dar mayor claridad a las características y funciones. Utilice este tipo de estructura alámbrica cuando desee comprender mejor detalles como el color, la navegación y la accesibilidad.
Ejemplos de estructuras alámbricas
Un marco de baja precisión.

Este es un ejemplo de un marco de baja fidelidad. Una estructura alámbrica de baja fidelidad utiliza líneas y símbolos en lugar de activos como imágenes o videos. Algunos de estos símbolos se explican por sí mismos. Un cuadro con una X indica dónde se colocará la imagen, o un rectángulo con un ícono de reproducción representa el video. Como puede ver, puede recopilar mucha información incluso con unas pocas líneas.
Marcos de alta precisión

Estas son maquetas de alta calidad para una aplicación móvil. Como puede ver, están bastante cerca de lo que esperaría de una aplicación móvil, pero aún faltan cosas como la copia y el color.
En ambos casos, los wireframes deben dejar claro que no son diseños finales, que el código no está escrito y que todo está abierto a discusión.
Cómo empezar a trabajar con el marco.
Para wireframes de alta o baja fidelidad, deberá comprender el problema, la solución que está probando y el usuario del que desea recibir comentarios.
entender el problema
¿Qué necesita entender el equipo? ¿No está claro si el usuario puede interactuar con la nueva función que está creando? ¿Esta nueva función coincide con el contexto de la página web? Una declaración clara del problema lo ayudará a desarrollar su hipótesis para que tenga una idea clara de la solución que ofrecerá su marco.
Comprender la solución
¿Cuál es la solución al problema presentado? Si cree que colorear una sección del sitio en amarillo atraerá la atención del usuario, entonces esta será la base de su marco.
Comprender al usuario
¿A quién le importa esta decisión? Si está tratando de entender si los usuarios harán clic en ese cuadro amarillo, debe asegurarse de saber para quién es el esquema y cómo se ve el éxito para el equipo. Si no lo hace bien, terminará creando un producto terminado para la persona equivocada.
Una vez que el equipo de diseño entiende el problema, la solución y el usuario, pueden construir un marco exitoso.
La forma más rápida de comenzar una estructura alámbrica es usar lápiz y papel y esbozar su idea. Mantenlo simple y esquemático: usa líneas, círculos y cuadrados. Incluya conceptos tales como la colocación de imágenes, videos y textos. En este punto, no hay necesidad de escribir una copia o incluir imágenes o videos reales. Simplemente agregue imágenes que representen sus activos.
Hagas lo que hagas, asegúrate de no dedicarle demasiado tiempo, incluso si es tentador crear una copia perfecta de lo que estás pensando. Trate de esbozar su idea en menos de 10 minutos porque debe mantenerlo simple y plasmar la idea en papel.
Herramientas de marco
Hay varias opciones para los equipos que buscan desarrollar wireframes.
Para aquellos que se sienten cómodos mostrando prototipos de baja fidelidad a los clientes, pueden usar una herramienta como Balsámico, que proporciona una forma rápida de convertir prototipos. La herramienta es simple y proporciona líneas irregulares y una representación simple de elementos como videos de YouTube para ayudar a los equipos a evitar apegarse demasiado a lo que están diseñando.
Si está buscando herramientas con mayor precisión, figma, Bosquejo y Invisión le permite presentar copias de su aplicación a su equipo o usuarios potenciales en una fracción del tiempo que lleva construir la aplicación real.
De cualquier manera, tendrá un artefacto que podrá compartir con sus colegas, partes interesadas y clientes, y luego realizar cambios en horas en lugar de semanas.