Usable y accesible: Wireframes

Artículos relacionados
[01-10-07] La usabilidad como metodología para el desarrollo ...

Última actualización: 5 de mayo de 2009

Terminología

Wireframe, Blueprint, Prototipo, Storyboard, Mock Up, Diagrama de contenido…

Lo primero aclaremos la terminología.

Como expliqué en "Disciplinas relacionadas con la usabilidad", hay diversas disciplinas que intervienen en el Diseño de Interfaz de Usuario, entre ellas se encuentra la Arquitectura de Información (AI).

El Arquitecto de Información se encarga de la organización, etiquetado, navegación y sistema de búsqueda que ayuda a los usuarios a encontrar y gestionar la información de manera efectiva.

Para llevar a cabo estas tareas, nos valemos de la diagramación para especificar cuál será la organización, estructura, funcionamiento y navegación del sitio.

Existen dos tipos de diagramas (sin contar los que pueden surgir de la aplicación de otras técnicas como el Card Sorting) como podemos ver en este gráfico de NSU:

[DE-1]

[Ver imagen "Tipos de diagramación" más grande]

Así pues distinguimos:

los PLANOS, que son diagramas de organización y funcionamiento

las MAQUETAS, que son diagramas de presentación

Los diagramas de organización y funcionamiento se llaman BluePrint (también Architecture Map o Diagramas de contenido o flujo) y pueden ser más o menos avanzados. En NSU vemos dos ejemplos, uno más sencillo y otro más completo:

[DE-2]

[Ver imagen "BluePrint sencillo" más grande]

[DE-3]

[Ver imagen "BluePrint más elaborado" más grande]

Como se ve, el objetivo de estos diagramas es mostrar la estructura del sitio y su flujo de navegación.

Para la realización de este tipo de diagramas de recomienda siempre el "Vocabulario visual para describir arquitectura de información y diseño de interacción" de Jesse James Garrett.

Por otro lado hemos visto que tenemos los diagramas de presentación, cuyo objetivo es mostrar el contenido de las páginas, concretando los elementos que se plantearon en los primeros planos (blueprints) y ubicándolos en las páginas o pantallas del producto final.

Podemos tener distintos tipos de prototipos, que en ningún caso incluyen el diseño gráfico puesto que este se aplica en una etapa posterior. Para simplificar, podemos hablar de:

Prototipos de Baja fidelidad o Wireframe o StoryBoard: son un conjunto de dibujos que representan cómo estarán organizados los elementos en las páginas, de tal manera que implementan aspectos generales del sistema sin entrar en detalle.

Prototipo de Alta Fidelidad o Maqueta o MockUp, con los que se representan aspectos más precisos. Sirven, por ejemplo, para detallar el proceso interactivo global de una o varias tareas concretas. Son prototipos o maquetas dinámicas, normalmente en (X)HTML, que simulan o tienen implementadas partes del sistema final a desarrollar. Pueden ser de muy distintos tipos, completo o parcial, horizontal o vertical, etc.

En Sidar tienes un excelente artículo sobre distintos tipos de prototipado.

El propósito de crear estos prototipos es dar la oportunidad de evaluar el diseño prematuramente. El objetivo es producir estos prototipos rápidamente y evaluarlos eficazmente para que puedan ser refinados, elaborados y reevaluados antes del producto final. Ingeniería de la Usabilidad aplicada al desarrollo de un portal web administrado dinámicamente, José M. Belmonte Marín

El doctor Granollers, en su tesis doctoral, propone un nuevo tipo de prototipado, el StoryBoard Navegacional, que une los dos tipos de prototipado. Lo expliqué en el artículo anterior, "Metodología DCU MPlu+a"

Buenos ejemplos de Storyboard Navegacional los proporciona Vicki Huynh, por ejemplo en R2 for SmBiz

Una vez aclarados los términos, me voy a centrar en los diagramas de presentación Wireframes.

¿Qué es un Wireframe?

Una representación esquemática de una página web sin elementos gráficos que muestran contenido y comportamiento de las páginas. Sirven como herramienta de comunicación y discusión entre arquitectos de información, programadores, diseñadores y clientes. También se pueden utilizar para pruebas de usuarios. "Wireframes: recopilación de enlaces" en No lo entiendo.

Es muy importante aclararle siempre al cliente qué es un Wireframe, estar seguros de que entiende que ese no es el aspecto final del sitio, sino una mera representación gráfica de su contenido.

¿Cómo es un Wireframe?

Ejemplo 1: Wireframe Rediseño de Terra.org en Guindo

Ejemplo 2: Wireframe del Rediseño del blog El Factor Humano 2.0 de WebStudio

Ejemplo 3: Representing Data in Wireframes de Dan Brown

¿Cuándo se realizan?

Una vez tengamos delimitados los objetivos del cliente, las necesidades de los usuarios y los contenidos y funciones de la web; antes de empezar a programar y de crear el diseño visual de la página. "Wireframes: recopilación de enlaces" en No lo entiendo

Por tanto, antes de hacerlo, es necesario tener todos los requisitos del proyecto: requisitos de negocio, de contenido, de diseño, de ancho de banda, de software, etc.

Ventajas de crear Wireframes

