Hasta hace algún tiempo, defendía la idea de que era imprescindible crear wireframes para todos los proyectos. Hoy creo que la situación ha cambiado considerablemente.
No se trata de un cambio de opinión respecto del valor de la herramienta en sí misma, sino de una realidad diferente, de condiciones distintas en la industria.
Disponer de semanas o incluso meses para elaborar y documentar wireframes es costoso, requiere de dedicación y de tiempos que no siempre están disponibles. Se justifica cuando los equipos que diseñan y definen la arquitectura de información de un producto son distintos. Se debe comunicar de modo claro qué hacer, entregar instrucciones de cómo construir el sitio o aplicación. Esas instrucciones deben ser precisas, no deben dejar dudas. Este escenario es cada vez menos frecuente.
Cuando el equipo que diseña y el que implementa es el mismo, o son equipos que están muy comunicados, el valor de los wireframes se diluye. Adquiere más valor la comunicación directa.
Los wireframes son tanto una herramienta de comunicación de diseño, así como de política interna. Como herramienta de comunicación, son la representación de un momento de un proyecto. Su rol político tiene que ver con la necesidad de respaldar decisiones, de contar con definiciones que servirán de referencia para contratar la implementación o para controlar su desarrollo.
El problema es que un diseño nunca está cerrado. Se marcan hitos, se cierran ciclos, pero los proyectos no se detienen. Y en estos momentos, el tiempo tiene un valor enorme. Un producto puede perder una oportunidad vital por no salir en el momento adecuado.
¿Qué alternativas hay? Si no vamos a elaborar wireframes, es necesario documentar los aspectos centrales de la arquitectura de información o de las interacciones. Las alternativas son varias, por ejemplo, alguna o una combinación de las siguientes:
- Bocetos de pantalla de baja resolución. Es decir, dibujos en papel sin mucho detalle de las estructuras principales.
- Prototipos semifuncionales. Simulaciones interactivas que documentan páginas, flujos e interacciones.
- Flujos de pantallas. Llamados de diversos modos, se trata de diagramas de pantallas dispuestos en un flujo, que funde un diagrama de interacción con wireframes de diferente resolución.
Estas son sólo las alternativas más comunes. El punto más importante, es que siempre será necesario marcar un hito en que las ideas de diseño se comunican y traspasan a un equipo de desarrolladores. Mientras más cercanos —y mayor confianza tengan— ambos equipos, se requerirá de menos detalle en la documentación.
