Will Web For Food

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.

The beyond usability movement (Jordan and Servaes 1995; Blythe et al. 2003; Battarbee 2004) sees traditional usability as a performance-oriented approach which fails to take the broader issues that relate to human-product relationships into account. The problem is not that the definitions, guidelines and so on, outlined within usability do not match the new approach. Usability literature indeed provides extensive lists and hierarchies of important issues, including all the emotional, subjective, social or context dependent aspects that the beyond usability movement also considers important. For the new camp, the problem resides what not so much in the definitions (Blythe and Wright 2003: XVI) as what they see usability is in practice.
The basic old school usability is about seeking problems people have with particular products (Keinonen 1998). This is fine as long as we have products to test, but less useful when designing experience-rich interactions (Battarbee 2004: 8-9) or anticipating the use of some as yet non-existent product (Koskinen and Battarbee 2003).
Three key themes have emerged from the new school:

• Design for user experience. The key objective is to provide people with experiences created or mediated by products and services.
• User inspiration. Designers can be inspired about the doings or the users and material they produce.
• Empathic design. We need deeper understanding of the users. We need to know them as individuals.
• Hedonism. People seek pleasure through products.

In Co-experience. Understanding user experiences in social interaction.

Desambiguazión: Este post no habla de sitemap en XML para posicionamiento en buscadores.

Los Sitemaps son diagramas que representan los contenidos del site.
Vale, parece sencillo, este es nuestro Sitemap, un diagrama que dice aquí van “los servicios”, aquí “quieres somos”, aquí el “blog”…
Pero esta idea se complica cuando se incluye la variable “navegación”.  El Sitemap puede dar una idea de cómo se llega a un sitio, cual es la relación entre las distintas pantallas (¿páginas del site? ¿contenidos?). Pero la navegación se debe resolver en otro documento que se llama Task Flow. Llevar a cabo un Task Flow nos obliga a identificar objetivos de los usuarios (Investigación) y que diseñemos para lo probable y no para todo lo posible.
Volviendo a los Sitemap. Para iniciar el Sitemap hay que tomar una decisión. Y esa decisión responde a ¿Cómo se va a enfrentar el equipo al proyecto?.
Podemos elegir entre a un nivel muy alto de detalle, donde se van a modelar todas las pantallas y todas las interacciones y microinteraciones, vamos a llamar a esto Enfoque A.  O un enfoque modular, donde vamos a descomponer los componentes de las pantallas en módulos reutilizables. Vamos a llamar a este otro Enfoque B.

Estas consideraciones pueden influir mucho sobre como se va a desarrollar el proyecto, y se suelen dejar al gusto del “prototipador” que las puede tomar de una forma inconsciente. (Además de que no le compete a él tomar estas decisiones).

El enfoque A consume mucho más tiempo en prototipar, y se suele emplear en proyectos pequeños. Tiene como punto negativo que hace que lo importante se diluya entre la cantidad y genera la sensación de documentación al peso.

El enfoque B es mucho más participativo y esta más orientado a equipos de desarrollo,  se suele emplear en proyectos grandes donde hay varias personas implicadas en el diseño de los wireframes. Como punto negativo tiene un nivel de abstracción mucho más elevado que dificulta su consumo por el cliente, pero permite una ejecución mucho más ágil.

Algo tan asumible como en principio es un Sitemap puede determinar como se va desarrollar el proyecto.

Para leer más sobre Sitemap (y entregables)

• Information Architecture (2nd Ed.) de Rosenfeld and Morville.
• Communication design de Brown.
• A Project guide to UX design de Unger y Chandler.
• Modular web design de Curtis.

A la hora de plantear una investigación con usuarios nos podemos encontrar con que existen varias herramientas, o técnicas que tienen una finalidad similar, y que debemos elegir una.

Una de esas situaciones se da cuando debemos decidir si deseamos emplear  entrevistas o queremos usar focus group.

Ambas son técnicas exploratorias y su empleo nos permite conocer las necesidades o impresiones de los usuarios sobre un producto.

