Internet. Tecnología. Personas. Desde el 2001.

ping@seisdeagosto.com

Los test con usuarios reales constituyen la pieza clave para definir interfaces con un enfoque humano adecuado.Conocer las distintas variables que entran en juego en el desarrollo de un test ayudará a identificar un mayor número de oportunidades de mejora, con un enfoque más lógico e intuitivo. Se trata, en definitiva, de diseñar interfaces al encuentro de las necesidades reales de los usuarios finales.

Concepto de tarea prescrita y tarea real
Aplicando conceptos generales basados en la Ergonomía, podemos distinguir tres variables que entran en juego a la hora de poner en marcha un test con usuarios reales:

1. Tarea prescrita (o escenario): ruta o camino definido dentro del interfaz que el usuario recorre para conseguir un determinado objetivo. Este escenario constituye la tarea propiamente dicha.

2. Diálogo que se genera entre el interfaz y el usuario para conseguir el objetivo pretendido.

3. Tarea real (o actividad) que el usuario realiza durante el test para alcanzar el objetivo final pretendido.

Diferencias tarea prescrita/tarea real
En Ergonomía, la diferencia existente entre tarea prescrita y tarea real – o actividad – constituye el elemento clave para identificar el coste humano. Este coste humano es denominado por distintos autores como «carga de trabajo» (Brito, 1991, Ferreira & Marcelin, 1983) y abarca distintos ámbitos: psíquico, cognitivo y, como no, físico.

Centrándonos en el ámbito cognitivo, la diferencia tarea prescrita/tarea real constituye un elemento clave para poder abordar un test de usuario de la forma más correcta. Teniendo en cuenta esta diferencia podremos obtener conclusiones más precisas y objetivas en nuestros test con usuarios:

– Si las pautas definidas en la tarea prescrita coinciden con la tarea real que desarrolla nuestro usuario durante el test podremos hablar de éxito en la realización de la tarea.

– Si las pautas definidas en la tarea prescrita no coinciden con las de la tarea real estaremos hablando de fracaso en la realización de dicha tarea.

– Finalmente, si las pautas definidas en la tarea prescrita no coinciden con las de la tarea real, pero el usuario finaliza con la creencia de haber finalizado la tarea prescrita con éxito, estaremos ante un caso de éxito relativo. El usuario cree que ha finalizado la tarea con éxito, pero en realidad no sucede así.

En cualquiera de los tres casos arriba mencionados, con especial énfasis en los dos últimos, conviene conocer qué ha llevado a los usuarios testados a fracasar o a estar en la creencia de haber alcanzado el éxito sin haberlo conseguido. Personalmente, creo que el fracaso relativo debe tener prioridad absoluta a la hora de abordar las oportunidades de mejora tras obtener las conclusiones de los test con usuarios.

La metáfora del reloj de arena
Como metáfora, para ayudar a comprender cómo se yuxtaponen las tres variables arriba mencionadas, he comparado el desarrollo de un test con usuarios con con un simple objeto real: un reloj de arena.

La comparación con un objeto real ayuda a reconocer las tres variables y saber en qué lugar se encuentra el papel del experto en usabilidad.

Si consideramos un reloj de arena, el globo que compone la parte superior del mismo, con la arena que contiene, constituiría la tarea prescrita.

El globo inferior, en el que se va depositando la arena que cae, constituiría la tarea real.

El cuello del reloj de arena, por donde pasa la arena del globo superior al inferior, equivaldría a la dinámica que se genera entre el interfaz, el usuario y el conjunto de variables que surgen en la consecución de la tarea prescrita, el contexto que rodea al individuo.

Es en esta parte central del reloj de arena donde el papel del experto en usabilidad toma una importancia aún mayor, donde se exige una atención especial para conocer qué provoca el éxito o el fracaso en la consecución del objetivo final prescrito.

Conclusiones
A pesar de que los tests con usuarios aportan resultados objetivos, el desarrollo de guiones y escenarios lleva implícito cierta dosis de subjetividad, puesto que se pueden elegir distintos caminos para alcanzar un mismo objetivo o también estar tentados a pasar por ciertas zonas de interfaz y no por otras que puedan ser más problemáticas.

Tener claras estas tres variables ayudará a definir test de usuarios más eficaces, con metas finales bien definidas, al encuentro de las «zonas problemáticas» bien identificadas dentro del interfaz que es objeto de testeo.

