Will Web For Food

A veces tengo la sensación de que las técnicas clásicas HCI se colocan un paso detrás de las necesidades de los proyectos.
Cualquiera que haya tenido una mínima experiencia en cualquier proyecto “normal” sabe que la gestión tiene mucho que ver en el éxito de los proyectos.
También puede haber notado que hay un punto en el cual la gestión y la definición del proyecto están tan próximos que es difícil distinguirlos.

Tenemos una serie de técnicas HCI para la fase de descubrimiento y exploración, cosas como el diseño de la investigación, las encuestas, los focus group o los test con usuarios.

Y por otro lado una serie de técnicas de design management, tales como procesos y métodos vinculados a la gestión que también entran en juego en ese instante.
La relación entre estos tres últimos conceptos: “técnica, proceso y método” es una discusión clásica.
No tengo intención de sentar cátedra y cerrar el debate, solo comparto mi aproximación.
El Método ayuda a definir con exactitud que es lo que el equipo de diseño tiene que hacer.  Las técnicas con las acciones mediante las cueles se definen los desafíos del proyecto, Las técnicas son brainstorming, prototyping, role playing, observación. Sobre las técnicas de gestión del diseño hay constantemente debate y  o adecuaciones de otros campos, con aportaciones como architectural programming. El proceso es la forma en la que ponemos en relación método y técnica. De este modo se habla de procesos interativos, procesos estandarizados e incluso el proceso puede ser el servicio de muchas empresas de consultoría y diseño.

Una forma de neutralizar toda esta situación y de paso lograr que las técnicas HCI y el design management se encuentren y potenciar la resolución creativa de problemas es emplear “juegos“.

Actualmente estoy trabajando entorno a este punto, y es interesante por que creo que pone en contexto los objetivos y las necesidades del proyecto. Tambien conceta disciplinas como el Service Design y el Design Research con el HCI.

Referencias:

• Innovation Games. Luke Hohmann.
• GameStorming. Dave Gray Sunni Brown & James Macanufo.

Por mi experiencia en reuniones de definición de proyecto y por el tipo de documentos que solemos generar en ese proceso, creo que podría ser interesante replantearnos la forma en la que afrontamos los “kickoff“.

El proceso y la documentación suelen resultar farragosos y asimétricos. Asimétrico por que la documentación suele ser concreta en la parte en la que debería ser abstracta, como por ejemplo cuando se definen los campos de formulario de un proceso. Mientras que es abstracta en lo que debería ser concreta, como por ejemplo como deberían ser los objetivos o indicadores a tener en cuenta en los procesos principales del producto.

Esta situación propicia que en algunos casos el proceso de diseño de producto se convierta en un intricado proceso de gestión de expectativas del equipo y el cliente.

Todo este proceso tienen algo que hace que me resulten lejanos a mi forma de trabajo de los últimos tiempos.

Pero no digo que la toma de requisitos sea una fase a evitar, de hecho tener unas pautas de que se espera del proyecto siempre es útil y necesario. Pero creo que no lo enfocamos del todo bien.

Una forma de resolverlo podría ser teniendo una entrevista con el cliente. Algo que sirva para aprender, para conocernos, para entendernos. No en torno a una mesa con un montón de gente de diferentes departamentos, sino una entrevista dialogada en la que entendemos las necesidades, los desafios, el ecosistema en el que vive el proyecto. Estableciendo una relación de dialogo.

¿Y si vamos un poco más allá?

¿Se podría monta como un híbrido de  entrevista y taller de co-creación?. En el que el cliente cuenta lo que necesita, que implica, como lograrlo, o mezclarlo con un focus-group. Detectar necesidades e inquietudes.

Un taller en el que se trabaja con el equipo del cliente sobre las dificultades o desafíos del proyecto.

¿Y si el documento de kickoff es un primer prototipo?. ¿O grabarlo y editar el video y que uno de los entregable sea un clip de video con todo el proceso?

Suena interesante. No sé si podría reducir tiempos del proyecto, pero desde luego haria más sencillas las cosas.

Si tienes un proyecto y crees que esto puede tener alguna utilidad avisame por favor, estaré encantado de jugar en tu equipo.

¿Qué son?

