3

Validation Onion: La UX es mejor por capas, por Sergio Nouvel

Mi llegada a Lean UX fue una mezcla de intuición y accidente. Comencé a darme cuenta que los mismos problemas surgían una y otra vez en los proyectos en los que participábamos en Continuum: ideas que se ejecutaban sin ser cuestionadas, gerentes entrando al final del proyecto a cambiarlo todo desde cero, decisiones de diseño dominadas por el debate de “yo creo” versus “a mí me parece que”, diseños que al ser implementados por los desarrolladores terminaban desbaratados… ¿les suena?

Muchos se encogen de hombros y dicen que “así es la industria”, “así son los clientes”, y pavadas por el estilo. En realidad todos estos problemas son un defecto de gestión: los diseñadores tendemos a traspasar pasivamente al papel lo que escuchamos en las reuniones, como si se tratara de un retrato hablado. El rol de un diseñador debiese ser más bien el de un líder y moderador, que por añadidura tiene talento para plasmar ideas abstractas en productos y sistemas concretos. Pero, desde luego, es más fácil decirlo que hacerlo.

Pues aquí van cuatro ideas para empezar a allanar el terreno:

1. Todos deben estar sentados en la mesa desde el principio

Todos: diseñadores, desarrolladores, el dueño de la idea, las áreas involucradas y todos quienes tienen potencial de estorbar o cambiarle la dirección a un proyecto.

Cuando todos están participando de las decisiones desde el principio, se minimiza el tener que volver atrás, y por ende se reduce el riesgo (y menos riesgo equivale a más dinero). Asimismo, el trabajo de UX es alinear todas las visiones y necesidades en torno a una sola propuesta de valor. Cuando no hacemos este trabajo, se termina volviendo en contra nuestra en forma de constantes retrocesos y limitaciones que van apareciendo en el camino.

2. Amplía tu concepto de prototipo

¿Para qué prototipamos? Para saber si las cosas van a funcionar antes de construirlas a gran escala. Usualmente aplicamos esta idea a cosas físicas o tangibles. Pero ¿qué hay de las ideas abstractas que soportan a un producto o negocio, como la propuesta de valor?

Hay un concepto de simulación inherente en el prototipo, que es necesario para tomar el atajo entre la idea y la realidad. Y aquí viene la idea clave: las cosas intangibles también pueden ser prototipadas. Una idea de negocio, por ejemplo, puede ser prototipada llamando por teléfono a varios amigos y contándoles de un nuevo servicio que acaba de salir, como si existiera.

Prototipar las ideas antes siquiera de construirlas es especialmente útil porque no sólo lo necesitas para refinar tu propuesta de valor, sino también la manera de comunicarla.

3. La documentación está viva e incompleta

Nuestra memoria es frágil, pero nuestra memoria emocional lo es aún más (es así como nos enamoramos y des-enamoramos). Y entre las cosas que olvidamos más rápido es la motivación que tenemos para hacer algo. Todos hemos estado en esos proyectos (o empleos) donde todo es risas y canciones al principio, para un par de meses más tarde terminar exhaustos, desmotivados y preguntándonos quién nos mandó a meternos en esto. Necesitamos documentar tanto lo que vamos aprendiendo en el camino como las razones por las que este proyecto vale la pena: su propuesta de valor.

Y al mismo tiempo, esta documentación nunca puede ser una biblia dogmática, sino todo lo inverso: un punto de partida, un registro que está constantemente actualizándose. Si consideramos una documentación como “terminada”, significa que hemos dejado de aprender. Por eso es una buena idea que el registro sea una wiki o un Google Doc, algo que reciba las colaboraciones de todos y que se mantenga en continua edición.

4. Las decisiones más importantes vienen primero

Tal como en una casa el techo no puede ir antes que los cimientos, en los productos y servicios orientados al usuario también hay una jerarquía y orden lógico, sin el cual la construcción no tiene sentido. El problema es que, a diferencia de una casa mal construida, en el mundo digital es difícil distinguir cuando las cosas han sido hechas en desorden.

Y es así como tenemos proyectos que comienzan por el diseño gráfico y el look&feel antes de preocuparse de si el producto merece ser hecho en primer lugar. El orden en el que se construye un producto digital no es trivial; se gastan recursos de tiempo y dinero construyendo cosas que no han sido validadas en primer lugar. Podemos pasarnos meses iterando sobre una interfaz, para luego construirla y descubrir que nadie la quería.