De forma breve, una entrevista es una conversación que se lleva  a cabo entre  un entrevistador, el investigador, y un entrevistado, el usuario. Su duración media esta entorno a una hora y su finalidad es recabar los puntos de vista del entrevistado sobre un tema concreto.

Un  focus group  básicamente es una conversación de un  grupo de usuarios, generalmente el numero de participantes suele estar entre 7 y 10 usuarios, a los que un moderador les plantea una cuestión en torno a la cual se desarrolla la conversación. La duración media suele ser 2 horas.

Esto es una forma simplista de presentar las técnicas para ilustrar este post.  Si deseas ampliar la información sobre la entrevista y sobre el focus group puedes seguir leyendo aquí.

En principio ambas técnicas parecen muy similares, y parece que no tenemos razones de peso para elegir una técnica frente a otra.

Uno de los aspectos que nos pueden ayudar a tomar una decisión es la eficacia de las técnicas a la hora de detectar necesidades de los usuarios.

Para responder esta pregunta necesitamos dados. Un articulo de de Griffin y Hauser en Marketing Science titulado The voice of the customer
mostró que un focus group de 8 usuarios  de dos horas de duración identificaba prácticamente el mismo numero de necesidades que dos entrevistas de una hora.

1 focus group de 8 personas = 1 entrevista de 1 persona + 1 entrevista de 1 persona.

En la mayoría de los casos la decisión sobre uso de una u otra técnica se toma en función del tiempo que cuesta aplicar la técnica, el coste económico que tiene, y las experiencias previas del equipo con una u otra técnica.

En nuestro caso, si al entrevistado le gratificamos con, por ejemplo, 50 euros por su colaboración de una hora y el coste en gratificaciones a los participantes de un focus group de 8 usuarios ronda los 400 euros, parece obvio que la técnica a emplear es la entrevista.

Con dos entrevistas hacemos un focus group, pero no cuestan lo mismo.

1 focus group de 8 personas  400 euros = 1entrevista  de 1 persona 50 + 1 entrevista de 1 persona 50.

Por el coste de un focus group podríamos hacer 10 entrevistas. Además de ahorrar la mitad del tiempo.

Pero la proporción de necesidades descubiertas no se mantiene constante. A partir de 7 entrevistas, según el estudio de Griffin y Hauser el numero de necesidades descubiertas son el 80%, mientras que con 7 focus groups se llega al 90%.

El 80% de las necesidades con entrevista = 7 entrevistas x 50 euros = 350 euros y 7 horas de trabajo de campo.

El 80% de las necesidades con focus group= 7 focus group de 8 usuarios =2.800 euros y 14 horas de trabajo de campo.

Siguiendo los datos del estudios de  Griffin y Hauser podemos decidir, que el focus group es aconsejable cuando nuestro proyecto requiere un nivel de certeza muy elevado, mientras que para la mayoría de los proyectos llevar a cabo de 3 (descubriremos 60%) a 7 entrevistas (descubriremos entorno al 80%) debería ser suficiente.

Bola extra

Un buen diseño de investigación con usuarios no se basará en una única técnica, ya que necesitamos contrastar los datos, lo más indicado es asociar técnicas, iniciando el proceso con un focus group que nos permita obtener una visión general y múltiples puntos de vista para a continuación entrevistar a  un par de usuarios tipo de cada uno de los perfiles que nos permita contrastar y profundizar esa información.

Referencias:

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

La revisión bibliografía es una técnica muy común en la mayoría de las investigaciones  de casi cualquier campo del saber, pero por el contrario tiene un uso escaso en HCI.

La finalidad de este post es presentar la técnica de revisión bibliografía, indicar sus ventajas y mostrar su aplicación.

La revisión bibliografía es el proceso por cual se considera la literatura existente sobre el tema que se va a investigar.

Esto podía parecer una forma rimbombante de llamar a los “googlazos”, pero el proceso es un poco más complejo. Veámoslo.