Test remotos de usabilidad o Remote Research (RR) es una forma de aplicar test usabilidad* con usuarios sin que el evaluador se encuentre físicamente en el mismo espacio que el participante.
Los test de usabilidad se pueden agrupar en dos grandes grupos en función de la localización del participante y evaluador.
Si el participante y el evaluador se encuentran en el mismo lugar, los test son presenciales o de laboratorio.

En cambio si el participante y el evaluador se encuentran en lugares diferentes son test  remotos o remote reseach.
Los RR pueden así mismo agruparse en distintas categorías**, por ejemplo en función de la participación del moderador podemos tener test moderados y test automatizados por una herramienta. Además, los moderados son de corte más cualitativo, mientras que los automatizados son más cuantitativos.

En función de la captación del participante y la forma de hacerlo podemos hablar de captación en vivo, mediante un layer, captación por perfil y mediante agencia de captación, contactos personales  o paneles de investigación.

E incluso en función de la tecnología empleada en las herramientas de captación remota podríamos agrupar en función de las que usan JavaScript y las que usan tecnologías Html.

Ventajas de RR vs Laboratorio

La ventaja principal entre los RR y lo test de laboratorio son los costes, entorno a un 42% más barato mediante RR. Este ahorro viene de reducir el tiempo de ejecución y el tiempo de captación de los participantes.
Además los RR poseen una mayor variedad en la procedencia de las muestras, ya que los RR son virtualmente aplicables a cualquier persona del mundo con una conexión.
Algunos caso de estudio otorgan unos valores de éxito mayores a los RR. Si se realiza el test en Laboratorio y en Remoto suelen detectarse entorno a 15 resistencias al uso con el RR que pasan desapercibidas en el laboratorio. Pero estas tasa de éxito no son valores concluyentes, así que no vincules tu elección a ello.

Inconvenientes de RR vs Laboratorio

Para mí el principal inconveniente está en la falta de especialización en las herramientas y en la técnica. Los RR aun no forman parte del arsenal metodológico de los profesionales, aunque muchas de estas herramientas son gratuitas.

Si estas interesado en potenciar tus conocimientos en RR y probar alguna herramienta consulta el fantástico el documento de Liz Bacon en referencias.

Referencias:

* Diga Test de Usabilidad, NO test de usuarios
** Otras categorías sobre las herramientas de investigación en Remote Usability

• Pros y contras del RR en Jhonny Holland
• Evaluación de herramientas. Usabilia VS Loop,   Quick and dirty, y el gdocs de Liz Bacon
• Alert box sobre RR
• Libro: Remote Research de El Presidente y Tony Tulathimutte y A practical guide to usability testing de Dumas y Residh.

La literatura sobre wireframing es muy limitada, y la mayoría de las referencias suelen ser blog, lo que atomiza este conocimiento, que ademas se suele adquirir mediante la experiencia.

En la mayoría de los casos estas referencias se suele centrar en el uso de un determinado software, más que en ciertos principios básicos de la técnica.

Se acepta dentro de las profesiones relacionadas con el diseño de productos digitales en mayor o menor medida que wireframe* y prototipo son sinónimos. De forma absoluta esto no es correcto. Wireframe toma su nombre de las estructuras alambicas que se emplean en el diseño industrial y mecánico. Mientras que el prototipo es una versión alfa de un producto que presenta múltiples finalidades, como es analizar costes antes de su producción, servir para testeó y evaluación o la captación comercial y financiación.

Cuando yo me tengo que enfrentar a un proyecto en el cual debo realizar wireframes sigo una serie de acciones que creo que me simplifican la vida.

Mis pasos durante el wireframing:

#1. Papel. Empezar realizando la composición del producto en papel. Esta idea supongo que no es nueva para nadie, pero creo que es bueno decirlo porque tengo la sensación de que hay prejuicios sobre hacerlo porque se percibe como una actividad no-seria el dedicar una mañana a dibujar interfaces.

¿Qué gano haciendo esto? En primer lugar tomar conciencia de los posibles enfoques y necesidades de la solución. Te permite tener en mente un foto a gran nivel de lo que quieres hacer. De esta forma es más sencillo que elijas la herramienta con la que vas a realizar el entregable y como hacerlo y que preveas el tiempo y esfuerzo que implica.

#2. Unifica las pantallas. Una vez que sabes lo que quieres hacer, una forma cómoda de trabajar es creándote componentes y re-utilizándolos a lo largo de todo el documento. Esta re-utilización puede ser creándote una página maestra o varias, en función de tus necesidades, o creándote galerías de componentes.

