Experto en Axure

Como algunos sabréis, sigo desde hace tiempo las andaduras del director de cine (y daily vlogger) Casey Neistat.

Este personaje, que asumo puede despertar odio y amor a partes iguales, tiene un aparente desprecio absoluto por las herramientas que utiliza para grabar. En cualquiera de sus vídeos es fácil comprobar cómo trata despreocupadamente su cámara y es habitual verle visitar tiendas de fotografía para, simplemente, cambiar la lente que acaba de destrozar en la toma anterior.

Varias veces Casey Neistat ha descrito los principios que rigen este comportamiento, pero nunca tan bien como en un reciente vídeo:

“All I want from my camera gear is to get the hell out of my way, so I can make videos”

Todo lo que hay entre él y su audiencia, dice, son dificultades a las que debe hacer frente, pero que en ningún caso son el foco u objetivo de su trabajo.

I hate camera gear. Just leave me alone so I can make movies.
Tomado de Casey Neistat

Todos los que hacemos trabajo no tangible, como arquitectura de información, estamos en una situación similar. Queremos comunicarnos con una audiencia (un cliente, un compañero de trabajo, desarrolladores, un supervisor…) y para ello usamos herramientas de prototipado, entornos para compartir ficheros, servicios de videoconferencia y obviamente el propio sistema operativo de nuestro ordenador.

Lo lógico sería que estos intermediarios digitales fueran lo menos importante de nuestra profesión, pero curiosamente no es así. En algunos cursos de formación del sector se dedican más horas a aprender a utilizar herramientas concretas que a realmente diseñar. Veo más ofertas de trabajo solicitando “Experto en Axure” que “Arquitecto de información”. Y algunos currículos parece que la única forma que tienen de justificar su experiencia es en “horas de vuelo” de Sketch.

Al final todo este asunto me recuerda a la clásica pregunta que hacen algunos curiosos a los fotógrafos: “¿saca buenas fotos esta cámara?”.

De momento, al menos, nadie me ha preguntado si mi Axure saca buenos prototipos.

Nuestro trabajo no es real

Cuando hablo de prototipado en alguna de mis clases, a veces acabo con un breve fragmento del libro Prototyping: A Practitioner’s Guide de Todd Zaki Warfel:

“Prototypes by their very nature are somewhat incomplete, sketchy versions of the final product. They’re not perfect. They don’t have to be. They’re not meant to be”.

La cita pertenece a una sección cuyo mero título me parece revelador: “It’s a Prototype – Not the Mona Lisa”.

Nuestro sector ha desvirtuado totalmente el propósito de los prototipos. Muchas agencias y consultoras han convertido una herramienta para comunicar ideas de diseño en una finalidad en sí misma. También técnicas de modelización, como las personas o los user journeys, han pasado de ser herramientas para comprender la realidad a partir de su simplificación, a ser bonitos entregables con los que únicamente deslumbrar al cliente.

Mezclamos el objeto con su representación. Confundimos la meta con el camino.

Y claro, no es raro que salten voces críticas diciendo que estamos todos perdiendo el tiempo; pero no creo que la solución sea abandonar estas técnicas.

Mi propuesta es que dejéis de vender los proyectos como si fuéramos una charcutería, a kilo de wireframe; dejad de prometer entregables en las propuestas sin saber qué necesidad comunicativa van a tener; dejad de tener a un diseñador una jornada entera de trabajo dibujando muñequitos en un user journey cuando no es estrictamente necesario.

Hay una empresa que ha hablado largo y tendido de este tema: Basecamp (antes 37Signals), que ya en el año 2006, con Jason Fried y David Heinemeier Hansson a la cabeza, lanzaba un libro llamado Getting Real. En uno de sus capítulos podemos leer:

“Stories, wireframes, even html mockups, are just approximations. Running software is real”.

Repetid el mantra: «solo el software es real«. El destino final de nuestros prototipos y otros entregables es el mismo que el del catálogo de ofertas del supermercado de la esquina: la papelera.

Los diseñadores

Cuando entró en la oficina sólo quedaban tres personas. Eran diseñadores de interacción. Los tres estaban ensimismados en sus puestos de trabajo.

Se acercó al primero, que estaba usando el ordenador, trazando cajas y líneas en blanco y negro, con mucha concentración y mimo. Observó cómo a veces se acercaba a la pantalla para asegurar que la alineación era correcta.

—¿Qué haces? —le preguntó.
—Preparo un entregable para un cliente—respondió.

Se dirigió entonces al segundo, que movía en su ordenador cajas de un sitio para otro con mucho menos esmero que el primero.

—¿Qué haces? —preguntó.
—Diseño una interfaz—dijo rápidamente.

El tercero tenía el ordenador apagado; estaba ante una libreta, dibujando descuidadamente también cajas y líneas, tachando continuamente y volviendo a empezar.

—¿Qué haces? —preguntó por tercera vez.
—Hago más eficiente pagar en un parquímetro—contestó.

Al salir de la oficina se encontró a un cuarto compañero en la calle. Estaba apoyado en la pared, con las manos en los bolsillos, mirando fijamente cómo alguien usaba un parquímetro.

—¿Qué haces?
—Intento mejorar la vida de la gente de la ciudad.

Consultor o diseñador

Un consultor es alguien que asesora profesionalmente, que “da su parecer”. El consultor es llamado para ayudar a resolver un problema, lo analiza y da su parecer sobre cómo solucionarlo, pero no soluciona nada.

Ese parecer, en ocasiones, puede asemejarse a un diseño. El consultor puede entregar un diagrama de cómo él considera que se debería organizar esto o presentar unos garabatos de aquello; pero estos entregables no son el fin, son únicamente un medio para transmitir o comunicar su parecer.

El cliente recoge ese parecer, lo estudia y hace algo que el consultor nunca podrá llevar a cabo mientras siga siendo consultor: toma decisiones. Con ello el cliente esboza un plan, que podrá ser modificado, ampliado o descartado más adelante, pero ese plan sí es diseño.

El consultor que aspira a ser diseñador estará eternamente frustrado. Se desesperará al ver que el producto final no es como su imaginación proyectaba. Se irritará cuando por falta de una visión global sus propuestas iniciales sean descartadas. Llorará al ver que no tiene control sobre el futuro del proyecto.

Si tú, lector, te sientes identificado con este último párrafo te aconsejaría lo siguiente: cambia de profesión o asume la realidad: lo que haces es consultoría, no diseño.