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.

10 libros sobre diseño y usabilidad

Quería hacer eso tan manido de recomendar algunos libros para el verano, pero es complicado elegir. Así que disculpad la pereza, pero me voy a limitar a enumerar los 10 primeros libros sobre diseño de interacción, interfaces y usabilidad que leí, en riguroso orden cronológico.

  1. Don’t Make Me think (3ª edición disponible)
    de Steve Krug
  2. The Design of Everyday Things (nueva edición disponible)
    de Donald Norman
  3. The Humane Interface
    de Jef Raskin
  4. Universal Principles of Design (2ª edición disponible)
    de William Lidwell, Kritina Holden y Jill Butler
  5. GUI Bloopers (2ª edición disponible)
    de Jeff Johnson
  6. The Elements of Graphic Design (2ª edición disponibile)
    de Alexander W. White
  7. Thinking with Type (2ª edición disponible)
    de Ellen Lupton
  8. Designing Visual Interfaces
    de Kevin Mullet y Darrell Sano
  9. About Face (4ª edición disponible)
    de Alan Cooper
  10. Designing for People
    de Henry Dreyfuss

10 libros sobre diseño y usabilidad

El mito del dedo gordo

Es más o menos conocido que al diseñar para pantallas táctiles debemos cuidar las dimensiones de los elementos interactivos. Deben superar cierto tamaño para que puedan ser pulsados minimizando el número de errores.

Pekka Parhi, entre otros, investigó empíricamente mediante tests de usabilidad esta cuestión y determinó unos tamaños mínimos aconsejables que teóricamente toda persona que diseñe para interfaces táctiles debería conocer.

A partir de 5mm de tamaño, 1 de 30 taps (un 3%) fallara. A partir de 7mm es 1 de cada 100 (1%).Lo que no es tan conocido es porqué sucede esto.

La explicación habitual es que “tenemos los dedos gordos”. Según esta teoría, si alguien intenta pulsar repetidamente en un mismo objetivo visual, el punto de contacto entre el dedo y la pantalla será siempre distinto, con una distancia grande entre pulsaciones. Como si disparáramos a una pared con un arma automática sin estabilizar y viéramos los agujeros de bala muy dispersos pese a estar apuntando siempre en el mismo sitio.

Sin embargo, empíricamente se puede observar que esto no es cierto. Si se pulsa repetidamente en un mismo sitio las pulsaciones se concentran en un área mucho más pequeña de lo que la teoría del dedo gordo nos podría hacer pensar. Es decir, sí somos precisos, entendiendo precisión como el hecho de que pulsamos siempre en el mismo sitio. El problema, en todo caso, es que el sitio en el que realmente pulsamos y el que percibimos o creemos estar pulsando pueden ser distintos. Volviendo a la metáfora del arma, es como si realmente los agujeros no estuvieran dispersos entre sí, pero sí puede ser que nunca toquemos al blanco.

Esto es observable en cualquier test de usabilidad: vemos participantes que no tienen ningún problema en pulsar en zonas mucho más pequeñas de lo recomendado, mientras que otros son incapaces de hacerlo aunque pulsen repetidamente. Y no, unos no tienen los dedos más gordos que los demás. Simplemente su pulsación tiene un offset o desvío fijo: visualmente creen estar pulsando en un sitio, pero pulsan siempre algo más abajo o más arriba.

Un dedo siempre pulsa fuera de su objetivo, pero todas las pulsaciones son muy cercanas

Christian Holz y Patrick Baudisch han propuesto el “Generalized Perceived Input Point Model” que explica estas observaciones con diversas variables, entre ellas el ángulo de contacto y el modelo mental de cada usuario, es decir, cómo entiende cada persona el hecho de “tocar”.

Los autores del modelo comentan que el problema, pues, es un caso de hardware no adaptándose al modelo mental del usuario y no tanto de una limitación inherente de nuestros mecanismos físicos para tocar.

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.

Minimalismo

Casey Neistat es un director de cine con un estudio peculiar, lleno de cachivaches, herramientas y todo tipo de material para realizar sus vídeos. La impresión inicial es que el estudio es caótico, saturado, aparentemente todo lo contrario a lo que llamaríamos “minimalista”…

Foto de un estudio con multitud de estanterías y objetos.…pero en realidad apenas hay decoración: todo está rigurosamente organizado de forma extremadamente simple, sirviendo cada elemento a un propósito concreto.

En el campo del diseño de interacción, y con el minimalismo por bandera, vemos cada día más interfaces absolutamente planas, sin apenas jerarquía visual; o sistemas de navegación que no muestran inicialmente ninguna opción y las ocultan en espera que el usuario sepa cómo mostrarlas. Y sí, con ello se consiguen interfaces limpias, blancas, aparentemente elegantes, ¿pero es esto minimalismo?

Un diseño es minimalista si utiliza lo mínimo: sólo los elementos imprescindibles de comunicación e interacción; evita el ruido, la decoración, pero no elimina la señal, los contenidos y las funciones.

