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.

Exigencia tecnológica

Llego a una puerta, agarro la barra vertical y estiro. No se abre. Estiro de nuevo. Sigue sin abrirse. Veo entonces un cartel indicando “Empujar” y una cierta sensación de estupidez me invade.

No creo que esta situación os resulte muy extraña. La tecnología nos hace sentir estúpidos cuando no sabemos utilizarla. Nos sucede con los ordenadores, los grifos del baño y constantemente con todo tipo de puertas. En The Psychology of Everyday Things, Donald Norman introduce este tipo de situaciones y las ejemplifica justamente hablando de puertas. Son las llamadas “Norman Doors”, puertas cuyo diseño nos indica que se deben abrir de una forma, pero realmente se abren al revés.

La revista Vox hizo recientemente un divertido vídeo con Norman sobre este tema:

Los que nos dedicamos a la usabilidad no solo intentamos que la tecnología, especialmente la digital, sea más fácil de comprender, aprender y utilizar; también pretendemos “evangelizar” para que cuando no sepamos utilizar algo no nos sintamos tan estúpidos, ya que en general la culpa no es nuestra, sino del diseño. ¿Pero lo estemos haciendo bien?

En el encuentro anual de profesionales de experiencia de usuario UXSpain, Asier Arranz hizo una interesante demostración en vivo de realidad virtual con unas Microsoft HoloLens. Durante la demostración intentó hacer una llamada vía Skype al centro de control del auditorio, pero a la primera no funcionó y tuvo que reiniciar Windows 10. “Esto nunca cambiará”, bromeó. Al segundo intento sí arrancó la videoconferencia y la sala estalló en un aplauso.

¿Por qué aplaudimos?

No me malinterpretéis, no le quito mérito a la charla ni al trabajo de Asier, y tengo presente que se trataba de un modelo especial, no comercializado y para desarrolladores; pero el aplauso me parece muy ilustrativo de las bajas expectativas que tenemos, me incluyo, con la tecnología digital.

Mi sensación es que ya no atribuimos tanto los problemas a nuestra torpeza, pero sustituimos la culpabilidad con simple condescendencia. Hemos llegado a un punto en que aceptamos que los programas se queden sin memoria y se bloqueen; que perdamos documentos de vez en cuando; que nuestro router deje de funcionar y tengamos que reiniciarlo (llegando al extremo de personas que compran sin ruborizarse este tipo de dispositivos); o que la mitad de llamadas que hacemos por Skype no conecten a la primera.

Nos sentimos tan identificados con el chiste de “esto nunca cambiará” al reiniciar Windows 10 que reímos implicados.

450 personas que nos dedicamos a la experiencia de usuario aplaudimos cuando algo, simplemente, se limita a funcionar como estaba previsto.

Da que pensar sobre dónde estamos realmente en la jerarquía de necesidades de Stephen P. Anderson.

Pirámide, de abajo a arriba: Functional, Reliable, Usable, Convenient, Pleasurable, Meaningful.
Modelo jerárquico de Stephen P. Anderson

 

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.

El puerto no está conectado

Apreciado Responsable de Mensajes de Error,

He visto un mensaje tuyo y de aquí que te escriba esta misiva.

Quiero que sepas que la gente, la normal, no tú ni yo, cuando lee la palabra “puerto” piensa en un “lugar en la costa o en las orillas de un río que por sus características sirve para que las embarcaciones realicen operaciones de carga y descarga, embarque y desembarco, etc.”

Esto explicaría que mi padre no te entienda si le dices que “el puerto no está conectado” cuando intenta imprimir la declaración de la Renta.

Que hayas decidido usar la palabra “puerto” me hace pensar que quizás tengas un perfil técnico. Tranquilo, yo también, te entiendo: te veo intentando cumplir un deadline absurdo y con la responsabilidad delegada implícitamente de escribir los mensajes de error que tus compañeros “de UX” no se han molestado ni en pensar. Sí, esos mismos que pasan más tiempo preocupándose sobre qué buzzword poner en sus biografías de Twitter que en hacer su trabajo; yo también conozco algunos.

Pero vamos a intentar mejorar este mensaje de error en concreto. Y no, no me digas nada más empezar que el mensaje sólo puede indicar el síntoma y no la causa del problema.

¿No es justamente “el puerto no está conectado” una causa probable del síntoma “no llega señal al puerto”? No creo que puedas saber, técnicamente, si el problema es que el dispositivo no responde o es que está físicamente desconectado; pero bien que asumes esto segundo. Y no, no lo critico, entiendo que intentas hacer un mensaje explicativo y útil. Conozco personas que habrían escrito “Error 0x0554” y se habrían ido a casa orgullosas de un trabajo bien hecho.

Hagamos algo. Cambia simplemente la palabra “puerto” por “cable”. Sí, ok, hay puertos software y máquinas virtuales. ¿Crees que es el caso de muchos de tus usuarios? Y sí, existen conexiones inalámbricas, pero podemos mostrar otro mensaje para estos casos ¿no?

Ya te estoy robando demasiado tiempo, lo sé. Admito que no es trivial. No es simplemente escupir cuatro palabras en el fichero de localización de strings de la aplicación.

Pero mira, hagamos una cosa, ni tu ni yo, mantén el mensaje original, tal cual, pon de hecho lo que te dé la gana, haz de esa ventana modal tu lienzo de expresión personal, pero añadamos una línea debajo: “Comprueba que la impresora no esté apagada o el cable desconectado”.

Gracias.