Actualizado
Cuántas veces nos habremos quedado mirando el humo blanco de un avión, imaginado hacia dónde va y de dónde viene. Casi al mismo tiempo, uno se para a pensar en la cantidad de aviones que pueden estar surcando el cielo de nuestro planeta en ése preciso momento.

La compañía Flightaware consigue saciar de alguna forma la curiosidad de muchos de nostros. En su web aloja un curioso vídeo en el que nos muestra los vuelos que entran y salen de los Estados Unidos en un solo día a través de diminutos puntos rojos que representan los aviones.

Es curioso observar el gran flujo que entra y sale por las costas este y oeste. También ver cómo disminuye el tráfico a partir de la media noche. El mundo es tan pequeño…

Actualización

Aaron Koblin, de Design Media Arts, tiene entre sus proyectos una serie de experimentos visuales que tienen mucho que ver con lo que aquí se habla. Genial el «The U.S. as seen by the FAA» (en Quicktime).

Para quien tenga más interés: The Celestial Mechanics website

Gracias Nacho 🙂

Dos enfoques distintos que producen dinámicas de trabajo diferentes a la hora de crear interfaces de usuario fáciles de usar.
La actividad del diseñador de interacción no sólo se limita a generar propuestas de interfaz. Revisar cómo se implementan los prototipos en la propuesta forma también parte del día a día de los que se dedican a crear procesos fáciles e intuitivos.

La revisión de prototipos implica realizar un seguimiento de los bocetos definidos y ver cómo se han implementado en la propuesta final que toque, maqueta, conjunto de PSD´s, etc.

No se trata tan solo de identificar posibles oportunidades de mejora en los flujos de navegación que se generan entre las diferentes pantallas, también hay que repasar la aplicación correcta de etiquetas, errores en el diseño, etc… Se trata, en definitiva, de comprobar que lo que se ha definido en el prototipo funciona y se aplica según lo previsto.

Esta tarea de revisión de prototipos es un diálogo que se genera, según sea el caso, entre dos perfiles:

Diálogo 1. Entre el diseñador de interacción y el diseñador gráfico. Este último, tras definir la capa de diseño entregará su propuesta al equipo de desarrollo.

Diálogo 2. Entre diseñador de interacción y uno o varios desarrolladores, cuando no existe un perfil de diseñador gráfico propiamente dicho.

La dinámica de las reuniones entre el diseñador de interacción y el que implementa el prototipo, ya sea diseñador gráfico o desarrollador, son muy diferentes dependiendo del perfil.

Diálogo 1. Diseñador de interacción con diseñador gráfico

Un diseñador gráfico atiende más al diseño visual, presta más atención a la organización de los módulos que componen una determinada propuesta gráfica: el código de color empleado, la tipografía, alineaciones, retículas, etc.

Elige una propuesta gráfica y aplica esa identidad visual a lo largo de todas las propuestas de interfaz definidas por el diseñador de interacción.

Al estar más centrados en aspectos visuales, los diseñadores gráficos suelen dejar de lado aspectos de navegación o comportamiento, y es aquí donde el diseñador de interacción tiene que prestar una mayor atención a la hora de identificar áreas de mejora:

Diálogo 2. Diseñador de interacción con desarrollador

Existen corporaciones donde el perfil de diseñador gráfico, o no se considera o por distintas razones, no se implica en un determinado proyecto. Las propuestas de interfaz en este caso, pasan del diseñador de interacción al equipo de desarrollo, que hace las veces de «desarrollador y diseñador gráfico amateur».

Cuando el que implementa la propuesta generada por el diseñador de interacción es un desarrollador, existen más posibilidades de que se dejen pasar detalles como alineaciones, colores, distancias entre elementos, etc… Pero, por el contrario, aspectos de navegación y comportamiento se aplican de forma sólida.
Conclusiones:

Los aspectos en los que el equipo de diseño de interacción debe intervenir con un diseñador gráfico son muy diferentes a aquellos que se tocan cuando se trabaja codo con codo con un desarrollador.

Con un desarrollador las áreas de mejora están más relacionadas con el diseño visual (estética). Lo contrario ocurre con el diseñador gráfico, que deja pasar de lado más detalles que tienen que ver con navegación o comportamiento de interfaz.

La opción de pasar un prototipo directamente a desarrollo parece, desde mi experiencia, ser la solución más interesante, ya que el primer objetivo es que la página funcione y se comporte correctamente y, más tarde, aplicar conceptos de diseño visual.

