De la colina a la montaña

Hace unos años, cuando empecé a trabajar en consultoría de usabilidad, era difícil convencer al neófito de la utilidad de las evaluaciones empíricas, es decir, todas aquellas técnicas de testing basadas en la experimentación y la observación, como el test tradicional de usabilidad o el “moderno” test A/B.

Hoy en día, probablemente gracias a (o por culpa de) la popularización de enfoques lean y sus famosos MVP (mal entendidos), empezamos a observar lo contrario: algunos equipos de diseño han integrado tanto estas técnicas de evaluación que toman más protagonismo que la propia generación o construcción de soluciones. Son entornos donde se dedica muy poco esfuerzo a la investigación generativa (entrevistas con usuarios, etnografía, etc.) y se intenta sacar algo lo más rápido posible para luego optimizar mediante tests.

Este enfoque creo que tiene varios problemas, entre ellos el que describía Alan Cooper recientemente:

Yo lo veo así: observad el siguiente dibujo e imaginad que se trata de un espacio de soluciones a un problema, siendo la altura la representación de la calidad de cada alternativa (entendida como consideréis: eficiencia, conversión, utilidad, usabilidad, etc.)

Una representación tridimensional muestra dos picos parecidos a montañas, uno más bajo a la izquierda y otro más alto a la derecha.

 

 

 

 

 

Si nuestro objetivo es llegar a lo más alto, nos interesa subir a la “montaña” de la derecha (óptimo global de la cordillera); pero si escogemos un punto de partida mediocre en la zona izquierda y nos limitamos a ascender ciegamente mediante pequeñas mejoras dirigidas por tests, lo único que conseguimos es subir poco a poco una colina (nuestro óptimo local actual).

El salto de la colina a la montaña no procederá nunca de la evaluación empírica por si sola. Se requiere lo que en genética se llamaría una mutación, un salto más grande y peligroso, cuyo riesgo podemos reducir (¡sorpresa!) mediante la tan denostada y poco “científica” investigación generativa.

Una historia de investigación

La agencia mandó a dos consultores, una chica y un chico. Él iba con un traje de dos piezas, americana cruzada, corbata de seda… ella con un traje falda de entallado clásico: recta y sin corte. Se sentaron y nos hablaron de lo importante que era nuestro proyecto para ellos. Insistieron en que antes de diseñar era imprescindible conocer a los usuarios; al parecer era crítico para el éxito del producto.

Qué bien sonaba todo. Qué distinto a la anterior empresa que habíamos contratado, que se habían puesto a diseñar sin apenas preguntarnos ni a qué nos dedicábamos.

Accedimos a trabajar con ellos. Preguntamos si se encargarían personalmente del diseño. Rieron y nos dijeron que no, que ellos gestionarían el proyecto y “conducirían la investigación”, pero no harían el diseño. El tono de voz era casi de sorna, de desprecio, ¡el diseño parecía lo menos importante de todo el proceso! ¿Tan equivocados estábamos? ¿Tan importante era la investigación?

En la primera sesión de investigación los consultores nos habilitaron un ordenador en una de nuestras salas para poder observar a distancia. La licencia del programa que utilizaban era muy cara, pero entendíamos que valía la pena. El chico se quedó con nosotros y sacó un paquete de notas adhesivas y varios rotuladores. La chica estaba en otra sala donde iban llegando participantes que habían sido invitados a la sesión conjunta de investigación.

“¿Dónde está el diseñador?”, pregunté. Asumía que era importante que estuviera presente, pero me indicaron que estaba ultimando otro proyecto y no había podido venir.

El consultor nos dio las notas adhesivas y nos pidió que fuéramos escribiendo nuestras observaciones y pegándolas a la pared. ¿Observaciones de qué?, me preguntaba, pero no lo explicité en voz alta por si quedaba en evidencia pidiendo aclaración de algo tan obvio. La sesión empezó y los participantes hablaban y hablaban. No me quedaba claro qué era relevante y qué no. El consultor que nos acompañaba parecía tomar notas en su ordenador. ¿O estaba respondiendo correos de otros proyectos? Esperaba que fuera lo primero.

“A mí no me gusta el producto de la competencia”, comentaba un participante. “A mí sí”, decía otro. Anoté “a algunos les gusta el producto de la competencia y a otros no” y lo pegué en la pared justo al lado de la nota de un compañero, en la que estaba escrito: “el producto debe ser sensual”.

La sesión duró casi dos horas. La pared estaba llena de notas. El consultor nos indicó amablemente que fuéramos agrupando la información en conjuntos relevantes para nosotros. Lo intentamos y una vez lo dimos por terminado, él sacó una foto y empezó a guardar sus cosas. Al parecer la sesión había acabado. Ahí finalizaba la investigación, asumí.

Tres semanas más tarde nos reunimos de nuevo. Los consultores traían unos diseños, pero el diseñador seguía sin acompañarlos. Pregunté por él y me indicaron que estaba ya con otro proyecto.

La propuesta se parecía mucho al producto de la competencia y me vino a la cabeza una de las notas que escribí. “A algunos no les gustaba el producto de la competencia”, comenté. Esperaba una justificación, pero los consultores se mostraron sorprendidos ante mi intervención. Admitieron que sí se parecía un poco y que se lo dirían al diseñador inmediatamente.

Pregunté cómo habían transmitido los resultados de la investigación al diseñador. Ambos consultores se miraron confundidos. Concreté: “¿ha visto la grabación?”. Ella intervino y respondió que no, pero añadió que el diseñador había analizado “minuciosamente” las conclusiones obtenidas. “¿Qué conclusiones?”, pregunté honestamente. Una segunda mirada entre ellos me lo explicó todo: la foto a las notas adhesivas era las conclusiones de la investigación. Ahí había acabado todo el proceso. No había más análisis que la mera recopilación de nuestras propias inexpertas observaciones.

Semanas más tarde cerrábamos el proyecto. El resultado final no me pareció malo, pero me pregunté sinceramente si esa investigación había aportado algo. Decidí no contar más con esa agencia e inicié conversaciones con otros profesionales.

Un día contacté con un tipo barbudo que se presentó en la oficina en tejanos y medio desaliñado. “Será barato”, pensé inmediatamente; pero poco tardó en hablarnos también de la importancia de la investigación. ¿Otro que nos quería vender la moto? No contento con ello, empezó a mencionar una nueva fase entre investigación y diseño. Imprescindible, decía; “modelización”, la llamaba. ¿Qué cojones? ¿Modelizar? ¿Cuántas tonterías se inventaría esa gente para vender más?


Esta historia, obviamente, es una caricaturización de la realidad, pero basada en un cocktail de casos que me han ido transmitido clientes y compañeros. La tenía escrita de hace tiempo, pero al dejársela leer a un amigo en su momento me comentó que no le gustaba ese mensaje final de “vender humo”. Consideraba que no era cierto y que lo que genera estas situaciones son más bien limitaciones profesionales o la inmadurez de la profesión.

Estoy totalmente de acuerdo, no deja de ser el principio de Hanlon: “nunca atribuyas a la maldad lo que puede ser explicado por la estupidez”; pero lo que me interesa comunicar no es el motivo real por el que sucede todo esto, sino la imagen que se transmite. Un ejemplo clásico es la percepción de la técnica de modelización mediante Personas de Alan Cooper. Es tan habitual usarla mal que llega un momento que la sensación ya no es “este profesional, por ignorancia, usa mal la técnica”, sino “este profesional me está timando con algo que no sirve para nada”.

Y hasta aquí, la explicación del chiste.

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.