Por página maestra me refiero a un fondo de Visio, un lienzo de OmniGraffle o un master de Axure que puedas necesitar en múltiples paginas de tu documento.

Existen muchas galerías de componentes. Lo normal es que partas de alguna popular, la adaptes a tus necesidades y se acabe convirtiendo en tu galería.

¿Qué ganas haciendo esto? Al usar paginas maestras evitas que los elementos constantes te “bailen” en el PDF, que los cambios estructurales sean mucho más ágiles, por ejemplo cambiar un disclaimer en el pie en un documento de 40 páginas puede ser un poco pesado si hay que hacerlo 40 veces.

#3. Poner titulo al documento nada más empezar. Y configurar los settings de tu programa con auto-salvado cada 15 minutos. A veces una mañana de trabajo se pierde de forma accidental y resulta muy frustrarte.

¿Qué ganas haciendo esto? Paz mental, hay veces que tiraría el ordenador por la ventana, pero saber que en el peor de los casos pierdo 15 minutos me ayuda a mantener la calma. La contrapartida a la seguridad es la libertad, y se hace pesado en según que programa las pausas para que se salve, pero eso es un tema muy personal.

#4. Guárdate un día para que brille. Por definición un trabajo te lleva lo que crees que vas a tardar, más lo que no sabes que vas a tardar por lo que se pone un tiempo de margen. El diablo esta en los detalles y los detalles consumen mucho tiempo.

No se si estas tácticas son comunes, supongo que cada maestrillo tiene su librillo. Seguramente parte de esta situación se deba a la ausencia de una metodología proyectual. Espero que estos pasos sean de utilidad para alguien.

*Wireframe: A wireframe is a visual illustration of one Web page. It is meant to show all of the items that are included on a particular page, without defining the look and feel (or graphic design). It’s simply meant to illustrate the features, content and links that need to appear on a page so that your design team can mock up a visual interface and your programmers understand the page features and how they are supposed to work.

En usability.gov

Las investigaciones se diseñan.

En los proyectos no se suele hablar de esto por que se suele encontrar en un espacio aspiracional, pero el proceso de desarrollo del producto se optimiza si integramos  técnicas de investigación en el proceso.

Suele ser más o menos frecuente encontrarnos con proyectos en los que se van a llevar a cabo alguna o varias técnicas de diseño centrado en el usuario.

Lo que no suele ser tan frecuente, es que la finalidad de todos estos procesos de investigación estén planeados hacia un único fin. Dando la sensación que las técnicas por las técnicas mismas son lo importante del proceso, cuando la técnica es un elemento puramente táctico, mientras que el diseño del producto, y ahí se incluye la investigación, es la estrategia.

El proceso de desarrollo debe cubrir un amplio espectro, desde la idea al producto, o desde el concepto a la solución. Para lo cual, en la mayoría de proyectos nos vamos a encontrar con dos estados.

1. Descubrimiento, este estado es inicial, tengo una idea, un proyecto, pero no se como enfocarlo, necesito una aproximación a la realidad, necesito conocimiento. Este tipo de investigación se conoce como investigación primaria y suele ser de tipo flexible.
2. Confirmación, en este estado ya tenemos una opinión, pero no tenemos la certeza de que sea plenamente operativa. Deseamos contrastar nuestro enfoque con la realidad. A este tipo de investigación se la conoce como investigación secundaria o de contraste. (No confundir con investigación sobre fuentes secundarias).

Clicar sobre la imagen para ampliar.

Si desde el inicio del proceso tenemos en cuenta estos dos estados, los datos pueden ser acumulativos y pueden servir de brújula para la toma de decisiones de diseño.

En mi opinión esto debería estar presente tanto en la mentalidad de las empresas de consultoría, como en el cliente.

Referencias:

• Measuring Behaviour. An introduction guide. P. Martin y P. Bateson. Cambridge University.
• A Designer’s Research Manual. J Visocky O`Grady y K.  Visocky O`Grady. Rockport

Medir la usabilidad es un tema complejo. Habitualmente el concepto se emplea como un indicador, pero en la mayoría de los casos lo que realmente se hace es una valoración subjetiva. Alguna de las técnicas más populares emplean el mismo método, por ejemplo los análisis expertos y algunos modelos de check list de análisis heurístico se basan en puntuaciones subjetivas que dificultan poder  recrear el experimento y comparar los resultados.