A nivel práctico creo que una formación en desarrollo complementada con conocimientos de interacción sería lo más razonable o con más posibilidades de funcionar. En una situación real es mucho más necesario y urgente que un sistema funcione de manera coherente y lógica, que su atractivo a nivel visual.

En algunos casos, cuando he visto el trabajo del diseñador gráfico sobre mi propuesta de prototipo realizada unas semanas atrás, he tenido dificultades en identificar que realmente era mi propio prototipo.

Trabajando con desarrolladores la experiencia ha sido diferente, no sólo veia claramente el prototipo desarrollado por debajo, sino que también identificaba más rápidamente qué cosas había que seguir mejorando para avanzar con la propuesta. El diseño se aplica de forma más rudimentaria pero lo que va apareciendo es más coherente.

Este artículo no pretende polemizar sobre qué formación o perfiles son más adecuados, ni quién es mejor. Tan sólo trato de plantear soluciones a un problema que seguramente muchos de nosotros, tenemos día a día.

Un cuarto de siglo ha pasado desde que se presentara el primer modelo de la gama Audi con tracción Quattro.

La marca alemana siempre se ha caracterizado por fabricar modelos sólidos, robustos, que no acusan el paso de los años a nivel de mecánica. Y, aún hoy, el modelo Quattro es uno los principales bastiones de la marca.

Pero no estamos aqui para hablar de coches. Hablemos de publicidad. Hace unos meses pudimos ver por televisión el lanzamiento del nuevo Audi A6. Lo que muchos de nosotros no sabíamos era que este anuncio se trataba de un remake que celebraba los 25 años de cuatro ruedas con traccción 4×4…

Allá por el año 86, el piloto de rallies Harald Demuth desafió las leyes de la gravedad conduciendo el flamante Audi 100 CS Quattro por una de las rampas de salto de ski más empinadas de por aquel entonces: la Pitkävuori Ski Jump en Kaipola, Finladia. Este anuncio se tornaría en el spot comercial de más éxito de la marca de los cuatro anillos. Toda una leyenda.

Para celebrar estos 25 años, se decidió romper el record establecido por Harald con la última versión del modelo Quattro.

El 24 de Enero del 2005, el ingeniero de Audi Uwe Bleck consigue aparcar el Audi A6 4.2 a 47 metros por encima del suelo también en Kaipola. Esta pista de ski superaba las características técnicas del spot de 1986: un ángulo de 37.5 grados, el equivalente a un 80% de gradiente… Casi nada.

A pesar del logro, estoy seguro de que muchos de nosotros se quedarían con el spot emitido 19 años atrás. Mucho más humano (se puede ver al piloto acariciar el vehículo), con ese inconfundible estilo de los años 80 – música incluída – y la aparentemente dureza de las condiciones atmosféricas, consigue transmitir mucho más que el remake realizado hace meses.

La versión del 2005 es mucho más fría, sin ése toque humano que siempre hace falta (no se ve ni un personaje en el spot) y acompañado por una banda sonora que, a mi modo de ver, no aporta emoción ninguna.

Sabemos que las comparaciones son odiosas, pero hay que verlas. La descarga es lenta, pero merece la pena:

Spot del 86´con Harald Demuth (WMV 1,74 MB)

Remake del 2005 con Uwe Bleck (WMV 2,61 MB)

… Nada que ver. Añorados años 80.

El Interactive Institute de Suecia ha desarrollado un juego en el que el concepto de jugar con una pelota no lleva implícitos los conceptos de adrenalina y acción.

Como su propio nombre indica, en Brainball el secreto del éxito está basado en la pasividad y la relajación mental del cerebro.

Las ondas generadas (concretamente las alpha y las theta, que se generan cuando estamos relajados) serán las encargadas de mover la pelota a lo largo del tablero.

Existe incluso una versión comercial que puede ser comprada: se llama Mindball

Tachi Laboratory es un departamento adjunto de la University of Tokio. En este laboratorio se desarrollan experimentos sobre Virtual Reality o la denominada Tele-Existence.

Durante el CHI2005 pudimos experimentar in situ una de sus más recientes creaciones, Gel Force, un novedoso interface que juega con las distribuciones de presión y dirección de la fuerza.

Hablando sobre Gel Force con uno de sus creadores, Kevin Vlack, un matemático americano que desarrolla su carrera de investigación en el país del sol naciente, conocimos de primera mano la ingente cantidad de componentes y parámetros que se entrecruzan en este fabuloso display.