Esto se conecta con el punto 1: dado que las decisiones más importantes para el proyecto son las que ocurren al principio, tiene sentido que estén todos los actores importantes en ese momento.

Imagino que el lector se preguntará: Ok, si hay un orden lógico, ¿cuál es?

Aquí es donde entra Validation Onion.

Cuatro capas de validación

Estas cuatro capas tienen una cierta inspiración en el modelo de capas de Experiencia de Usuario propuestas por Jesse James Garrett:

1. Scope

Aquí validamos la razón de ser del proyecto: su propuesta de valor, sus usuarios, la necesidad que soluciona, la variable que lo vuelve innovador respecto a lo ya existente, las limitaciones y recursos humanos y técnicos para llevarlo a cabo, etc. Esta capa debe asegurarse de que existe mercado: que hay personas con una necesidad concreta, dispuestas a comprar/usar el producto para satisfacerla.

2. Estructura

Una vez que hemos validado que el proyecto merece existir, debemos asegurarnos que sus features y funcionalidad son exactamente las requeridas a este punto. Esto también implica eventualmente definir una estrategia para construir un producto mínimo viable (MVP) y un roadmap de futuras funcionalidades en el caso en que el MVP se valide con los usuarios. Esta capa se asegura de que el producto sea simple en su esencia, más allá de su interfaz. La Arquitectura de Información es clave en este punto para definir flujos de usuario y la manera en la que se organiza el contenido.

3. Interfaz

Una propuesta de valor sólida y una estructura clara y entendible por los usuarios son la materia prima perfecta para un correcto diseño de UI. Aún cuando es cierto que empezaremos a prototipar desde la fase 1, es aquí donde se concentran todos los esfuerzos de lograr una interacción simple y elegante. No interesa el look&feel en este punto; esta capa se asegura de que el producto sea usable y sea percibido como simple.

4. Identidad

Cuando todo lo anterior ha sido definido, aquí validamos que el producto sea atractivo y enamore por su aspecto. En este punto los valores definidos en el Scope son más fácilmente trasladables a un diseño de marca; los aspectos diferenciadores de la interfaz (“signature moments”) son enfatizados, y a todo el producto se le da un carácter único.

validation onion
Modelo del Validation Onion

Sólo el comienzo

Cada una de estas capas de Lean UX merece un artículo aparte. Existen metodologías y herramientas que facilitarán la validación en cada etapa, muchas surgidas de la experiencia aplicando Validation Onion en projectos de muy variada naturaleza.

En las primeras versiones de esta metodología, las capas se llamaban “fases”. Me parece mejor el nombre “capas”, dado que sugieren una cierta simultaneidad; no podemos ver una sola totalmente abstraída de las demás. Por ende, incluso habiendo un orden lógico para estas capas, pronto se comienza a ver que los insights y decisiones de una capa impregnarán a las siguientes.

Este proceso está pensado para ser rápido y ágil: no debería durar más de 5-6 semanas para los proyectos más complejos. El trabajo de UX que demora meses antes de sacar algo a la luz no tiene cabida aquí. Los procesos largos, que toman meses, usualmente parten de una noción equivocada: que “tiene que resultar bien a la primera”.

Esto no es cierto: dado que no estamos construyendo cohetes espaciales o equipamiento médico, hay un cierto margen para la imprecisión. Dicha tolerancia al error es aprovechada por Lean UX, demorándose menos en validar con usuarios productos incompletos y premisas imperfectas. Esta agilidad permite aprender antes de los usuarios, disminuyendo el riesgo del proyecto antes que se gasten grandes sumas de dinero en construir e implementar.

Si quieres saber más sobre esta metodología, mira esta presentación.


Sergio NouvelSobre el autor:
Sergio Nouvel es emprendedor, consultor de UX y blogger.
Su twitter es @shesho.

 

Fatal error: Uncaught Exception: 12: REST API is deprecated for versions v2.1 and higher (12) thrown in /web/htdocs/www.uxinperu.com/home/wp-content/plugins/seo-facebook-comments/facebook/base_facebook.php on line 1273