Prototipando con wireframes

Los wireframes son prototipos de baja fidelidad visual que sirven para comunicar y proponer una solución de acuerdo a un entendimiento del problema / necesidad / oportunidad para un usuario determinado.

Fundamentos del prototipado

¿Por qué hablar de prototipos y no de sistemas de diseño? ¿Por qué cuando pensamos en diseñar sólo podemos imaginar una interfaz gráfica pixel perfect? ¿Cómo pueden ayudarnos las herramientas?

enlainterfazCarmel Hassan Montero

Como vimos en los fundamentos del prototipado, los wireframes se caracterizan por ser prototipos con ciertas ventajas:

• Rápido.
• Disponible en el momento preciso y en cualquier momento.
• Barato.
• Desechable.
• Crea un vocabulario claro.
• Imprecisos y por tanto flexibles y abiertos.
• Poco detalle y poco refinado.
• Sirve para sugerir y explorar.
• Ambiguo.
• Propositivo.
• Cuestiona el problema.

En este artículo nos centraremos en el los factores de diseño y proceso creativo de un wireframe asumiendo que ya se ha llevado a cabo un mínimo proceso de investigación y una exploración de ideas y entendiendo que el prototipo aún podría cuestionar ambas cosas.

Cómo crear un wireframe

Lo primero que debemos entender es que no existe un proceso lineal ni único para obtener un wireframe, ni existe tampoco el prototipo perfecto. De hecho, un wireframe debe ser imperfecto y podrá ser cambiado tanto como sea necesario mientras cumpla su propósito comunicativo.

Define el propósito

Una de las primeras decisiones que debemos hacer es decidir y definir el propósito de un wireframe y esto depende del proyecto, el equipo y el problema.

Por ejemplo, no llegaremos al mismo nivel de definición si yo soy la única diseñadora del equipo a si habrá más diseñadores que tengan que tomar decisiones: lo que para mí puede quedar claro sin necesidad de pintarlo puede no ser evidente para el resto de mi equipo.

Tampoco llegaremos al mismo resultado si el wireframe va a ser compartido con algún cliente, si va a ser usado para evaluar alguna solución con usuarias, si va a ser usado para codiseñar, o si es una primera especificación para el equipo de desarrollo. Puede que necesitemos pasar por ciertas etapas o iteraciones en algunos casos y en otras no.

Cuando tengamos claro el propósito nos será más fácil poner límites y decidir qué recursos necesitamos. En general, el wireframe es anterior a un diseño de alta fidelidad y posterior a un proceso de investigación:

1. Definir el problema (investigación)
2. Explorar soluciones (sketches)
3. Definir una solución (wireframes)
4. Especificar una solución (prototipo de alta fidelidad)
5. Desarrollo de la solución (código)

¿Qué podemos comunicar con un wireframe?

• Pantallas principales.
• Navegación.
• Interacción no evidente.
• La arquitectura de la información.
• Layout (*).
• Elementos de información más importantes.
• Variaciones de diseño.

(*) Algunos autores creen que el layout es algo que debería quedar fuera de un wireframe. Sin duda, el layout es un elemento que influye mucho en el aspecto visual, y por tanto debería dejarse para una etapa de mayor fidelidad. En mi opinión, el wireframe puede y debe dar ciertas indicaciones (expectativas) de cómo debería ser el layout o estructura visual, la cual puede y debe revisarse cuando se haga la propuesta visual definitiva.

Elegir la herramienta

Por lo general, tenemos muy asociado la creación de wireframes con herramientas digitales (Balsamiq, Figma, Penpot, Axure, etc.).

En el libro Sketching User Experiences, Bill Buxton explora decenas de formas diferentes de abordar la etapa de exploración (sketches) y definición (wireframes o prototipos de baja fidelidad) usando herramientas físicas o una combinación de ambas.

Sketching User Experiences: Getting the Design Right and the Right Design

Sketching User Experiences approaches design and design thinking as something distinct that needs to be better understood—by both designers and the people with whom they need to work— in order … - Selection from Sketching User Experiences: Getting the Design Right and the Right Design [Book]

O’Reilly Online LearningBill Buxton

Además, en su cuaderno de trabajo, puedes practicar el prototipado de múltiples ideas con interacciones diferentes.

Por ejemplo, una herramienta como Balsamiq te permite comenzar el prototipado diseñando conceptos como si fueran sketches que podrás pasar rápidamente a wireframes clicables. Sin embargo, no te permitirá definir componentes reutilizables con diferentes estados y que permitan interacciones complejas como sí podría hacerlo Axure, la cual nos ayudaría a crear prototipos fácilmente evaluables con usuarios reales.

En Figma o Penpot, podremos diseñar wireframes fácilmente convertibles en prototpos de alta fidelidad y ayudan al equipo de diseño a imaginar/visualizar interacciones como si fuese el producto final, incluso preparar los diseños para su entrega al equipo de desarrollo.