Hay dos grandes ventajas, por un lado el equipo y el cliente se centra en el diseño de contenidos y no en el diseño visual, y por otro lado, definiendo la organización y estructura en etapas previas al diseño y programación se evitan cambios posteriores más costosos, reduciendo así costes y tiempos.

Las principales características o ventajas de los prototipos (se refiere a los prototipos en general, no a los Wireframes en particular) según el doctor Granollers son:

Son formidables herramientas de:
- Comunicación entre todos los componentes del equipo de desarrollo y los usuarios
- Participación, para integrar activamente a los usuarios en el desarrollo.
Dan soporte a los diseñadores a la hora de escoger entre varias alternativas.

Permiten a los diseñadores explorar diversos conceptos del diseño antes de establecer los definitivos.

Permiten evaluar el sistema desde las primeras fases del desarrollo (facilitan la exploración de ideas sobre nuevos conceptos tecnológicos).

Son esenciales para la documentación, tanto de conceptos funcionales del sistema como de tareas concretas del mismo.

Son el primer paso para que ideas abstractas sean concretas, visibles y testables.

Fomentan la iteratividad.
Mejoran la calidad y la completitud de las especificaciones funcionales del sistema.

Son herramientas de propósito general, pues sirven para comprobar la fiabilidad técnica de una idea, clarificar requisitos que quedaron “indeterminados” o ver como responde con el resto de la aplicación.

¿Qué información debe contener un Wireframe?

Como bien indica "Using Wireframes" de Strange Systems:

Inventario de contenido. Qué contenido debe estar presente en cada página

Elementos de la página. Cabeceras, enlaces, listas, imágenes, formularios, etc.

Etiquetado. De vínculos, títulos, etc.

Layout. Ubicación, colocación y agrupación de los elementos de la página (cabeceras, pies, navegación, áreas de contenido, titulares, etc.) Muestra la estrategia de navegación y la priorización de contenidos dentro de la página, así como la agrupación en barras laterales, barras de navegación, áreas de contenido, etc.

Comportamiento. Mediante notas asociadas a los elementos para indicar cómo se deben mostrar (nº de elementos, visualización por defecto) o definir el comportamiento funcional cunado un elemento se activa (enlace externo, etc.)

Tipos de Wireframe

Como especifica "Using Wireframes" de Strange Systems, pueden ser más o menos detallados:

Content-only: tan sólo consta del nombre de la página y un listado de contenidos

Diagrama de bloques: contiene sólo la información básica a través de bloques de funcionalidad y agrupamiento de contenidos (Ejemplo 1: Wireframe Rediseño de Terra.org en Guindo )

Wireframe detallado: tendría todos los elementos antes mencionados incluidas las notas de comportamiento (Ejemplo 1: Wireframe Rediseño de Terra.org en Guindo y Ejemplo 2: Wireframe del Rediseño del blog El Factor Humano 2.0 de WebStudio)

¿De cuántas páginas creamos un Wireframe?

De la página principal y de los principales tipos de subpáginas o plantillas, entre las que deberán incluirse, una página de formulario, una página de resultado búsqueda y una página de error. Si estamos ante una aplicación deberá incluir una página de ingreso de datos, una página de detalle y una página de listado.

¿Cómo se hace un Wireframe?

37signals propone en "Una introducción a la utilización de patrones de diseño en la web" una metodología para hacer un Wireframe que consta de 6 pasos. No ha de tomarse como una receta mágica, pero puede orientarnos:

Haz una lista numerada de toda la información que debe tener tu página (no sólo datos, sino también acciones, actitudes), lo que llaman "bit".

Agrupa los "bits" que se relacionan entre sí. A cada grupo lo llamarías con una letra y asociada a esa letra pondrías los números de la información que relaciona. Por ejemplo A:1,3,5

Prioriza qué grupos son los más importantes desde un punto funcional, agrupando los grupos en tres prioridades: Lo más importante, Lo necesario y Lo que es bueno tener.

Diseña cada fragmento, cada agrupación de "bits". Lo podemos hacer sin preocuparnos de los conflictos porque ya sabemos que incluyen a todos los elementos relacionados entre si.

Junta los fragmentos teniendo en cuenta la prioridad y el equilibrio.

Hazlo real. Hasta ahora todo lo hemos hecho en papel, es el momento de pasarlo a pantalla y hacer los ajustes necesarios para ello.

Errores en la creación de Wireframes

Hay tres errores típicos:

Realizar Wireframes demasiado complejos en su forma

Realizar Wireframes con algo diseño gráfico

Incluir un exceso de información

Para evitarlos es bueno seguir las recomendaciones de Liz Danzico en "The Devil's in the Wireframes"

Amplifica a través de la simplificación:
El Wireframe debe ser claro, sin diseño, ni iconos, ni color. Por ello Gene Smith propone usar una única figura, un único color y un único tipo de letra. Tampoco es necesario ser tan estrictos, pero ayuda a entender la filosofía del Wireframe.
Quita los detalles innecesarios: debe contener el mínimo número de elementos necesarios para que no distraigan la atención.
Anota cuidadosamente pero sólo lo realmente relevante.
Habrá que tener en cuenta además como se va a presentar, si va a ser un entregable deberá ser autoexplicativo por si mismo, pero si se va a presentar personalmente al cliente (como debería hacerse siempre para evitar interpretaciones subjetivas) no necesitará anotaciones tan detalladas.