Los tres botones

Desde hace varios meses tengo esta imagen en mi cabecera de Twitter y LinkedIn:

Tres botones rojos dispuestos horizontalmente

Alguien me preguntó por ella el otro día, así que vamos con la explicación.

Es una foto que hice en enero de 2010, hace más de 7 años, cuando trabajaba en Usolab, consultora de usabilidad y diseño centrado en el usuario.

Estos botones servían para encender y apagar las tres luces del piso de arriba de nuestras oficinas. Pero no era tan sencillo como puede parecer.

Para empezar, había un problema de mapeado: simplificando un poco (ya que la distribución de las luces era realmente perpendicular a la de los botones) la luz de la izquierda se encendía con el botón de la derecha y viceversa. El único botón bien situado era, claro, el central.

Pero había otra dificultad añadida. Es fácil ver que estos botones no parecen del todo convencionales. Si habéis trabajado alguna vez en un entorno industrial los reconoceréis como botones de seguridad. Para abrir el circuito (apagar la luz) funcionan como pulsadores, pero para cerrarlo (encender) es necesario girarlos 90º en el sentido de las agujas del reloj. Si os fijáis observaréis unas pequeñas flechas, bastante disimuladas, que lo indican.

Estos botones de seguridad son útiles para evitar encender maquinaria sin querer y poder apagarla rápidamente si es necesario; pero creo que estaremos de acuerdo en que no están diseñados para encender y apagar luces. Siempre me hizo gracia pensar en los distintos escenarios de uso de este mecanismo y cómo el único que estaba bien resuelto era “apagar la luz central”.

Pasé casi 7 años en Usolab. Nunca más me he rodeado de gente de la que haya aprendido tanto como en esa época; pero no quiero subestimar la influencia que tuvieron en mí estos tres botones, cuando manipulaba incorrectamente, día tras día, el pulsador equivocado.

Amazon no es una biblioteca

En un almacén de Amazon te puedes encontrar un DVD de Walking Dead cuidadosamente colocado al lado de unos pepinillos en vinagre. No, no es un ejemplo inventado, es literal:

Algunos estaréis ya familiarizados con el llamado “chaotic storage” que usan muchos almacenes: los productos se colocan básicamente al tun-tun, aprovechando cualquier espacio libre sin tener en cuenta la relación entre ellos (más allá de características técnicas como la humedad ambiente, temperatura, etc.)

El “truco” es que los productos se asocian al lugar de almacenaje en el momento de colocarlos (mediante códigos de barras), de forma que en cualquier momento si se necesitan unos pepinillos en vinagre el sistema sabe en qué puntos del almacén se pueden encontrar.

Esta técnica ofrece mucha flexibilidad, ya que no es necesario planificar cómo evolucionarán los stocks de los productos; pero además es muy eficiente, en tres sentidos:

  • Es eficiente en espacio, ya que se aprovechan mejor los huecos, y el espacio libre en general, al no tener que reservarlos para productos del mismo tipo
  • Es eficiente para organizar nuevos ítems, ya que no es necesario conocer dónde van, sino simplemente dejarlos en el primer sitio disponible
  • Y también es eficiente para recoger, ya que un mismo producto es probable encontrarlo en muchos puntos del almacén, consiguiendo así que las cuidadosamente calculadas rutas para recoger varios ítems acaben siendo más cortas

Pero…. Si este sistema de organización es tan bueno, ¿por qué no lo usan también las bibliotecas, por ejemplo?

La respuesta es que los escenarios de uso en ambos casos son distintos. Si en una biblioteca siempre buscáramos libros concretos (conociendo, por ejemplo, su título y autor) el sistema sería factible, pero la realidad es más compleja: nuestro interés en una biblioteca puede ser explorar un tema concreto, sin conocer exactamente qué buscamos; investigar en profundidad alguna cuestión, con un enfoque exhaustivo; o simplemente volver a un libro que ya cogimos en un pasado.

Antes de plantear sistemas de organización y navegación, es indispensable preguntarse si están presentes estos tres escenarios (búsqueda exploratoria, investigación exhaustiva y reencontrar) y no quedarse únicamente con la búsqueda de un elemento conocido.

La información que importa

Overwatch es un reciente videojuego desarrollado por la empresa Blizzard. Se trata de un FPS, un juego de disparos en primera persona, en el que se forman dos equipos de 6 jugadores que compiten entre sí por un cierto objetivo. La derrota o victoria está basada en lo que hace el equipo y no únicamente en el desempeño individual de cada jugador.

Es habitual en este tipo de juegos poder ver en cualquier momento de la partida cómo lo están haciendo tus compañeros, activando estadísticas varias, especialmente el número de bajas (kills) efectuadas por cada jugador.

Tabla de estadísticas del juego
Scoreboard de Battlefield 4 (tomado de Total Gaming Network) mostrando “K/D”, kills/deaths.

En algunos juegos, para estimular que los jugadores no se centren simplemente en matar, no se muestran las bajas, sino unos puntos que se otorgan según las acciones que está haciendo cada miembro del equipo.

Tabla de estadísticas, sin "kills" ni "deaths"
Scoreboard de Team Fortress 2 (tomado de Scalari.net)

Pero uno de los objetivos de diseño de Overwatch, según su director Jeffrey Kaplan, fue eliminar el individualismo y la competencia interna (entre miembros del equipo) inherente de este tipo de juegos. Para contribuir a ello tomaron una decisión interesante: no mostrar ningún dato concreto sobre los demás jugadores.

Imagenes de los jugadores sin datos de la partida actual
Scoreboard de Overwatch (tomado de The Guardian)

La arquitecta de información Abby Cobert, en “How to make sense of any mess” escribe:

The difference between information, data and content is tricky, but the important point is that the absence of content or data can be just as informing as the presence.

En Overwatch, Kaplan y su equipo han decidido eliminar datos para moldear la información que los usuarios percibirán. La realidad, del juego, sigue siendo la misma, pero al cambiar la fotografía que mostramos al jugador estamos influenciando en sus prioridades y, con ello, en su comportamiento.

En palabras de Kaplan:

So we basically stopped displaying any form of scores, kills, deaths because it really wasn’t telling the story of who was doing their job properly to win or lose as a team. And really, what it’s all about is, “Did you win or lose as a team?” None of that other stuff really matters at the end of the day.

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.