Narrativa de wireframes guiados

Una de las herramientas que desde mi punto de vista son más agradecidas pos los clientes del mundo real a la hora de iniciar un proyecto para la web son los wireframes. Aquí ya hemos hablado de ellos, y otros también los han hecho, como es el caso de Nelson y Rodrigo.

Como técnica de prototipado de bajo nivel son una herramienta muy útil. La combinación de éstos con un desarrollo de un mapa web hacen de estos dos entregables una potente herramienta de comunicación con el cliente en las primeras fases de los proyectos. Pero como herramienta de soporte y enganche químico con el cliente tienen también su valor, que desde mi punto de vista es casi indiscutible. Es la primera ocasión en la que el cliente ve cosas de su proyecto, al poco tiempo de haberse iniciado éste.

Un texto leido en El Factor Humano, titulado Storyboards y Narrativa para Wireframes Guiados, me lleva a una de las lecturas pendientes de la semana: The Guided Wireframe Narrative for Rich Internet Applications. En este último texto, Andres Zapata nos pone sobre la pista de la adecuación del uso de wireframes a los proyectos que cuentan como requisito el uso de ajax o de tecnologías que redunden en la interacción con el usuario de forma cuasi inmediata. En definitiva, nos está presentando cómo aplicar la técnica de realización de wireframes a Rich Internet Applications.

Y Zapata inicia su argumentario de una forma casi inapelable:

There is no better form to express structure, conventions, and flow than ?showing? the client a prototype.

O lo que es lo mismo: no hay mejor forma de expresar la estructura, el flujo y las convenciones que vamos a utilizar que mostrarlo al cliente a través de un prototipo. Ahora bien, en el escenario que se está planteando de aplicaciones con una alta carga de interacción, siendo ésta acotada en el tiempo real de ejecución de la aplicación, hay que ingeniárselas para no estirar demasiado la cuerda del coste, de forma que tal prototipo sea viable económicamente, y efectivo dentro del proyecto. Aquí es donde entra en luego lo que Zatapa denomina guided wireframe narrative, y nosotros vamos a llamar narrativa de wireframes guiados.

De tal modo, Zapata afirma, y yo lo comparto, algo así como que la clave de usar un medio de información en un conexto poco definido, como son los wireframes, cuando tenemos que ilustrar una información en un contexto más definido, tenemos que hacerlo en capas, en dimensiones. Ahí es donde los wireframes guiados juegan un papel protagonista. Siguiendo el argumento de Zapata, como no podemos hacer un prototipo de la aplicación (por evidentes razones presupuestarias), lo que vamos a hacer es plasmar el argumento, la historia: lo vamos a contar. Pero como lo que vamos a contar no tiene una sola vertiente, tiene matices y no es para nada un argumento lineal (wireframes), lo que hemos de hacer es mostrar esos matices a lo largo del argumento (wireframes guiados).

Lo mejor es verlo con ejemplos. Pero antes vamos a describir los planos, la naturaleza de los matices que tenemos que reflejar en nuestros wireframes guiados:

• Jerarquía
• Estado de la pantalla
• Convenciones de diseño
• Patrones de interacción

La forma en la que vamos a plasmar los niveles de matices en nuestros wireframes guiados puede estar basada, según lo que cuenta Zapata, en una consecución de pantallas de Power Point en las que vamos a insertar de forma recursiva una serie de bocadillos con anotaciones al respecto del comportamiento de la aplicación en función de la interacción con el usuario.

Personalmente yo no voy a recomendar el uso de aplicaciones que tengan un equivalente funcionalmente razonable en el mundo del software libre. Por eso me quedo con las herramientas análogas de la familia Open Office, como será la herramienta Impress.

En cualquier caso, el proceso de diseño de los wireframes guiados va a ser el que sigue:

1. Realizar el trabajo previo: entrevistas con el cliente, revisión de los requisitos, reuniones varias, etc.
2. Realizar el diseño conceptual como con unos wireframes al uso.
3. Importar las capturas de los wireframes en la herramienta Impress.
4. Tomar la perspectiva de cada una de los cuatro planos que vamos a considerar (de forma iterativa)
5. Señalar los diferentes aspectos que queramos considerar sobre el diseño de cada pantalla, a través de unos globitos de ayuda (al estilo de los tebeos) que indiquen lo que sucede.
6. Secuenciar cada llamada de tal modo que cada una de ellas sean mostradas de una en una, y de ese modo ayude a comprender y describir la dimensión en particular y el documento en general.

Por último hay que hacer mención del por qué hacemos uso de los wireframes para acometer esta extensión de los mismos en nuestra labor en este caso. Son cuatro razones bien simples y comprensibles.

1. Son familiares: nosotros sabemos cómo hacerlos y el cliente sabe cómo leerlos.
2. Son económicos: es mucho menos costoso presentar diez pantallas a través de wireframes que con HTML.
3. Son rápidos en su desarrollo: realizar wireframes es más sencillo que escribir HTML.
4. Son comprensibles: los wireframes no son susceptibles de reaccionar ante una posible acción por parte del usuario. No se puede hacer click en ningun sitio, con lo que los clientes no se ven frustrados (porque no puede no funcionar) y además, y desde mi punto de vista, mucho más importante, abstraen al cliente de posibles despistes respecto del cometido de los wireframes.

¿Cómo se ve todo esto?

Pues de la siguiente forma. Las imágenes están tomadas, tal cual, del post original de Zapata.

Como se puede ver en la sucesión de pantallas, se trata de que cada una de las reacciones de la aplicación y de la interacción por parte del usuario se vean reflejadas en los wireframes a través de las llamadas que van apareciendo a lo largo de la presentación de los mismos. Ya que no olvidemos que se trata, en muchos casos, de una modificación del concepto de pantalla que describe cada wireframe. Nos vamos a encontrar con muchas osaciones en las que la misma pantalla tiene por encima una multitud de interacciones, acciones y reacciones que se verán sustanciadas con las llamadas a modo de bocadillos de tebeo. Esa es la línea narrativa que esta herramienta nos va a proporcionar y que nos va a permitir trasladar al cliente y describir muy bien los cuatro planos a los que se hacía referencia con anterioridad: jerarquía, estado de la pantalla, convenciones de diseño y patrones de interacción.

En Torresburriel Estudio desarrollamos las capacidades técnicas de tu equipo en temas de usabilidad, experiencia de usuario y diseño de producto a través de nuestros cursos online y presenciales. Contacta con nosotros y cuéntanos tus necesidades.