Esto nos coloca en un lugar complejo, por un lado  necesitamos ponderar el grado de subjetividad del evaluador, para poder saber como de fiables son las comparaciones entre distintos estudios, realizados por distintos evaluadores. Y por otro nos limita para definir planes de mejora de la usabilidad  de un producto a lo largo del tiempo ya que no podemos estar seguros de la homogeneidad de los datos que comparamos.

Para  evitarte callejones sin salida lo mejor es dar unos pasos previos antes de medir.

“Usabilidad” hace referencia a una especie de constructor  de la cualidad de un producto*. Cuando deseamos medirla debemos comenzar por definir que es usabilidad. Esto puede suponer un problema por que no existe ninguna definición estándar aceptada plenamente por toda la industria, aunque de forma mayoritaria se suele aceptar la definición ISO 9241-11 en la que se identifica la usabilidad con tres dimensiones del producto: Eficiencia, Eficacia y Satisfacción.

¿Porqué debemos indicar una definición? A la hora de iniciar la evaluación de un producto debemos seleccionar e indicar cual es nuestra definición, por que es ahí donde vamos a indicar las métricas que vamos a emplear. Son estas métricas las que nos permite definir en nuestros proyectos como se van a llevar a cabo las auditorías y las evaluaciones. Parece una tontería, pero muchas veces esto se obvia. Optar por una u otra definición también condiciona como vamos a investigar. ISO 9241-11 esta vinculado a la realización de tareas por definición. Si usas esta definición tienes que evaluar tareas.
Para este post se ha decidido emplear como ejemplo la técnica de test con usuarios.

Muy bien, vamos a medir. Como hemos establecido 3 dimensiones, necesitamos definir como vamos a medir y que medir.

Primero veamos las dimensiones y que significan.

• Eficacia: Capacidad de lograr el efecto que se desea o se espera.**
• Eficiencia: Capacidad de disponer de alguien o de algo para conseguir un efecto determinado.**
• Satisfacción: Razón, acción o modo con que se sosiega y responde enteramente a una queja, sentimiento o razón contraria.**

Eficacia la podemos medir contabilizando las tareas que se logran  y las que no se logran (Tareas OK VS. Tareas KO) . Aquí nos va hacer falta definir que es lograr una tarea, podemos medirla contabilizando las dificultades que encuentra el usuario y el numero de “dificultades” que estimamos en los que un usuario abandonaría una tarea.

Eficiencia la podemos medir contabilizando el tiempo empleado en la consecución de la tarea. Para poder establecer ratios de tiempo, definimos un tiempo “experto” para la tarea que tomamos como referencia para la prueba.

Satisfacción se suele medir con un cuestionario post prueba, hay un montón de cuestionarios de satisfacción que te pueden servir de ejemplo.

El resto del proceso es el habitual. Identificamos las tareas que vamos a testar, identificamos a las unidades muestrales, hacemos la captación y realizamos las pruebas.
Después de esto procesamos los resultados, y presentamos el  informe.

Bola extra:
Cuando estamos analizando los datos, lo normal es crear una matriz de variables y estadísticos descriptivos. Y sobre esto analizar los datos. Puede ser útil hallar el coeficiente de correlación***, para establecer que relación hay entre las variables (cuando el tiempo de ejecución de una tarea es menor cuando las dificultades encontradas son menores, cuando esto ocurre el usuario puntúa como más satisfecho)

Bala de plata:
Es posible que necesitemos reducir nuestras variables a indicadores independientes para los datos  “Usabilidad” ya que se van a usar como kpi de negocio.
En ese caso se puede emplear análisis de componentes principales **** para reducir los factores  a variables para poder llevar a cabo acciones concretas sobre cada uno.

Referencias:

• * Disclaimer: Creo que tener un blog  sirve para estrujarse las meninges. Esta idea de constructo aun no esta refinada, y tiene ciertas connotaciones epistemológicas un poco paradójicas (ya …) como la posesión de una característica fuera del objeto. Aunque supongo que esto no le preocupa a nadie…
• ** Tomado de la RAE. http://www.rae.es/rae.html
• *** Para saber más del Coeficiente de correlación.
• **** Análisis de componentes principales (Pdf 448kb.)
• Sobre métodos, caro pero muy bueno.
• La biblia de los test. Un poco viejo, pero muy recomendable.