La revisión bibliografía permite que centremos nuestra investigación mediante la consideración de trabajos anteriores. Para ello, lo primero que debemos hacer es identificar los términos o “keywords”  que van a guiar nuestra investigación, estas palabras clave son las que nos permitan localizar  los trabajos previos.

Es importante identificar los trabajos previos publicados para poder focalizar, definir, contrastar o aprovechar la información obtenida, y por que así ayudas a que crezca el cuerpo teórico del HCI. Aunque no te des cuenta, cada pieza de información que aportas a tu proyecto, al equipo o a tu cliente, difunde conocimiento HCI.

Con nuestra lista de keywords realizamos búsquedas en las fuentes. Esto puede ser consultar manuales, búsquedas en bibliotecas o consultas en bases de datos.  Lo más normal es que las fuentes nos aporten nuevas keywords. Por eso tener una lista nos ayuda a mantenernos centrados en los objetivos de la investigación.

Una vez localizadas las referencias obtendremos un lista de referencias, esta lista se  la suele llamar  “lecturas preliminares” suelen considerarse de 20 a 50 referencias, ya, lío, no tengo tiempo para esto. La buena noticia es que las publicaciones científicas tienen un formato que incluye un resumen en pocas lineas.
Parece obvio, pero hay un orden de relevancia de las referencias, un  libro o un articulo en una revista especializada suele aportar más información que un post.

Ok, es posible que tengas más referencias de la que puedes manejar, por lo que una buena opción es ordenar la información en un  mapa conceptual.

Un mapa conceptual, es un diagrama del topic que estamos analizando, en el  que se indican las referencias ordenadas por keywords, junto con la referencia bibliografía (titulo, autor y año). Los mapas conceptuales no se suelen incluir en las publicaciones de las  investigaciones, pero creo que puede ser un buen anexo, ya que ayudan a contextualizar los datos y referencias.

Vale, muy bien, ¿pero todo esto para que me vale a mi? Principalmente para que no pierdas tu tiempo en algo que esta claro y es aceptado por toda la comunidad profesional, segundo, te ayuda a centrar tu investigación, identificando los “topics” de otros autores y  ayudándote a definir las variables de tu proyecto. Tercero, es una buena fuente de ideas para tu diseño de investigación. Si tienes que llevar a cabo investigaciones, la mejor forma de aprender es haciendo y viendo como otros lo han hecho.

Por ejemplo,  en nuestro proyecto estamos interesados en “el diseño centrado en el usuario”.

Lo primero que se nos pasa por la cabeza es buscar en internet, pero no encontramos una definición unitaria. Esto supone un problema. Por lo que decidimos revisar la bibliografía.

Comenzamos  definiendo nuestras keywords.  Como la literatura se encuentra en su mayoría en ingles usaremos este idioma.

Mi lista de keywords es esta:

User-centered desing, UCD, contextual inquiry, customer-focused design, ISO 13407, ISO 9241,  empathic design, participatory design, usability engineering, usability testing, user experience design, UXD, user-focused design, user-friendly design.

Con mis keywords consulto las  bases de datos, las publicaciones especializadas,  google sholar , o la biblioteca.

Mis referencias son:

• User-Centered System Design: New Perspectives on Human-Computer Interaction. D. Norman & Draper, 1986.
• Criteria for selecting methods in user-centred design . N. Bevan, 2009.
• User-Centered Design. C. Abras, D. Maloney-Krichmar, J. Preece. in  Encyclopedia of  Human-Computer Interaction. W. Bainbridge ,2004.
• Bluffer’s guide to ISO 9241. Davis Travis, 2009.
• Hedonic, emotional, and experiential perspectives on product quality. M. Hassenzahl in Encyclopedia of Human Computer Interaction. C. Ghaoui, 2006.
• Usability inspection methods  Jakob Nielsen In Conference on Human Factors in Computing Systems 1994.
• Spark Innovation Through Empathic Design. D. Leonard, J.F. Rayport. Harvard Business Review, 1997.

Y el mapa conceptual es:

Clicar sobre la imagen para ampliar.