Pienso, luego diseño

Como experiencia personal, la planeación es algo que he ido desarrollando poco a poco. Principalmente a base de topes contra la pared, y en parte por haberme acostumbrado a trabajar al ritmo de las agencias donde todo es para ayer. Les compartiré un poco sobre mi experiencia y los problemas que tuve que enfrentar.

El problema de no planear

Es fácil ponerse a trabajar en un proyecto por inercia. A veces parece que una vez que se empieza, el trabajo saldrá rápido.

Sin embargo, en medio del proyecto empiezan a surgir todos los elementos que no se contemplaron en un principio. El proyecto se alarga, los parches aparecen y el proyecto pierde forma.

En mi caso identifiqué que esta forma impulsiva de atacar un proyecto provocaba:

• – Falta de visión, y un análisis de muy poco alcance
• – Retrabajo constante de diseño
• – Y sobre todo… Pérdida de tiempo

Un caso de la vida real

Estuve trabajando hace algunos meses en una nueva funcionalidad para Boletia, que involucraba crear una nueva forma de registro para que el organizador pudiera obtener información por boleto.

El equipo de diseño comenzó a trabajar con propuestas para diferenciar la forma de registro por reservación y por boleto. Se hicieron bocetos y se rebotaron ideas, se tomó una decisión (sólo entre el equipo de diseño) y se comenzó a trabajar directamente en el prototipo.

El primer ejercicio de boceto, limitado, y sin mucho análisis…

El problema fue que no se contempló el panorama completo, sólo se pensó en la solución directa, no en lo que afectaría.

Entonces cuando rebotamos el prototipo con el resto del equipo de producto surgió este cuestionamiento:

“Pero… ¿cómo van a navegar entre las formas de registro?”

A lo que se argumentó de esta manera:

No habíamos contemplado las implicaciones del diseño en la navegación del usuario, así que tuvimos que dar un paso atrás, volver a la planeación y tirar el trabajo a la basura.

Segunda etapa de bocetos…

Una vez más volvimos a bocetar ideas cada vez más y más rebuscadas, que sólo hacían más y más complicada la navegación y la usabilidad de la funcionalidad. Hasta que finalmente se llegó a una pregunta:

“¿Y si los separamos como dos secciones distintas en el menú?”

Así de fácil era la solución. Así de sencilla, directa y lógica era la respuesta a un trabajo de semanas… Pero no lo habíamos visto porque contemplamos un panorama muy reducido y nos habíamos acostumbrado a trabajar por inercia. Una lección muy frustrante de aprender porque el tiempo invertido fue demasiado.

La solución: Story Centered Design

Estuve buscando recursos para definir un proceso de diseño que nos asegurara una mejor productividad y un mejor enfoque para atacar un problema. Afortunadamente encontré muchos artículos interesantes, principalmente de la página de Google Ventures donde pude encontrar un camino sobre cuál trabajar para asegurarnos de tener una buena solución antes de hacer un prototipo.

Para empezar, el trabajo basado en el diseño centrado en la historia (Story Centered Design) promueve que cada problema y necesidad se plantee de forma natural, esto es, a través de una historia. Cada usuario tiene un camino para llegar del punto A al punto B, esto es una historia. Así que como diseñadores debemos contemplar las historias de cada usuario para que todas tengan como punto final nuestro objetivo.

Así es como desglosé el proceso de planeación en los siguientes pasos:

Specs

En esta etapa se definen los objetivos y las hipótesis que podrían hacernos llegar a la solución de un problema.

Mindmaps

Después de los specs definidos, comienza la lluvia de ideas, sin un orden en especial. Es muy importante contemplar posibles soluciones en diseño e interacción, analizar el flujo de una funcionalidad, y pensar en mensajes claros para brindar certeza al usuario (Lorem ipsum en estos casos puede causar más problemas).

Mockups

En el camino me encontré con un ejercicio muy interesante para refrescar el proceso de diseñar mockups y estimular la creatividad. El Crazy Eights es un ejercicio en el que la persona tiene que hacer 8 propuestas en 5 minutos (o sea 40 segundos por propuesta). Me gusta mucho esto porque si antes de empezar tienes en mente, digamos, 3 propuestas, no hay problema, porque hay suficientes espacios disponibles como para que pienses en algo nuevo.

Una vez que concluye el ejercicio, se rebotan las propuestas, se da forma al flujo de interacción y se preparan los elementos para traducirlo a un Storyboard.

Storyboard

El storyboard es precisamente la parte donde se presenta la historia a través de pantallas e interacciones de la aplicación. Las formas de presentarlo pueden variar, desde hacerlo en el pizarrón, en vistas estáticas en Balsamiq o con un poco de interacción simulada a través de Invision.

El objetivo es involucrar a todo el equipo de producto a revisar el alcance y corroborar si la propuesta es posible de ejecutar o si se deben hacer adaptaciones. Al final, el trabajo de equipo ayuda a que todos estén en el mismo plano y que los esfuerzos en conjunto ayuden a salir más rápido para liberar nuevas funcionalidades constantemente.

—

Desde que apliqué este proceso sin duda que me ha ayudado a trabajar de forma óptima y evita que me llegue a ciclar en algún momento por no tener claro cuál es el objetivo y andar gastando tiempo.

En su experiencia, ¿cuáles han sido los retos que han enfrentado al abordar un proyecto?, ¿aplican un método de trabajo diferente?

Este ha sido un artículo basado en mi presentación para el proyecto Design The Future, una serie de reuniones entre diseñadores web, si desean pueden formar parte del grupo y estar al pendiente de la reunión del próximo mes.

Te puede interesar