Individuos e interacciones por encima de procesos y herramientas

“Individuos e interacciones por encima de procesos y herramientas”, sí. Este es el primero de los cuatro puntos enumerados en el manifiesto agile.

Sin embargo, cuando hablamos de agile, y me incluyo, nos llenamos la boca justamente de los elementos de la derecha. Hablamos de procesos y herramientas; nos encanta describir liturgias, ceremonias, mostrar backlogs o entrar en el detalle de cómo usar kanban en scrum. En nuestro discurso los individuos no existen o se deshumanizan; dejan de ser personas al ser simplificados a roles. Hablamos de diseñadores y desarrolladores, de product managers y scrum masters.

En el pasado UX Spain, una de las pocas ponencias en las que no se mencionó agile fue justamente la que podría haber llevado por título este primer punto del manifiesto.

Ruymán Ferrera, amigo y excompañero de trabajo, no habló sobre cómo construir un equipo UX a base de procesos y herramientas. Habló de cómo construir equipos con su mínima unidad divisible: las personas. Habló de Sarah. De Elena. De tal y de cual. Pero no vistos como roles, sino como individuos, y con esta perspectiva explicó que lo único innegociable es:

  • Empatía
  • Curiosidad (no sólo en UX)
  • Ganas de aprender

Quiero detenerme en el segundo ítem. Y concretamente en esa aclaración entre paréntesis, que asume la curiosidad en el campo profesional pero expresa que no puede limitarse a un solo espectro: los intereses personales, las obsesiones de cada uno, deben ser diversos.

Creo firmemente (en el sentido literal de creer, ya que nada está en mis manos para demostrarlo), que la diversidad personal enriquece. Y esta diversidad personal, por extensión, genera diversidad en el equipo, enriqueciendo a sus miembros.

Así pues, no basta con juntar al diseñador con el programador. Debemos mezclar al que hace escalada los fines de semana con el que toca el bajo en un grupo los viernes por la noche. Al que hace raids en World of Warcraft con 40 amigos con el que cose amigurumis y los cuelga en Pinterest. Al que hace flaneur al salir del trabajo con el que escribe tutoriales de ARM para Raspberry Pi. Al que está en una liga de futbol amateur con el que nunca dice que no a una partida de un juego de mesa.

En una ponencia posterior, Susana Heredia dijo algo relacionado que me gustó:

“No es formar un equipo con distintos perfiles, sino con distintas personalidades”

https://twitter.com/Laux_es/status/606769533811101697

Vais a pasar muchas horas de vuestra vida trabajando con otras personas. Si podéis no perdáis el tiempo con gente que no sea interesante. No permitáis empobreceros en un entorno falto de curiosidad y diversidad. Para eso ya estamos los que trabajamos solos.

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.

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.

Ver el vestido de otro color

Hace casi un mes que medio mundo se volvió loco con un vestido que algunos veían blanco y dorado (al parecer la mayoría) y otros azul y negro.

Se trata obviamente de un efecto óptico (con un impacto importante de elementos contextuales a la propia observación), pero con una peculiaridad que a mí me parece especialmente interesante: para mucha gente es imposible cambiar su forma de ver los colores del vestido.

Dejad que lleve este tema al terreno de la usabilidad.

A veces en un test de usabilidad un participante tiene dificultades continuamente. Al parecer no entiende nada, todo son barreras para él. Y tú, como investigador, debes intentar averiguar dónde está el problema.

En esas ocasiones los árboles no te dejan ver el bosque: mientras observas al participante prestas atención a literales, estructura, componentes visuales… pero ninguno de estos elementos por sí solo puede ser capaz de generar tanta confusión.

Donald Norman hace unos años nos contaba esto:

The design model is the conceptualization that the designer has in mind. The user’s model is what the user develops to explain the operation of the system. Ideally, the user’s model and the design model are equivalent. However the user and designer communicate only through the system itself: its physical appearance, its operation, the way it responds, and the manuals and instructions that accompany it. Thus the system image is critical: the designer must ensure that everything about the product is consistent with and exemplifies the operation of the proper conceptual model.

Un usuario al aterrizar en un sistema acostumbra a tener ya un modelo parcialmente construido de cómo va a funcionar que puede no coincidir con el del diseñador. En estos casos, si la interfaz no proyecta una imagen del sistema claramente contradictoria con su prejuicio, entrará en juego su sesgo de confirmación, que le ayudará a incorporar todo lo que vea a su modelo mental.

El usuario acaba operando la interfaz con un modelo totalmente distinto al de diseño. Y claro, no entiende nada.

Como facilitador de un test debes ser capaz de hacer tres cosas ante esta situación.

Primero debes conseguir darte cuenta de lo que está sucediendo. Comprender que el problema es profundo y nada superficial.

Segundo debes averiguar con qué modelo mental trabaja el participante. Entender cómo él cree que funciona el sistema. Para ello es prácticamente indispensable utilizar el protocolo think aloud.

Y finalmente está lo más complicado: debes cambiar tu modelo mental por el del usuario y observar con sus ojos la interfaz. Debes ver el vestido de otro color.

¿Del SEO al UX?

Empecemos con franqueza: soy un neófito en SEO. Pero dejadme elucubrar sobre cómo funciona esto. Los buscadores, como Google, ganan dinero con publicidad. Y para ver su publicidad lógicamente debes usarlos. ¿Cuándo usarás un buscador? Pues cuando obtengas buenos resultados de búsqueda. ¿Qué es un buen resultado de búsqueda? Hasta hace poco era simplemente aquél cuyo contenido daba respuesta a tus preguntas. Por ejemplo, si me interesa una “receta de macarrones al pesto” un buen resultado es el que me describe cómo realizar esta receta.

Pero hoy en día hay cientos de webs con recetas de macarrones al pesto. Google, y otros buscadores, no pueden limitarse a valorar únicamente el contenido. Idealmente, ante dos sitios con idéntica información, Google debe ser capaz de posicionar mejor aquél que tenga un diseño más claro, el que ofrezca una interacción más usable, el que esté mejor adaptado al dispositivo que estás utilizando, etc. Dicho de otro modo: Google debe conseguir tener en cuenta la experiencia de usuario para posicionar sitios web.

Pero… ¿cómo los buscadores van a evaluar esto automáticamente? La realidad es que ya lo están haciendo. Google, por ejemplo, ya ha empezado a notificar a algunos propietarios con un mensaje clarísimo: “fix mobile usability issues” (podéis comprobar vuestro web en su prueba de optimización para móviles) y es de esperar que empiece a penalizar a aquellos sitios que hagan caso omiso del aviso.

Todo apunta a que en un futuro nada lejano los buscadores van a idear nuevos métodos de evaluación automáticos. Por ello, si el negocio de Google depende de conseguir dar más relevancia a los sitios web con una mejor UX, el negocio de un especialista en SEO debería ser, también, conseguir que el sitio web con el que trabaja ofrezca una buena experiencia.

Vamos, que SEO y UX no deben ser antagonistas: trabajar la UX de hoy también mejorará el posicionamiento de mañana.

Y de ahí que Arturo Marimón de SEOCOM me haya invitado a dar una pequeña charla con él en el ClinicSEO de Barcelona del 19 de febrero. Mi intención es ofreceros una introducción básica sobre cómo mejorar la usabilidad móvil de vuestros sitios web y, con ello, espero, el posicionamiento en años venideros. Nos vemos ahí.

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.