Wireframing: de la idea a la estructura

El wireframe es el primer artefacto visual del diseño. Su objetivo no es ser bonito: es ser claro y barato de cambiar. Representa la estructura de una pantalla —qué hay, dónde está y qué hace— sin entrar en color, tipografía ni detalle visual.

Pensar en wireframes te obliga a resolver preguntas estructurales antes de que el diseño visual las tape.

¿Qué es un wireframe?

Un wireframe es un esquema de baja o media fidelidad que muestra:

• La disposición de los elementos en la pantalla.
• La jerarquía de la información: qué es más importante, qué es secundario.
• Las acciones disponibles y su ubicación aproximada.
• La relación entre elementos (qué va con qué).

Lo que deliberadamente no incluye en esta fase:

• Colores definitivos (se usan escala de grises o blanco y negro).
• Tipografías específicas.
• Imágenes reales (se sustituyen por rectángulos con una X).
• Iconografía definitiva.

Niveles de fidelidad

Baja fidelidad (Lo-Fi)

Bocetos a mano o esquemas muy básicos en digital. El objetivo es pensar rápido, descartar opciones y converger en una dirección antes de invertir más tiempo.

Cuándo usarlos:

• Primeras iteraciones internas.
• Cuando la dirección del diseño aún no está clara.
• Para compartir con el equipo antes de una sesión de feedback.

Ventaja clave: son tan imperfectos que nadie se aferra a ellos ni los defiende como si fueran el diseño final. Eso facilita el debate y el cambio.

Media fidelidad (Mid-Fi)

Esquemas más estructurados en herramientas digitales (Figma, Whimsical, Balsamiq). Los elementos tienen tamaños aproximados reales, la jerarquía está resuelta y los flujos entre pantallas son navegables.

Cuándo usarlos:

• Validación con stakeholders o usuarios antes del diseño visual.
• Cuando necesitas que el equipo de desarrollo entienda el flujo.
• Base para el prototipo navegable de la siguiente fase.

Anatomía de un wireframe

Independientemente de la fidelidad, un wireframe bien construido responde a estas preguntas:

Estructura de página:

• ¿Cuál es el elemento más importante de esta pantalla? ¿Está en la posición más prominente?
• ¿Qué puede hacer el usuario aquí? ¿Las acciones principales están accesibles sin hacer scroll?
• ¿Hay información que solo necesita el usuario en ciertos contextos? ¿Está progresivamente revelada?

Navegación:

• ¿El usuario sabe dónde está?
• ¿Puede volver atrás fácilmente?
• ¿Las rutas hacia las tareas más frecuentes son cortas?

Estados:

• ¿Qué pasa cuando no hay datos aún? (Empty state)
• ¿Cómo se ve cuando hay un error?
• ¿Cómo se ve cuando está cargando?

Proceso recomendado

1. Empieza en papel

Antes de abrir Figma, dibuja a mano. Tres ventajas:

• Es más rápido explorar variantes sin comprometerse.
• Obliga a pensar en estructura, no en detalle.
• Los garabatos ilegibles son buenos: nadie se los toma como definitivos.

2. Dibuja primero el flujo, luego las pantallas

No empieces por la pantalla que te parece más interesante. Empieza por la entrada del usuario y ve pantalla a pantalla siguiendo el flujo que definiste en la lección anterior.

3. Usa una cuadrícula implícita desde el principio

Aunque sea a mano, piensa en columnas. La alineación y la consistencia de espaciado se resuelven mucho más fácil si tienes una rejilla mental aunque sea aproximada.

4. Rotula los elementos interactivos

Cada botón, enlace o campo necesita una etiqueta aunque sea provisional. “CTA” no es una etiqueta. “Crear proyecto” sí.

5. Dibuja los estados alternativos

Al menos el estado de error y el estado vacío. Son los que más se olvidan y los que más problemas causan en desarrollo si no se han diseñado.

Herramientas

Errores habituales

• Empezar con alta fidelidad: si usas colores, fuentes y componentes desde el primer sketch, el debate se centra en estética, no en estructura. La estética tapa los problemas lógicos.
• Diseñar solo el happy path: un wireframe que solo muestra el flujo perfecto no es un wireframe completo. Incluye siempre los estados de error, vacío y carga.
• Olvidar el contexto móvil: si el producto se usa en móvil, wireframea mobile-first desde el principio. Adaptar un diseño desktop a móvil a posteriori siempre cuesta más.
• No anotar las decisiones: un wireframe sin anotaciones obliga a reconstruir el razonamiento en cada reunión. Añade notas cortas explicando por qué está así, no solo qué hay.

¿Qué hemos aprendido?

• El wireframe resuelve estructura y flujo antes de entrar en diseño visual.
• La baja fidelidad facilita el cambio porque nadie se aferra a un garabato.
• Un wireframe completo incluye estados: vacío, carga y error.
• Las anotaciones son tan importantes como el dibujo.

Siguiente paso

En la próxima lección veremos Prototipado: cómo convertir los wireframes en algo navegable, qué nivel de fidelidad necesita cada tipo de validación y cómo preparar un prototipo para test con usuarios.