Infotectura

Para qué sirven los wireframes

20 de Mayo

Web Design Ledger tiene un post con 18 ejemplos de wireframes a mano alzada. Algunos son muy sencillos y abstractos, y muestran solamente los elementos de las pantallas y su ubicación. Otros son más detallados, e incluyen sugerencias de tonalidades, dirección visual, y hasta colores. Algunos de los diagramas incluyen sitios web conocidos: Vimeo, Firefox, y hasta Twitter (¡muy interesante ver el concepto original!).

Lo resalto porque en varias ocasiones he encontrado profesionales en nuestro campo que parecen obsesionados con producir wireframes “perfectos”. Estas personas buscan siempre producir diagramas terminados, con calidad de presentación, y pasan más tiempo creando diagramas “bonitos” que pensando sobre los problemas de diseño que deben resolver.

Los wireframes sirven dos propósitos:

1. Permitir al diseñador entender los elementos que va a incluir una página o pantalla, sus tamaños relativos, y su relación entre sí. (El maquetado de la página.)
2. Comunicar al diseñador visual o al programador cómo va a estar estructurada la página o pantalla, y cuáles elementos debe incluir.

Para servir el propósito 1, no es necesario que los diagramas sean perfectos. De hecho, es preferible que sean rápidos y “desechables”: mientras más ideas se puedan explorar, mejor. Es parecido a tomar notas cuando uno escucha una charla: lo que se busca es capturar las ideas, aunque sea de forma imperfecta, por encima de escoger la tipografía correcta u otras preocupaciones estéticas. Como la audiencia es uno mismo, la calidad visual no es tan importante.

En muchos casos, para servir el propósito 2 tampoco es necesario tener diagramas perfectos: basta con que se comuniquen las ideas principales. Siempre y cuando la audiencia pueda entender estas ideas, el diagrama está sirviendo su propósito. Con la práctica he encontrado que cuando estamos tratando con diseñadores visuales, los diagramas más formales producen diseños más rígidos y menos orgánicos. (El resultado final tiende a parecerse demasiado al wireframe.) Por el contrario, los wireframes más informales tienden a producir diseños finales que se sienten más naturales.

En fin, los wireframes informales son preferibles: no nos atan prematuramente a una idea durante el proceso de exploración, y le dan a los diseñadores más libertad al momento de producir el diseño visual.

Eso dicho, a veces es apropiado crear wireframes más formales. Por ejemplo, cuando la audiencia del diagrama es alguien con quien no has trabajado antes, es preferible que el wireframe sea más detallado y preciso, ya que esto reduce las dudas y las oportunidades de equivocación. Además, he notado que los programadores tienden a preferir los wireframes más formales: en muchos casos es la primera representación visual que ven de los requisitos del sistema, y quieren poder explorar las posibilidades del interfaz en mayor detalle.

Varios diseñadores con los que he trabajado se quejan de que “no saben dibujar”, y que por ende no pueden crear diagramas a mano alzada. No creo que esta excusa es válida. En primer lugar, estos diagramas no tienen que ser obras de arte: tienen que comunicar. Siempre y cuando sean comprensibles por la persona que va a implementar el diseño, el diagrama está cumpliendo su función. (Fíjate en el diagrama inicial de Twitter en el link que resalté arriba — es el menos atractivo en la lista.) En segundo lugar, dudo de las capacidades de cualquier diseñador que no se atreva a hacer un bosquejo a mano alzada. El producir experiencias en el web exige al diseñador visualizar y comunicar visualmente. Una persona que no tiene capacidad para comunicarse visualmente tiene un gran reto en esta profesión.

Nota que no he incluido “presentar el diseño al cliente” como uno de los propósitos que sirven los wireframes. En mi experiencia, es un error mostrarle estos diagramas al cliente final. Muchos no entienden la diferencia entre el wireframe y el diseño visual del sitio, y mostrarles wireframes los confunde. Los clientes quieren ver el diseño visual: la representación de cómo se va a ver el sitio cuando esté terminado. Para poder producir el diseño visual lo más rápido posible, es recomendable producir wireframes rápidos e informales. Después de todo, nuestros clientes nos están pagando para producir websites, no para crear wireframes.