Por lo tanto ¿Cómo elegimos la herramienta adecuada? Depende del propósito del prototipo.

No podemos ignorar que la gran mayoría de las herramientas de prototipado tienen licencias de pago con suscripciones mensuales que obligan a los equipos de diseño a adquirirlas antes incluso de saber qué proyectos que realizarán.

Para tomar estas decisiones deberemos al menos conocer cuál es el proceso de diseño y colaboración con equipos que vamos a seguir.

¿Vamos a trabajar en baja fidelidad muy a menudo porque solemos codiseñar o explorar soluciones con el equipo de producto? Entonces puede que algo como Balsamiq te ayude.

¿Vamos a hacer tests de usuario con tal frecuencia que requiera una herramienta que dé independencia al equipo de diseño? Entonces una licencia de Axure puede merecer la pena.

¿Vamos a trabajar codo con codo con el equipo de desarrollo de manera que iremos transformando conceptos en diseños finales con frecuencia? Usa Penpot que es opensource o plantéate pagar por Figma.

Definir una estructura básica

Uno de los primeros pasos para empezar a diseñar con la herramienta elegida será la de crear o definir una estructura básica. Aunque esto a veces no es tan simple como crear una estructura de columnas sin más.

Las rejillas tradicionales que ha heredado el diseño web del diseño gráfico (de impresión) están cada vez más en desuso, la razón es que la pantalla no es un espacio físico fijo sino adaptable donde los elementos pueden disponerse de forma diferente según tamaños y resoluciones variables.

Un grid o rejilla que puede ser más útil consistiría en definir regiones y entonces sí, decidir el espacio entre ellas, incluyendo incluso las adaptaciones a diferentes dispositivos y resoluciones.

Definir los elementos gráficos

Como hemos indicado, un wireframe no es un prototipo de alta fidelidad visual, pero sí requiere de elementos gráficos que den significado a lo que pintamos para que se entienda en su contexto.

Para ello, nos valdremos de los siguientes elementos:

• Escala de grises.
• Sin (casi) ilustraciones, imágenes o iconografía.
• Poco texto.
• Fuente sin personalidad.
• Elementos proporcionados pero no medidos al píxel.
• Frames al tamaño del dispositivo.

Aunque ya hemos visto ejemplos de diseños en blanco y negro, es decir, que sólo utilizar una variación de color, cuando prototipamos con wireframes es conveniente jugar con varios tonos de grises para poder comunicar la jerarquía visual correctamente ya que no siempre contaremos con el contenido final.

Usaremos la mínima iconografía y casi ninguna imagen o ilustración para no interferir en la estrategia visual aún. La iconografía de usarse, será la más estándar posible para evitarnos sobrexplicar conceptos como, por ejemplo, un icono de búsqueda dentro de un rectángulo es suficiente para entender que ese elemento funcionará como un buscador.

Romper el hielo ¿por dónde empezar?

Antes de comenzar a crear el wireframe con una herramienta de diseño como Penpot, Figma o Sketch, el punto de partida puede ser diferente.

Si nos encontramos un mapa de experiencia, puede facilitarnos la identificación de una secuencia en la navegación. Si partimos de un análisis de competidores, puede que tengamos más claro el vocabulario y las funcionalidades que vamos a representar. Si se han dibujado sketches, puede que tengamos alguna idea sobre el dispositivo y los elementos de información principales que dirigirán la experiencia.

Sea cual sea, un primer paso puede ser crear una página dedicada en exclusiva con las capturas de todos esos artefactos visuales que representan parte de los requisitos a diseñar.

Junto a ello podemos ir tomando notas personales, tales como:

• Ideas de interacción.
• Preguntas que no estén resueltas.
• Hipótesis que se van a asumir.

También podemos crear junto a ellos un pequeño moodboard, con diseños que nos hayan inspirado y que estén relacionados con alguno de esos conceptos. No nos preocuparemos por ponerle orden, sino simplemente ir coleccionando esas ideas para tenerlas a mano. Incluso si nos atrae una idea por su aspecto visual es bueno volcarla en este moodboard para ser capaces de abstraerla y representarla a bajo nivel.

Definir una pantalla principal

Lo recomendable es comenzar el wireframe por la(s) pantalla(s) que tengamos más clara y que represente algo diferente y relevante, es decir, la pantalla de inicio que se verá con más frecuencia por la gran mayoría de tus usuarias.

Aunque en muchas ocasiones las soluciones que propongamos tienen como punto de partida la autenticación de usuarios, evitaría diseñar pantallas de registro en estos momentos porque a bajo nivel no aportan gran valor. La excepción a esta regla sería en caso de tener que representar un concepto muy innovador en la autenticación o registro o si se han definido más flujos, cuando éstas ayuden a entender en qué momento debe existir autenticación de usuarios.

En el artículo de Espacio UX encontramos un ejemplo de wireframe donde sí aporta valor el diseño del registro (Paso 2) ya que se representa una secuencia de pantallas. El hecho de que se incluya no quiere decir que haya sido la primera pantalla diseñada.