Me parece más minimalista el superficialmente descuidado etiquetado con rotulador permanente de las cajas rojas de Casey Neistat que las infames y pulcras tres líneas horizontales paralelas de un menú hamburguesa.

Interfaces adaptativas

Hace casi ya 3 años, cuando Ethan Marcotte se sacó de la manga el “Responsive Web Design” tomó prestada la idea de otro sitio, de algo llamado “responsive architecture”.

Esta arquitectura “sensible” es un planteamiento basado en intentar romper la rigidez clásica de los edificios y otorgarles cierta capacidad de adaptación que les permita responder a necesidades inmediatas de sus usuarios y no únicamente a las necesidades genéricas, determinadas durante el proceso de diseño.

El palabro parece que fue inventado por Nicholas Negroponte, quien ya escribía sobre ello en los 70, intentando buscar una forma de humanizar la relación entre la gente y las construcciones. Un objetivo, la humanización, compartido con los diseñadores de interfaces, quienes justamente investigamos a los usuarios, sus tareas y sus cosas para obtener unos requisitos que serán la semilla de una interfaz.

Lo problemático es que nuestro proceso de investigación, como tantos otros, se nutre de muchas técnicas basadas en la categorización o la determinación de “acuerdos”. Un ejemplo son las personas de Cooper, con las que intentamos reducir la complejidad y disparidad de los usuarios a unos pocos perfiles; o los análisis de clustering de card-sorting, con los que determinamos el nivel de “acuerdo” existente sobre la estructura organizativa de ciertos conceptos.

Este proceso de investigación no deja de ser, y perdonad la expresión, un “café para todos”, que además cuenta con el agravante, digno de Capitán Obvio, de ser previo al propio uso de la interfaz.

¿Podríamos dotar a las interfaces de cierta capacidad para entender las necesidades particulares de los usuarios en un momento y lugar determinado? La respuesta es sí, y tampoco es nada novedoso, tenemos otro palabro para ello: “interfaces adaptativas”, cuya implementación se ha limitado tradicionalmente a preguntar al usuario en tiempo de ejecución “¿y tú quién eres?”

Un sitio web de una entidad financiera, con su típica dicotomía “Particulares” y “Empresas” podríamos considerarlo un ejemplo rudimentario de interfaz adaptativa. Otro, algo más “inteligente”, es el de una aplicación de salud que a partir del login del usuario ofrece opciones para médicos o enfermeros según corresponda. Pero yo creo que nuestra meta debería ser ir más allá, imitar esa arquitectura “sensible” en la que obviamente el usuario no se limita a elegir, sino que es el propio edificio quien se adapta y muta en función de las necesidades inmediatas.

Y no, no me estoy subiendo al carro de “eliminar la interfaz”, o al menos no de lo que yo entiendo por interfaz (que considero que pese a su etimología va mucho más allá de una mera superficie de contacto). Hablo de crear interfaces que, al estilo de la interfaz predictiva de Mathematica o Google Now de Android, tengan capacidad de anticipación para poder ofrecer al usuario información y acciones que tengan sentido en ese particular momento, en su contexto ambiental, social, organizativo y personal.

Wrong road

La localidad temporal es un fenómeno sistémico que no necesita presentación para quien conozca el concepto de “cache”. Para los demás, decir simplemente que es una forma de predecir el comportamiento de ciertos sistemas, concretamente el hecho que cuando se hace referencia a un recurso es probable que ese mismo recurso sea referenciado en un futuro.

Internet es un sistema en que este fenómeno es observable. Si accedes a una página de un sitio web es presumible que en un futuro próximo accedas a ella de nuevo. De hecho es muy probable que entre dos visitas a una misma página sólo hayas visto otra distinta; vamos, que estás en A, vas a B y vuelves a A. Y digo volver, como si A estuviera antes que B, pero no: A y B comparten la red de redes y ninguna está antes que la otra, pero para tu histórico personal de visitas A es anterior.

Así que visto esto, la gente del National Center for Supercomputing Applications de Illinois decide en 1993 que a su primer navegador gráfico le falta un botón importante. Uno con una flecha hacia la izquierda con el tooltip “Back”. Y de esta guisa nace el botón “atrás”.

Lo curioso es que ahora, 20 años más tarde, aún nadie entiende cómo funciona. Y lo cachondo es que importa tres cojones. Ya lo estudiaron Saul Greenberg y Andy Cockburn en 1999: dile a alguien que busque algo en un buscador y pulse en el primer resultado, después que vaya atrás y haga clic en el segundo resultado. ¿Si ahora pulsas “atrás” dos veces qué página sale? Venga. Rápido. Ok, sí, tú lo has respondido bien… pero muchos usuarios van a creer que vuelves al primer resultado; y no: el botón atrás no es un simple histórico de visitas, sino un sistema tipo pila donde hemos eliminado ya el primer resultado de ella. La cuestión es que para la mayoría de situaciones el modelo mental que se hace la gente del botón “atrás” es suficiente. Podríamos hacer una analogía con la geometría euclidiana: no importa que sea falsa o incorrecta o incompleta ya que se trata de una buena aproximación a nuestra realidad más inmediata.