Pienso, luego diseño

Publicado el 13 / 07 / 2015

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 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:
Wat

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...

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

mindmap
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

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.


Escrito por

Te puede interesar

  • http://rodrigotello.me Rodrigo Tello

    Interesnate el artículo y que se desmenuse un caso en específico. Pero creo que decir “la solución era muy sencilla y nos tardamos mucho en verla” es un poco redundante y decir que había una forma de saberlo. Creo que precisamente el proceso de lo que aquí se llama “no planeación inicial”, fue absolutamente necesario para después dar con una metodología apropiada. Lo que se hizo inicialmente fue una apuesta educada. No significa que generar docs de Sepcs y usar Balsamiq vaya a salvarlos de haber “perdido tiempo”, que en realidad, es trabajo.

    Gracias por compartir.

    • 25Horas

      Es cierto, el primer alcance probablemente era una manera correcta de atacar el problema, pero el problema fuerte es que no se rebotó la idea y se pasó directamente al prototipo en HTML y CSS, eso sí fue para mí la pérdida de tiempo. Sobre todo es eso, el haber pasado al trabajo fuerte y volver al punto de inicio de cero. De otra forma, se pudo rebotar la idea antes en los mockups y hacer modificaciones o seguir proponiendo en esa etapa, y ahí en adelante el trabajo podría ser más fluido.

      En fin, todo es aprendizaje.

      Que bueno que te haya interesado este artículo 🙂

    • 25Horas

      Es cierto, el primer alcance probablemente era una manera correcta de atacar el problema, pero el problema fuerte es que no se rebotó la idea y se pasó directamente al prototipo en HTML y CSS, eso sí fue para mí la pérdida de tiempo. Sobre todo es eso, el haber pasado al trabajo fuerte y volver al punto de inicio de cero. De otra forma, se pudo rebotar la idea antes en los mockups y hacer modificaciones o seguir proponiendo en esa etapa, y ahí en adelante el trabajo podría ser más fluido.

      En fin, todo es aprendizaje.

      Que bueno que te haya interesado este artículo 🙂

  • Alice Vielmas

    Me gusto mucho este artículo porque expones un caso real, es interesante como a veces como diseñadores podemos caer en pensar que no es necesario o tan prioritario tener un feedback, ya sea con los desarrolladores, el cliente o incluso con usuarios (testing) antes de pasar nuestro diseño al código.
    Yo también me he topado con esas situaciones y es muy frustrante el tener que tirar algo que ya trabajaste por la borda. Algo que he implementado y que sirve mucho es hacer storymappings en conjunto con el equipo de desarrollo, incluso con el cliente, es muy útil y salen ideas muy interesantes. Otro recurso que ayuda mucho es antes de empezar con el diseño, definir las rutas de los usuarios en diferentes casos o escenarios, así puedes identificar más fácilmente posibles situaciones a las que se enfrentará el usuario y pensar en que implementar para que el proceso de realizar las tareas deseadas sea más fácil.

    Saludos!

  • Genesis Molina

    Es algo super importante porque no podemos diseñar y luego pensar en que lo basamos, para empezar a diseñar debemos de pensar en nuestro concepto y en que nos inspiraremos, muchas veces cuando ya estamos cansados se nos tapa la mente y ya no sabemos que hacer, para eso es importante leer este tipo de blog y ver que otras rutas tomar antes de diseñar..