Como curiosidad mencionar cómo una pantalla con apenas cajas y líneas puede entenderse perfectamente como caja de autenticación dentro de su contexto, es más, el Paso 1 está completamente vacío y también se entiende su utilidad.

Punto de partida: Pantalla (con contenido) de inicio

La pantalla principal la iteraremos tanto como creamos conveniente hasta encontrar el nivel de detalle deseado, a partir de aquí, iremos añadiendo otras pantallas navegables y que estén conectadas y sólo al final nos centraremos en incluir interacciones poco evidentes de algunos de los elementos del prototipo.

Por lo tanto el proceso sugerido es:

1. Diseñaremos una pantalla principal.
2. Iteramos hasta definir un nivel de detalle.
3. Incluiremos nuevas pantallas conectadas.

Incluye (algunas) interacciones

Una vez tengamos las pantallas donde ya pueda verse el flujo de navegación, la estructura visual y la arquitectura de contenidos, podemos comenzar a incluir un nivel más de detalle: microinteracciones.

Las microinteracciones son aquellas interacciones que ocurren en componentes visuales más elementales. A veces son animaciones de transición de un elemento interactivo, otras veces son mensajes de confirmación o de estado en general, otras veces muestran cómo aparecen o desaparece un contenido dependiendo de la acción de un usuario.

Es decir, toda interacción (más allá de la navegación de una pantalla a otra) que suponga un cambio en el estado de la interfaz dentro de la misma pantalla.

El diseño de microinteracciones en esta etapa del diseño, es decir, como prototipo de baja fidelidad o wireframe no debería comprometerse mucho en decidir el timing de una animación sino más bien la idea de cambio de estado, modificación o transformación de un elemento de información.

Añade anotaciones

Siempre es deseable que las pantallas hablen por sí mismas, pero no podemos ignorar que un wireframe es por definición ambiguo.

En algunas ocasiones puede ser necesario incluir algunas anotaciones al margen del diseño que faciliten la comprensión de los elementos que se representan y que nos ahorren incluir demasiados detalles gráficos.

Las anotaciones pueden incluir:

• Explicaciones de interacciones de difícil representación
• Elementos de información que no aparecen en ese momento
• Descripción del comportamiento de un elemento
• Indicaciones para otras personas del equipo (copywritters, desarrolladores/as, etc.)
• Explicación de alguna decisión de diseño no evidente

Intentaremos, no obstante, mantener el nivel de anotaciones el mínimo posible para no sobrecargar la comprensión del wireframe en general.

Como se

Otras consideraciones

A continuación quiero incluir este pequeño ejemplo para hacer algunas consideraciones adicionales sobre el diseño de wireframes.

Los wireframes también deben iterarse

Aunque siempre insistimos en la idea de que los prototipos son elementos desechables y sin gran nivel de detalle eso no significa que no pueda perfeccionarse hasta alcanzar un nivel de definición adecuado al propósito.

Habrá veces que con sólo diseñar cajas (véase 1.0) pueda ser suficiente para comunicar la estructura, pero que para revelar qué contenidos se espera incluir tengamos que incluir alguna etiqueta (véase 1.1) e incluso algún ejemplo de contenido real (véase 1.2).

No nos olvidemos que los prototipos son artefactos comunicativos y deben revisarse tanto como sea necesario.

En el libro Communicating Design de Dan Brown es un gran recurso para entender cómo usar wireframes dentro de un conjunto de artefactos y herramientas de comunicación del diseño.

Communicating Design: Developing Web Site Documentation for Design and Planning, Second Edition

Most discussion about Web design seems to focus on the creative process, yet turning concept into reality requires a strong set of deliverables--the documentation (concept model, site maps, usability reports, … - Selection from Communicating Design: Developing Web Site Documentation for Design and Planning, Second Edition [Book]

O’Reilly Online LearningDan M. Brown

Diseñar con o sin contenido

Otra decisión que debemos hacer en algún momento es cuándo debemos incluir algo de contenido (aunque no sea el final) en el prototipo.

A veces, cuando el contenido no es generado por los usuarios sino que es, por ejemplo, el diseño de una web o un dashboard, es decir, una pantalla con un claro propósito informativo, el contenido es una de las primeras cosas a incluir en el wireframe.

Utilizaríamos por tanto una estrategia Content First para poder adelantar cuanto antes decisiones importantes sobre el diseño de contenidos y de la información y también porque el diseño de los contenidos realistas puede influir en decisiones sobre:

• Estructura de la información,
• revelación progresiva,
• densidad de datos
• y representación gráfica de los mismos.

Además, cuando ponemos wireframes con un buen diseño de contenidos frente a usuarios, éstos se olvidarán de elementos gráficos no importantes y se centrarán en lo que les da valor, pudiendo obtener una validación temprana de la arquitectura de información antes de entrar en detalles de microinteracciones, componentes interactivos, etc.