Mostrando entradas con la etiqueta usabilidad metodología. Mostrar todas las entradas
Mostrando entradas con la etiqueta usabilidad metodología. Mostrar todas las entradas

jueves, 24 de enero de 2019

Reseña del libro "Lean UX. Cómo aplicar los principios Lean a la mejora de la experiencia de usuario"

Portada del libro Lean UX de Jeff Gothelf y Josh Seiden

Autor: Jeff Gothelf y Josh Seiden

Nº páginas: 164

Idioma: español (originalmente en inglés)

Formato: impreso y digital

Fecha de publicación: 2014 en español (2013 en inglés)

Web: Jeff Gothelf. Books

Podéis consultar más reseñas de libros en: "Libros y reseñas"

Lean UX es una metodología que se asienta en la colaboración multifuncional y en la gestión basada en los resultados. Supone un cambio de procesos, una nueva manera de pensar la gestión del software, centrada en las soluciones, en iterar una y otra vez perfeccionando el producto en cada nueva iteración. Es una metodología que permite dejar de hablar de funciones y documentos, para pasar a hablar de lo que funciona y lo que no funciona, y que nos permite armonizar un entorno de desarrollo ágil con el diseño UX.

Los autores se lo dedican a todos los diseñadores UX que siguen esperando la fase II, a la que relegaron parte de sus propuestas. El objetivo ahora es que las ideas más valiosas obtengan la mayoría de los recursos, mediante un método basado en la experimentación, la rápida iteración de ideas y el uso de procesos incrementales, donde el concepto de fase II ya no tiene cabida.

El libro está organizado en tres partes.

Parte I. Introducción y principios

Lean UX se asienta en tres pilares:

  • Design Thinking, enfoque centrado en las soluciones que, a través del trabajo colaborativo, itera una y otra vez perfeccionando el producto en cada iteración. Es una manera de trabajar que alienta la colaboración en el equipo y considera el producto desde una perspectiva holística y abarcadora.
  • Metodologías de desarrollo ágil de software, que tratan de entregar de forma rápida y regular software funcional a los clientes y aprovechar el aprendizaje que se obtiene de estas entregas para ajustar el proyecto. Aplican cuatro principios básicos:
    • Los individuos y las interacciones son más importantes que los procesos y las herramientas.
    • El software funcional es más importante que la documentación exhaustiva.
    • La colaboración con los clientes es más importante que la negociación de contratos con ellos.
    • La respuesta a los cambios es más importante que la planificación.
  • Método Lean Startup de Eric Ries que utiliza un ciclo de feedback denominado "crear-medir-aprender" y una filosofía que se aplica directamente al diseño de productos en Lean UX. Los principios que subyacen son:
    • cambiar documentos por artefactos de diseño;
    • colaboración funcional entre todos los implicados;
    • y un modelo basado en la experimentación.

Los principios en los que se basa Lean UX son:

  • Equipos multifuncionales para evitar el desarrollo en cascada.
  • Equipos pequeños, dedicados, coubicados, para fomentar la comunicación, concentración y camaradería; pero como no siempre es posible, a lo largo del libro se dan propuestas para trabajar con equipos localizados en diferentes lugares.
  • Progreso igual a resultados, no a entregas de documentación.
  • Equipos centrados en los problemas.
  • Eliminación del despilfarro, es decir, de todo aquello que no contribuye a conseguir el objetivo final.
  • Lotes pequeños, evitar crear muchas ideas de diseño sin probar ni implementar.
  • Descubrimiento continuo de lo que los usuarios están haciendo con nuestro producto y por qué lo están haciendo.
  • GOOB (Getting Out Of the Building), porque el éxito o el fracaso de nuestros productos no depende de las decisiones del equipo de desarrollo, sino de los usuarios.
  • Entendimiento común, es decir, el conocimiento colectivo del equipo sobre el producto y los usuarios.
  • Evitar las estrellas, gurús y ninjas que rompen la cohesión del grupo y reducen la colaboración.
  • Exteriorización del trabajo, es decir, exponer el trabajo a compañeros, colegas y clientes.
  • Hacer en lugar de analizar.
  • Aprendizaje en lugar de crecimiento: asegurarnos de que una idea funciona antes de hacerla crecer.
  • Permiso para equivocarse, porque los fallos conducen al perfeccionamiento (ver vídeo Why You Need to Fail, Derek Sivers, YouTube)
  • Escapar de los negocios basados en entregables.

Parte II. Proceso

¿Cómo conseguir un equipo que trabaja de forma colaborativa, iterativamente y en paralelo, que reduce al mínimo los entregables, y se centra en el software funcional y en el feedback del mercado?

Proceso Lean UX. Cuatro recuadros dispuestos en círculos unidos por flechas de doble dirección. En el sentido de las agujas del reloj: 1. Declarar suposiciones 2. Crear PMV 3. Poner en marcha un experimento 4.Feedback e investigación

Proceso Lean UX. Fuente: Lean UX, Jeff Gothelf, 2013

Visión, marco y resultados

En este capítulo explica cómo reorganizar el trabajo del equipo para que se centre en obtener resultados (no en desarrollar funciones), y en el proceso de declaración de resultados.

Se sustituyen los requerimientos por suposiciones, y a partir de ellas creamos y probamos hipótesis. La herramienta básica es por tanto la declaración de hipótesis, que tiene como elementos básicos: las suposiciones, las hipótesis, los resultados, los personajes y las funciones.

Comenzamos con la declaración del problema, después examinamos las suposiciones implícitas en él y las transformamos en hipótesis. Explica cómo escribir las declaraciones de hipótesis para que capten las funciones, la audiencia y los objetivos previstos, suficientemente específicos para poder probarlos; y proporciona ejemplos y plantillas.

Por ejemplo, la creación de Personas se realiza al revés de como posiblemente te han enseñado. En vez de dedicar mucho tiempo a un trabajo de campo para su creación, se crean unos protopersonajes en pocas horas, en una sesión de brainstorming en la que participa todo el equipo. Los protopersonajes son un modelo muy esquemático, y a medida que la investigación avanza y se aprende más sobre los usuarios, se va ajustando la definición de las Personas y nuestro diseño.

Una hipótesis a bajo nivel tendría un formato como este:

Creemos que [haciendo esto/desarrollando esta función/creando esta experiencia de usuario]
para [estas/os personas/personajes]
conseguiremos [este resultado].

Sabremos que esto es correcto cuando obtengamos
[este feedback del mercado, esta medida cuantitativa, o este conocimiento cualitativo]

Diseño colaborativo

Lean UX es un proceso colaborativo que reúne a todos los implicados en un trabajo de creación continua. El diseño colaborativo, dirigido por un diseñador de UX, permite a todo el equipo:

  • crear juntos los conceptos del producto,
  • construir un entendimiento común sobre el problema y las soluciones, con menos necesidades de documentar,
  • decidir qué funcionalidad y elementos de la interfaz implementan mejor las funciones recogidas en las hipótesis.

Lean UX promueve la conversación como método principal de comunicación entre los miembros del equipo.

La documentación de salida de las sesiones consta normalmente de esquemas de baja fidelidad y wireframes, no muy elaborados para que pueda cambiarse de dirección fácilmente.

Se dedica parte del capítulo a una técnica, el Estudio de Diseño, que es una sesión más formal de trabajo para conseguir que un equipo multifuncional visualice de forma conjunta las soluciones potenciales a un problema de diseño.

En resumen, se reparte una hoja dividida en seis cuadros y en cada uno se indica el personaje y el punto de conflicto que se desea resolver (de las suposiciones declaradas y las hipótesis que han generado). En 5 minutos cada uno genera 6 borradores de baja fidelidad para cada una de sus combinaciones de personaje-punto de conflicto. Después de ponerse en común, cada uno elige su mejor idea y desarrolla una versión de ella más elaborada. Finalmente, todos se ponen de acuerdo en una única idea, la que tiene más probabilidades de éxito y que servirá de base para el PMV.

El capítulo termina abordando una herramienta que se considera básica, la Guía de estilo, entendida como una biblioteca de patrones, un repositorio con los elementos de la interfaz aprobados y listos para funcionar. De este modo, no debatiremos sobre dónde poner, por ejemplo, la etiqueta de un campo de formulario, puesto que esto ya está definido de antemano. El trabajo se agiliza sin tener que volver a diseñar o prototipar estos elementos, nos centramos en la interacción y la extensión del sistema visual existente.

Si se trabaja desde cero, o en un producto simple, puede crearse la Guía de estilo completa antes de comenzar el proyecto, pero en proyectos complejos y actualizaciones de productos ya desarrollados, funciona mejor crearla a medida que el equipo crea o modifica un elemento de la interfaz.

En la Guía de estilo se incluyen:

  • todos los elementos gráficos de diseño: paleta de colores, tipografías...
  • los elementos de interacción: con su aspecto en todos sus estados, y con información sobre dónde se colocan en pantalla habitualmente y cuándo se utilizan;
  • el vocabulario: palabras que se utilizan en la interfaz, elecciones gramaticales, lenguaje en los botones...
  • incluso los fragmentos de código, para que los desarrolladores tengan una ventanilla única donde obtener las directrices de diseño y el código básico.

Puede elaborarse mediante una wiki o desarrollarse una guía dinámica, es decir, un repositorio de diseño y de código front-end que no solo define el aspecto y el comportamiento del producto, sino también el lenguaje necesario y las hojas de estilo para la interfaz, de tal manera que modificando la guía se modifica el producto.

La Guía debe estar accesible para todos los miembros de la organización, debe ser un elemento vivo que se mejora y actualiza, y debe ser aplicable para que no acabe convirtiéndose en un museo.

PMV y experimentos

El PMV (Minimun Viable Product) permite, partiendo de la hipótesis priorizada en la fase anterior, comprobar las suposiciones. Creamos los mínimos elementos posibles para probarla y saber si la hipótesis es cierta y hay que perfeccionarla, o si por el contrario hay que abandonarla.

En este contexto, hay que entender el PMV como el "producto" más pequeño que se puede crear para comprobar si una hipótesis es válida. El PMV puede adoptar muchas formas, a menudo un prototipo, y de hecho, repasa los diferentes tipos de prototipos, sus ventajas e inconvenientes, y cuál elegir en cada caso.

Pero no siempre es necesario crear un prototipo para averiguar algo, ni todos los PMV tienen que ser prototipos: puede ser el envío de un email, una landing, un botón para medir cuánta gente lo pulsa y estaría interesada, etc. Al final depende de nuestra hipótesis y lo que queremos averiguar (si resuelve un problema real, si hay suficiente demanda...)

Feedback e investigación

En la metodología es fundamental que el equipo consiga el feedback necesario que le sirva de guía en el proceso de diseño. Por ello, este capítulo se centra en qué técnicas usar para conseguir este feedback de forma continua y desde una etapa temprana, para incorporarlo a las siguientes iteraciones. Se trata de probar el PMV mediante técnicas de investigación ligeras, continuas y colaborativas.

La propuesta se basa en que la investigación la realice el propio equipo mediante descubrimiento colaborativo, con la ayuda de un especialista que ayude al equipo a planificar y ejecutar las actividades, para después dar sentido a los datos obtenidos y buscar patrones.

Por ejemplo, se propone la creación de equipos de perfiles mixtos para hacer entrevistas o enseñar el prototipo; la planificación semanal de test con 3 usuarios cada jueves; aprovechar el conocimiento del servicio de atención al cliente; diferentes formas de recoger feedback en la página; estudiar los registros de búsqueda y las estadísticas de acceso; realizar test A/B, etc.

Parte III. Cómo hacerlo funcionar

En esta última parte se aborda cómo integrar Lean UX en desarrollos ágiles, explicando cómo encajar las técnicas expuestas en un proceso Scrum típico y cómo hacerlas más efectivas, para pasar después a hablar de los cambios organizativos necesarios para apoyar esta manera de trabajar.

En 2007, Desirée Sy (Adapting Usability Investigations for Agile User-centered Design (PDF, 380 KB)) proponía integrar UX en desarrollos ágiles con la técnica "Ciclo 0" o "Sprint por etapas", en el que el diseño va un sprint por delante del desarrollo.

Ciclo 0 Planificar y recopilar datos de clientes, a partir de este, en cada ciclo siguiente, por ejemplo en el ciclo 2, los desarrolladores implementan el diseño del ciclo 1, y los diseñadores UX diseñan para el ciclo 2 y recopilan datos del cliente para el ciclo 3.

Fuente: Adapting Usability Investigations for Agile User-centered Design (PDF, 380 KB), Desirée Sy, 2007, Journal of Usability Studies.

Jeff Gothelf lo considera un modelo de transición, no una solución final a la que aspirar, porque acaba generando un proceso en cascada a pequeña escala, y para que Lean UX funcione, el equipo completo debe participar en todas las actividades.

El modelo que él propone se esquematiza de la siguiente manera.

El tema abarca varios sprint de 2 semanas. En cada tema hay reunión de planificación de la iteración (presente antes de cada sprint); generación de ideas y esquemas previos (antes de cada sprint, más antes del primero); y pruebas de usabilidad y valor (dos dentro de cada sprint)

Fuente: Lean UX, Jeff Gothelf, 2013.


Añado Lean UX a la biblioteca de reseñas, porque es ya un clásico y un libro de lectura obligatoria. Aporta muchas ideas que podemos llevar a la práctica, pero también es cierto que implantar la metodología hasta sus últimas consecuencias, con todos los cambios organizativos y culturales que hay que abordar, es difícil para muchas empresas y clientes, como reconoce el autor, y puede llegar a ser en algunos de ellos incluso una utopía.

miércoles, 11 de febrero de 2015

Reseña "The Design of Everyday Things" (2013) de Don Norman

Portada del libro The Design of Everyday Things 2013 de Don Norman

Autor: Don Norman

Nº páginas: 369

Idioma: inglés

Formato: libro impreso y versión digital

Fecha de publicación: 2013 (edición revisada y extendida)

Web: jnd.org> Books

Podéis consultar más reseñas de libros en: "Libros y reseñas"

Sobre el libro

Sigo reseñando clásicos, y un clásico entre los clásicos es sin duda "The Design of Everyday Things", que se publicó por primera vez en 1988 con el nombre de "The Psychology of Everyday Things". Se considera una lectura obligatoria porque describe y profundiza en los principios sobre los que se asienta el Diseño Centrado en el Usuario o la Experiencia de Usuario.

En 2013 Don Norman publicó una edición revisada y extendida del libro, que es la que reseño en este artículo. Los principios de la psicología humana siguen siendo los mismos que en 1988, lo que significa que los principios de diseño que se tratan en el libro, -basados en la psicología, en la naturaleza de la cognición humana, la emoción, la acción y la interacción con el mundo-, son los mismos. Sin embargo la tecnología ha cambiado mucho desde la primera edición del libro y los ejemplos se habían quedado obsoletos, por ello uno de los cambios de la nueva edición es la actualización de los ejemplos.

Pero además hay otras novedades importantes en la edición de 2013. Aunque el libro trata en realidad del Diseño Centrado en el Usuario, en la edición de 1988 no hace referencia explícita al mismo, como un proceso. Sin embargo en la edición revisada de 2013 dedica un capítulo completo a HCD (Human-Centered Design).

Tampoco hay referencias en la edición de 1988 a UX (Experiencia de Usuario), un término que no existía y que fue precisamente él uno de los primeros en utilizar años después. La primera edición del libro se centró en el diseño de productos comprensibles y usables, pero la experiencia total de un producto abarca mucho más que su usabilidad: la estética, el placer y la diversión juegan también un papel muy importante. De hecho en 2004 publicó un libro dedicado en exclusiva al "Diseño Emocional" ("Emotional Design: Why we love (or hate) everyday things"). En esta nueva edición se tratan también estas cuestiones.

Por último, cuando escribió el libro en 1988 era un académico; después ha trabajado para empresas como Apple o HP. En la edición de 2013 habla del modelo ideal pero también de lo diferente que puede ser el mundo real, con la presión de los presupuestos, los plazos y la competencia. Los mejores productos no son siempre garantía de éxito, porque para entender los productos no es suficiente entender el diseño o la tecnología, es fundamental entender el negocio.

Os recomiendo el curso de Don Norman "Introduction to the Design of Everyday Things”, que imparte en la plataforma Udacity y que precisamente está basado en el libro. El curso es gratuito y ya lo han hecho más 58.000 alumnos. Yo lo seguí el año pasado, y además de ameno, inspirador y muy práctico, es fantástico encontrar cientos de ejemplos compartidos por los alumnos.

A continuación resumo las claves del libro, que os recomiendo que leáis, pues el resumen no puede sustituir a la explicación detallada de todos los conceptos y los numerosos ejemplos que ofrece.

Objetivos del libro

El objetivo es convertir a los lectores en grandes observadores del absurdo, del mal diseño que da lugar a muchos de los problemas de la vida moderna, especialmente de la tecnología. También a convertirlos en observadores del buen diseño, de cómo los diseñadores reflexivos han trabajado para que nuestra vida sea más sencilla.

Un buen diseño es en realidad mucho más difícil de percibir que un mal diseño, porque el buen diseño se adapta a nuestras necesidades tan bien que se vuelve invisible, no llama la atención sobre sí mismo. Un mal diseño sin embargo se hace muy notable.

El libro nos guiará a través de los principios fundamentales que se requieren para:

  • crear o seleccionar productos usables y comprensibles, que proporcionan placer y satisfacción;
  • eliminar los problemas y buscar alternativas para aquellos productos que no cumplen estos requisitos.

1. The Psychopathology of Everyday Things

Un buen diseño (en todo el libro, diseño en el sentido amplio, no en el sentido de diseño gráfico) debe tener dos características: "discoverability" y "understanding", que nos permiten descubrir lo que hace un objeto o producto, cómo funciona, qué operaciones son posibles, dónde y cómo deben hacerse.

Para ello hay que comprender seis conceptos básicos que desgrana en este y otros capítulos:

  • Affordances. Todas las posibilidades de acción de un objeto que son inmediatamente percibidas por el usuario. No es una cualidad del objeto, es una relación determinada conjuntamente por las cualidades del objeto y las capacidades del usuario, que se nutre de experiencias pasadas, estimaciones comparando otro tipo de vivencias, etc.
  • Signifiers. Comunican dónde debe llevarse a cabo la acción, son señales o etiquetas, muy importantes porque comunican cómo usar el diseño, y que por tanto deben ser perceptibles.
  • Constraints. Las restricciones, las limitaciones del diseño (físicas, lógicas, semánticas y culturales), son indicios poderosos porque reducen el conjunto de posibles acciones, guían el uso y facilitan la interpretación.
  • Mappings. Trata de la relación entre los elementos de dos o más conjuntos. Cuando hay correspondencia espacial entre la disposición de los controles y los dispositivos controlados, así como contigüidad temporal, es más fácil determinar cómo usarlos.
  • Feedback. Es la comunicación completa y continua de los resultados de una acción y del estado actual del sistema. Debe ser suficientemente informativa y diferenciar la información importante de la que no lo es: ofrecer poca información o demasiada puede ser más molesto que no ofrecer ninguna.
  • “The conceptual model of the system", una explicación muy simplificada de cómo funciona algo. No hay que confundirlo con el "modelo mental" que es el modelo conceptual en la mente de las personas, que representa su comprensión de cómo funciona algo;o con la "imagen del sistema", que es lo que se puede derivar del mismo y de su documentación.

    El modelo mental de una persona se crea a través de la interacción con el producto y la imagen del sistema; lo creamos a partir de la experiencia y la formación, a partir de lo que el dispositivo parece y a partir de otras cosas similares que usamos en el pasado, en base a los anuncios, a lo que hemos leído en el manual, etc.

    Los diseñadores esperan que el modelo del usuario sea idéntico al suyo, pero la carga de la comunicación es con la imagen del sistema. Cuando la imagen del sistema es incoherente, inadecuada, incompleta o contradictoria habrá problemas.

    Un buen modelo conceptual permite predecir los efectos de nuestras acciones y nos da una sensación de control. Sin un buen modelo, operamos de memoria, a ciegas; hacemos operaciones que nos dijeron que hiciéramos; no comprendemos por qué, qué efectos esperar, o qué hacer si las cosas van mal.

Los productos y sus diseñadores deben entender a las personas, no se puede culpar a las personas de:

  • no usar los productos como desearían sus diseñadores;
  • no entender las reglas, a menudo arbitrarias y sin sentido, que dictan los productos para su uso;
  • no haber leído las instrucciones a veces más complejas que el propio producto;
  • cometer errores, porque los humanos cometemos errores.

2. The Psychology of Everyday Actions

Diferencia entre:

  • Procesamiento inconsciente. Es rápido y automático, reconoce la relación entre lo que estamos experimentando y lo que vivimos en el pasado.
  • Procesamiento consciente. Es lento y trabajoso, ponderamos decisiones, pensamos a través de alternativas, comparamos diferentes opciones.

Por otra parte, el pensamiento no puede separarse de la emoción. Los pensamientos conducen a emociones, y las emociones conducen a pensamientos. El cerebro está estructurado para actuar sobre el mundo, y cada acción lleva consigo expectativas, y estas expectativas conducen a emociones.

Distingue tres niveles de procesamiento dentro del cerebro, diferentes, pero trabajando en concierto, por ello el diseño debe realizarse en los tres niveles:

  • “visceral level”, es el nivel más básico y nos permite responder con rapidez y de forma inconsciente, sin conocimiento o control consciente.

    La respuesta visceral es acerca de la percepción inmediata y los grandes diseñadores utilizan la estética para producir respuestas viscerales, porque en este nivel algo nos atrae o nos repulsa, y esto no tiene que ver con lo usable, eficaz o comprensible que es el producto.

  • “behavioral level”, es el hogar de las habilidades aprendidas. Las acciones y el análisis a este nivel son en gran parte subconscientes. Cuando realizamos una acción bien aprendida, lo único que tenemos que hacer es pensar en la meta y el nivel de “behavioral level” se encarga de todos los detalles.

    En este nivel cada acción se asocia con una expectativa. Un resultado positivo tendrá una respuesta afectiva positiva; y uno negativo una respuesta afectiva negativa. Tenemos sensación de control cuando existe una buena comprensión y conocimiento de los resultados, y una sensación de falta de control y de frustración cuando las cosas no salen según lo planeado, y especialmente cuando no se conoce la razón ni las posibles soluciones. De ahí la importancia del “feedback”, que nos da tranquilidad.

  • “reflective level”: es el hogar de la cognición consciente y por tanto es más lento. Aquí es donde se desarrolla una comprensión profunda, donde tiene lugar el razonamiento y la toma de decisiones conscientes. Si los anteriores niveles eran el hogar de las emociones básicas, aquí reside el nivel más alto de las emociones.

Por otra parte diferencia en cada acción humana siete etapas, que pasa a identificar con cada uno de estos niveles de procesamiento. Además podemos asociar a cada etapa una pregunta que nos proporciona una lista de comprobación básica:

  • Metas: ¿Qué quiero lograr?
  • Ejecución, aquí tratamos de averiguar cómo funciona el objeto o producto. Entran en juego los “signifiers”, los “constraints”, los “mappings”, y el modelo conceptual.
    • Plan (reflective): ¿cuáles son las alternativas?
    • Specify (behavioral): ¿qué puedo hacer?
    • Perform (visceral): ¿cómo puedo hacerlo?
  • Evaluación, cuando fallan las cosas, aquí trataremos de averiguar lo que pasó, y qué otras cosas podemos hacer. Entran en juego el “feedback” y el modelo conceptual.
    • Compare (reflective): ¿he logrado mi meta?
    • Interpret (behavioral): ¿qué significa?
    • Perceive (visceral): ¿qué ha ocurrido?

No culpes a la gente cuando no pueden utilizar tus productos correctamente, eso es señal de que el producto puede ser mejorado: proporciona ayuda y orientación; informa correctamente de los errores y la solución para que los usuarios continúen con su tarea, no les hagas empezar de nuevo.

3. Knowledge In the Head and In the World

En este capítulo trata de la diferencia de que los conocimientos para realizar una tarea estén:

  • “in the world”, y por tanto la necesidad de aprender disminuye
  • “in the head”, y por tanto debemos aprenderlos y hacer uso de la memoria

Al hablar de la memoria tenemos que diferenciar:

  • La memoria a corto plazo. La información se retiene automáticamente; es recuperada sin esfuerzo; es muy frágil: si te distraes la olvidas; y la cantidad de información que puede ser retenida de esta manera es muy limitada. Se ve afectada por el tiempo (como los mensajes que aparecen poco rato en pantalla y desaparecen), el número de ítems y la familiaridad del material.

    El límite tradicional que se suele indicar es de cinco a siete elementos (recomienda reducirlo de tres a cinco elementos); de diez a doce si el material se repite continuamente (“rehearsing”).

  • La memoria a largo plazo. Es la memoria del pasado y cuesta más tiempo y esfuerzo recuperarla. Además se reconstruye y se interpreta cada vez que la recuperamos, y por eso está sujeta a sesgos y distorsiones.

    La facilidad para recuperar experiencias y conocimientos de la memoria a largo plazo depende de cómo interpretamos el material en primer lugar. Lo que se almacena bajo una misma interpretación probablemente no se puede encontrar más adelante cuando es buscado bajo alguna otra interpretación.

    Cuando lo que se está aprendiendo parece arbitrario, sin relación entre sí ni una estructura subyacente, es más difícil de aprender, lleva más tiempo y esfuerzo; además, cuando surge un problema no tienes pistas sobre lo que ha ido mal o cómo solucionar el problema. Parte de la potencia de un buen modelo conceptual reside en su capacidad de dar sentido a las cosas.

Recuerda que el pensamiento consciente requiere tiempo y recursos mentales. Pero las habilidades aprendidas, la práctica continuada, automatiza la acción, no necesita del control consciente, salvo para el aprendizaje inicial y para hacer frente a situaciones inesperadas.

Ofrece estructuras significativas; añade limitaciones apropiadas para obligar a determinadas acciones (“constraints” ); ofrece un buen “feedback”, “affordances” y “signifiers”. Un “mapping” correcto reduce la carga de memoria, aunque hay que tener en cuenta que un correcto “mapping” puede depender de la cultura. La elección de la metáfora dicta el diseño adecuado para la interacción.

Intenta conseguir, siempre que se pueda, que recordar sea innecesario.

4. Knowing What to Do: Constraints, Discoverability, and Feedback

¿Cómo determinamos cómo operar con algo que nunca hemos visto antes? No tenemos más remedio que combinar el conocimiento “in the world” con el conocimiento “in the head”. Se puede consultar una tabla comparativa entre ambos en la página 110.

En este capítulo se centra en el conocimiento “in the world”, y comienza con los “constraints”, las restricciones que limitan el conjunto de posibles acciones, que pueden ser físicas, culturales, semánticas o lógicas. Pueden consistir en:

  • forzar funciones
  • forzar a que una operación se haga en la secuencia correcta
  • mantener una operación activa, evitando que alguien la detenga antes de tiempo sin haber realizado las operaciones deseadas
  • impedir, por seguridad, que un evento ocurra

También trata el tema de las convenciones, que son un tipo de restricción cultural. Las convenciones proporcionan una valiosa orientación en las situaciones nuevas, y las convenciones generalmente aceptadas son difíciles de cambiar, aunque la alternativa propuesta sea mejor. La gente se opone a los cambios porque requieren un nuevo aprendizaje.

Si una nueva forma de hacer las cosas es solo ligeramente mejor que la anterior, es mejor ser consistente con las convenciones actuales. Solo cuando una nueva forma de hacer las cosas es muy superior a otra, los beneficios del cambio son mayores que la dificultad del cambio.

5. Human Error? No, Bad Design

Si el sistema le ha permitido al usuario cometer un error, está mal diseñado. Si el sistema induce a error, entonces está realmente mal diseñado. ¿Por qué se equivoca la gente? Debido a que los diseños se centran en los requisitos del sistema y las máquinas, y no en las personas.

Distingue dos tipos de errores:

  • “slip”, ocurre cuando una persona tiene la intención de hacer una acción y termina haciendo otra. Distinguimos:
    • “capture slips” en vez de hacer la acción deseada haces otra más frecuente, o que has hecho hace poco, porque tienen partes idénticas y una es más familiar que la otra. Los diseñadores deben evitar los procedimientos que tienen unos pasos idénticos, pero luego divergen. Siempre que sea posible, deben ser diseñados para ser diferentes desde el principio.
    • “description-similarity slips”: se actúa sobre un elemento similar al de destino. Los diseñadores necesitan asegurar que los controles y pantallas para diferentes propósitos son significativamente diferentes unas de otras.
    • “mode errors” ocurre cuando un dispositivo tiene diferentes estados (“modos”) en los que los mismos controles tienen diferentes significados (como un reloj con múltiples funciones). Los errores de modo son inevitables en cualquier cosa que tenga más posibles acciones que controles o indicadores; lo que suele ocurrir cuando agregamos más y más funciones a los dispositivos.
    • memoria-lapse, la memoria falla, por lo que la acción no se realiza (o no se hacen todos los pasos) o sus resultados no se evalúan. La causa inmediata suelen ser las interrupciones o los muchos pasos necesarios entre el inicio y el final de las operaciones que sobrecargan la capacidad de la memoria a corto plazo. Por ello, minimiza el número de pasos y ofrece feedback.
  • “mistakes”, se producen cuando se establece la meta equivocada o se forma un mal plan. A partir de ese momento, incluso si se ejecutan las acciones adecuadamente, estas son inapropiadas porque forman parte de un plan equivocado. Muchos errores surgen porque la gente tiende a confiar en las experiencias recordadas más que en un análisis más sistemático. Tomamos decisiones basadas en la memoria, que está sujeta a sesgos.

    Existen tres modos de comportamiento:

    • Skill-based behavior. Cuando los trabajadores son extremadamente expertos en su trabajo, hacen las tareas rutinarias con poco o ningún pensamiento o atención consciente. Normalmente aquí se producirán “slips”.
    • Rule-based behavior. Si se selecciona la regla equivocada (porque se interpreta mal la situación, el resultado se evalúa incorrectamente, etc.) es un error, que puede llevar a más problemas a medida que continua el ciclo de acción; si se produce un error en la ejecución de la regla normalmente es un “slip”. Se debe proporcionar la mayor orientación posible para asegurar que el estado actual de las cosas se muestra de forma coherente y fácilmente interpretable.
    • Knowledge-based procedures. Cuando ocurren eventos no familiares, donde no se pueden aplicar las habilidades ni las normas existentes, si se diagnostica mal la situación el esfuerzo se dirigirá a resolver el problema equivocado y estaremos ante un error. En este caso lo esencial es un modelo conceptual apropiado para guiar el desarrollo del plan y la interpretación de la situación.

    Y por último también tenemos memory-lapse mistakes cuando el lapso de memoria lleva a olvidar la meta o plan de acción, debido muchas veces a las interrupciones. Por eso hay que asegurar que toda la información relevante está continuamente disponible.

En resumen, los “slips” son el resultado de acciones subconscientes, y les ocurren más a los usuarios expertos, muchas veces por falta de atención pues hacen las tareas de forma mucho más automática que los novatos; y los “mistakes” son el resultado de deliberaciones conscientes.

Los “mistakes” se presentan a menudo por la información ambigua o poco clara sobre el estado actual de un sistema, la falta de un buen modelo conceptual o un feedback de baja calidad sobre lo que ha sucedido en realidad. Una fuente importante de errores, especialmente de lapsos de memoria, son las interrupciones o distracciones. La mayoría de los sistemas hacen que sea difícil reanudar la tarea después de una interrupción, pues no ofrecen información crítica que necesita el usuario para recordar las numerosas pequeñas decisiones que había tomado.

Es relativamente fácil diseñar para la situación en la que todo va bien, donde la gente utiliza el dispositivo de la manera que se pretendía y no se producen acontecimientos imprevistos. La parte difícil es diseñar para cuando las cosas van mal.

Estos son algunos de los consejos para evitar errores:

  • Añadir restricciones (“constraints”). Por ejemplo, si un control no es relevante para la tarea actual, no está visible en pantalla.
  • Ofrecer la opción de “Deshacer”.
  • Pedir confirmación y ofrecer mensajes de error.
  • “Sensibility checks”. Los sistemas menos inteligentes siguen ciegamente mis órdenes, los inteligentes se dan cuenta, por ejemplo, de que estoy ordenando una transacción de una cantidad enorme, mucho mayor que otras habituales, y me avisan.
  • Minimizar los “slips”. La solución no es que es usuario tenga que prestar siempre mucha atención consciente, porque el comportamiento especializado es subconsciente, y por tanto rápido, sin esfuerzo, y por lo general preciso. Se minimizan diferenciando claramente los diferentes procedimientos (que no tengan pasos similares) y controles. Ofreciendo retroalimentación perceptible, junto a mecanismos que permiten deshacer el error, y evitando las interrupciones.
  • Ponga los conocimientos necesarios para operar la tecnología “in the world”. No obligues a que todo el conocimiento esté en la cabeza, esto ayuda especialmente a los no expertos. Pero también a los expertos cuando necesitan llevar a cabo un operación poco frecuente. Haz las cosas visibles, proporciona información, que sea posible saber qué se puede hacer y poder determinar el estado del sistema fácilmente y con precisión.

6. Design Thinking

Normalmente, el problema que nos preguntan no es en realidad el problema raíz, solo un síntoma. Una solución brillante para el problema equivocado puede ser peor que ninguna solución. Los buenos diseñadores nunca empiezan por tratar de resolver el problema que les dicen, comienzan por tratar de entender cuáles son los verdaderos problemas, en un proceso iterativo, antes de proponer una solución, no sin antes considerar una amplia gama de soluciones.

Este proceso se llama “design thinking” y utiliza dos herramientas: Human-centered Design (HCD) y “The double-diamond diverge-converge model of design”.

HCD (Human-centered Design) es el proceso que garantiza que las necesidades de las personas se cumplan, que el producto resultante sea comprensible y utilizable, que lleve a cabo las tareas deseadas, y que la experiencia de uso sea positiva y satisfactoria. Por tanto nos garantiza resolver los problemas y hacerlo de una manera acorde con las necesidades y capacidades humanas.

El principio fundamental es resolver el problema correcto. Y tiene dos grandes fases: encontrar el problema (“discover” and “define”) y encontrar la solución ("develop” and “deliver”) es lo que el Design Council (UK) describió en 2005 como el "double-diamond design process model".

En Human-centered Design (HCD) se distinguen cuatro fases diferentes e iterativas.

1. Observation

El investigador estudia a los potenciales clientes y a las personas que van a utilizar el producto, observa sus actividades, intenta entender sus verdaderos intereses, motivaciones y necesidades. La definición del problema para el diseño de productos provendrá de esta profunda comprensión de las metas que la gente está tratando de lograr y los impedimentos que experimentan.

Una de sus técnicas es observar al público objetivo en su entorno, donde van a utilizar el producto o servicio en la realidad. Esta técnica se llama etnografía aplicada, un método adaptado del campo de la antropología, pero diferente, porque los objetivos son diferentes.

Dedica un apartado a la diferencia entre la investigación de diseño y la investigación de marketing. El diseño y el marketing son dos campos complementarios, pero cada uno tiene un enfoque diferente. El diseño quiere saber lo que la gente realmente necesita y cómo utiliza realmente el producto o servicio. El marketing quiere saber lo que la gente va a compra, que incluye el conocimiento de cómo toman sus decisiones de compra.

Estos diferentes objetivos conducen a diferentes métodos de investigación:

  • Los diseñadores tienden a utilizar métodos de observación cualitativos, mediante los cuales pueden estudiar en profundidad a las personas, entender cómo hacen sus actividades y los factores de su entorno que entran en juego. Normalmente solo examinan un pequeño número de personas.
  • El marketing se ocupa de los clientes. ¿Quién podría comprar el artículo? ¿Qué factores podrían atraerle para considerar la compra de un producto? Se utilizan para ello estudios cuantitativos a gran escala, focus group, encuestas y cuestionarios. O por ejemplo se ha generalizado en los sitios web el uso de test A/B.

Los diferentes métodos tienen objetivos diferentes y producen resultados diferentes.

Los diseñadores se quejan de que los métodos utilizados por el marketing no reflejan el comportamiento real, no dicen nada de las necesidades reales de la gente, de sus deseos y de las razones de sus actividades. Que dan una visión superficial de un gran número de personas.

La gente de marketing se queja de que, a pesar de los que métodos de investigación de diseño dan una visión profunda, el número de personas que se observa es muy pequeño.

El debate no es útil. Necesitamos ambos. Los diseñadores entienden lo que la gente realmente necesita. El marketing entiende lo que las personas quieren comprar. No es lo mismo, son dos enfoques, y por ello deben trabajar juntos en equipo.

2. Idea generation (ideation)

Una vez que se determinan los requisitos de diseño, el siguiente paso para un equipo de diseño es generar soluciones potenciales. Este proceso se llama generación de la idea o “ideation”.

Hay muchos métodos y muchos de ellos caen bajo el título de "lluvia de ideas." Cualquiera que sea el método utilizado, hay varias reglas:

  • Generar muchas ideas. Es peligroso obsesionarse con una o dos ideas demasiado pronto en el proceso.
  • Ser creativo sin tener en cuenta las limitaciones. Evita criticar las ideas o desecharlas demasiado pronto, incluso las más locas, pueden contener ideas creativas que más tarde se pueden extraer y adaptar a la idea final seleccionada.
  • Pregúntalo todo, incluso si la pregunta parece "estúpida".

3. Prototyping

La única manera de saber realmente si una idea es razonable es probarla. Construye un prototipo o maqueta rápida para cada posible solución, por ejemplo a lapiz. A veces las ideas se transmiten mejor por bocetos, sobre todo si están desarrollando servicios de difícil prototipado. Pone como ejemplo la técnica de “Wizard of Oz”.

Los prototipos durante la fase de especificación del problema se hacen principalmente para asegurar que el problema se entiende bien. Durante la fase de solución del problema de diseño se realizan prototipos para comunicar la solución propuesta.

4. Testing

Se testea el prototipo con el público objetivo. Si el producto se utiliza individualmente, la prueba será individual. Aunque a veces es muy interesante hacer que lo utilicen dos personas juntas: una persona opera el prototipo, la otra guía las acciones y la interpretación de los resultados (en voz alta). Esto hace que hablen de sus ideas, hipótesis y frustraciones abiertamente y de forma natural.

El equipo de investigación debe observar, sin distraer. A menudo se graba, para mostrarlo a otros miembros del equipo o para su revisión. Cuando termina el estudio, se puede obtener información más detallada acerca de los procesos de pensamiento de la gente haciéndoles volver sobre sus pasos, recordándoles sus acciones y cuestionándolas. A veces ayuda mostrarles las grabaciones de sus actividades como recordatorio.

Según Jakob Nielsen basta con estudiar a cinco personas. Entonces se estudian los resultados, se refinan, y se hace otra iteración, probando con cinco personas diferentes. Cinco es por lo general suficiente para dar grandes resultados. Es mejor más iteraciones que más personas.

Los test se realizan en la fase de especificación del problema para asegurar que el problema se entiende bien. En la fase de solución del problema se hacen para asegurar que el nuevo diseño responde a las necesidades y capacidades de los que van a utilizarlo.

La parte más difícil del diseño es conseguir los requisitos correctos, lo que garantiza que se está resolviendo el problema correcto. Los requisitos realizados en abstracto están invariablemente mal. Los requisitos establecidos por preguntar a las personas lo que necesitan están invariablemente mal (aunque expliquen cuidadosamente cómo hacen sus tareas, cuando los observas ves que se desvían de su propia descripción). Los requisitos deben especificarse por ver a la gente desenvolviéndose en su entorno.

Con cada ciclo, los ensayos y observaciones pueden ser más específicos y más eficientes, las ideas se clarifican, las especificaciones están mejor definidas, y los prototipos son aproximaciones más cercanas al objetivo, al producto real. Después de las primeras iteraciones es hora de empezar a converger en una solución.

Diseño centrado en la actividad

¿Y si el producto está destinado a todo el mundo? ¿cómo podemos pretender dar cabida a todos ellos? La respuesta es centrarse en las actividades, no en las personas individuales: lo llama diseño centrado en la actividad.

El modelo conceptual del producto se construirá en torno al modelo conceptual de la actividad, porque las actividades de las personas en todo el mundo tienden a ser similares. Además las personas están más dispuestas a aprender cosas centradas en las actividades que aquellas que parecen arbitrarias.

No hay que confundir tarea con actividad. Diseñar para tareas suele ser demasiado restrictivo. Una actividad es una estructura de alto nivel, tal vez "Ir de compras". Conlleva una serie de tareas con un objetivo común. Una tarea es un componente de nivel inferior de una actividad, tales como "conducir al mercado", "encontrar una cesta de la compra", etc.

Los productos deben dar apoyo a las actividades y a las diferentes tareas de cada una. Los dispositivos bien diseñados empaquetan juntas las diversas tareas que se requieren para una actividad.

Las actividades son jerárquicas, por lo que una actividad de alto nivel puede tener bajo ella otras de nivel inferior, que a su vez se desglosan en tareas. Las tareas son finalmente ejecutadas por operaciones básicas.

Diseñe para los individuos y los resultados pueden ser maravilloso para esas personas en particular pero un desastre para otros. Diseñe para las actividades y el resultado será utilizable por todos.

Insiste en la importancia de que el proceso HCD sea iterativo, especialmente en las etapas iniciales, en las posteriores a veces es complicado, por ejemplo si el producto es un coche. Por ello los mejores métodos combinan los beneficios de la iteración propia de las metodologías ágiles (en este caso iteraciones dentro de cada etapa) y las revisiones por etapa propias de las metodologías tradicionales.

El truco consiste en retrasar las especificaciones precisas de los requisitos del producto hasta algunas pruebas iterativas con prototipos desplegados rápidamente, manteniendo así bajo control la planificación, el presupuesto y la calidad.

La gestión de los proyectos

La parte más difícil del desarrollo de productos complejos es la gestión: organizar, comunicar y sincronizar a las diferentes personas, grupos y divisiones departamentales implicadas.

El proceso de HCD describe el ideal. Pero la realidad de la vida dentro de un negocio a menudo obliga a las personas a comportarse de manera muy diferente al ideal.

Hay muchas presiones. Es típico que se pida que incluyas características que está ofreciendo la competencia, o una nueva tecnología. Otros grandes desafíos son los plazos y los presupuestos insuficientes; o la viabilidad financiera, que por lo general significa rentabilidad. También es importante que tenga un fácil mantenimiento. A veces los clientes no son los usuarios finales, y es necesario estudiar a ambos.

También hay que lidiar con la diferente visión del producto de cada disciplina, a veces con requisitos contradictorios o incompatibles, pero correctos cuando se ven desde sus respectivas perspectivas. Por ello es importante tener equipos multidisplinares, que aprendan a entender y respetar la requisitos de los otros. Si todos los puntos de vista y requisitos son entendidos por todos los implicados, a menudo es posible pensar en soluciones creativas que satisfagan a la mayoría.

También hay que en cuenta a las personas con necesidades especiales, y el enfoque correcto es el llamado diseño universal, que beneficia a todos los usuarios y especialmente a estas personas. Y la clave para ello es la flexibilidad del diseño, que puedan ajustarlo a sus necesidades.

Las soluciones fijas invariablemente fallan con algunas personas; las soluciones flexibles al menos ofrecen una oportunidad para que las personas con necesidades diferentes. A veces es imposible construir un producto que se adapte a todos, así que la respuesta puede ser la construcción de diferentes versiones del producto.

También reflexiona sobre la complejidad y la confusión. La complejidad es buena, la confusión es mala. La confusión no está en el objeto, está en la mente. Y para evitarla es necesario un buen modelo conceptual: las cosas complejas no son complicadas una vez que se entienden.

La normalización es un avance importante en la usabilidad, por ejemplo puedes conducir cualquier coche, en cualquier lugar del mundo. El problema es que las normas pueden tardar tanto tiempo en establecerse que para el momento en que entran en la práctica pueden ser irrelevantes. Sin embargo, las normas son necesarias. Simplifican nuestras vidas y pueden hacen posible que diferentes equipos de diferentes marcas puedan trabajar juntos en armonía.

7. Design In the World of Business

En este capítulo sigue reflexionando sobre la diferencia entre el modelo ideal y el proceso de diseño en el mundo real, donde hay que tener en cuenta la presión de la competencia (con la que solo puedes competir en precio, características y calidad, y además hay que ser más rápidos que ellos), los presupuestos y los plazos, siempre escasos.

Hace especial énfasis en la "Featuritis", la tentación mortal de añadir más características, porque así lo expresan los clientes, porque las añade la competencia o porque las ventas bajan y así se empuja a los usuarios a actualizarse. Es difícil que un producto puede permanecer utilizable y comprensible con todas las características especiales que se le van añadiendo con el tiempo.

Hay dos formas de innovación: la incremental y la radical. La más común y poderosa es la incremental, pequeñas mejoras incrementales, producto de las pruebas y el perfeccionamiento continuo. La más espectacular, y la que muchos buscan, es la radical, pero la mayoría de las ideas radicales fallan, e incluso aquellas que tienen éxito es a menudo después de mucho tiempo. Aunque la tecnología cambia rápidamente, las personas son resistentes a cambiar su forma de hacer las cosas.

También aborda aspectos morales. Estamos rodeados de objetos de deseo, no objetos de uso, ni siquiera de objetos duraderos. Porque las ventas no pueden parar. El diseño de las cosas cotidianas está en peligro de convertirse en el diseño de sobrecargadas cosas superfluas e innecesarias para seguir vendiendo.Reflexiona también sobre las repercusiones que esto tiene sobre el medioambiente.

Los diseñadores necesitan hacer cosas que satisfacen las necesidades de las personas, en términos de función (comprensibles y usables), y en términos de su capacidad para ofrecer emocionalmente satisfacción, orgullo y deleite. En otras palabras, el diseño debe ser pensado como una experiencia total.

Pero en el mundo real no es suficiente. Un diseño que la gente no compra es un diseño fallido, no importa lo bueno que sea. Y tiene que ser fiable y estar en la fecha prevista. Y tiene que ajustarse al presupuesto, ser viable, y dentro de las limitaciones de fabricación o programación. Y debe ofrecer un buen servicio al cliente.

Para satisfacer las múltiples necesidades se requiere paciencia y una combinación de conocimientos técnicos, del negocio y habilidades sociales para interactuar con los muchos grupos de personas involucrados, cada uno con su agenda y todos ellos convencidos de que sus requisitos son críticos.


Tetera que tiene la boca para servir el té y el asa en el mismo lado.

Esta tetera está basada en la que aparece en la tapa del libro y que Don Norman toma de la artista francesa Jacques Carelman (de su libro "Catalogue d’objets introuvables"). Ejemplifica que diseñar cosas bonitas, pero que no satisfacen las necesidades y expectativas de los usuarios, es absurdo. Le agradezco a Daniel Mordecki enormemente el regalo, que tengo siempre junto al monitor .

Podéis consultar más reseñas de libros en: "Libros y reseñas"

miércoles, 26 de febrero de 2014

Customer Journey Map, Mapa de empatía y Personas en UX Research

Son muchas las técnicas que podemos utilizar para conocer a nuestra audiencia o público objetivo, según las posibilidades y características de cada proyecto, y que nos permitirán recopilar diferentes datos, cuantitativos o cualitativos, según el caso: diferentes tipos de entrevistas (contextuales, en profundidad, en pares, etc. con los propios usuarios, con los departamentos de marketing, de atención al cliente, etc.), encuestas, cuestionarios, observación en contexto, focus group, tutoría entre pares, estudio de datos obtenidos de las herramientas de analítica web, estudiar lo que los usuarios dicen en los comentarios dentro y fuera del sitio o en nuestros canales de redes sociales, etc.

Pero luego es necesario extraer conclusiones, sintetizar los datos y sobre todo humanizarlos, que esos entes vagos y abstractos “usuarios”, “clientes” se conviertan en personas con las que podamos empatizar, personas que tienen motivaciones, necesidades, expectativas y limitaciones.

Para ello los Customer Journey Map, los Mapas de empatía y la técnica de Personas son un gran aliado.

Customer Journey Map

Es un documento que ilustra visualmente la relación de nuestros clientes con la empresa y su percepción de la misma, así como sus necesidades y expectativas en cada fase de la relación.

Para ello se identifican:

  • las diferentes fases de la relación desde el punto de vista del cliente. Cómo interactúan a través del ciclo de vida de la relación y cuáles son las interacciones específicas.

    Por ejemplo, si tenemos un e-commerce, la interacción del cliente va mucho más allá de la interacción en la propia web: busca previamente información en otros sitios, compara los productos en diferentes e-commerces, el cliente recibe el pedido, puede hacer una devolución, puede llamar al servicio de atención telefónica, etc.

  • una vez definidas las fases a alto nivel, se identifican los diferentes touchpoint (puntos de contacto concretos en diversos medios) y los momentos de la verdad (moment of truth) aquellos que son especialmente importantes para el cliente o la empresa por su relevancia.
  • después se plasman las necesidades y las percepciones de los clientes: qué esperan en cada fase e interacción (qué quieren lograr, cómo quieren sentirse y ser tratados), qué piensan y qué sienten en cada una, si están satisfechos, si las consideran adecuadas o valiosas, si les surgen problemas, dudas o incertidumbres.

Vemos aquí varios ejemplos, el primero referente a un e-commerce y el segundo a una reserva de vuelos:

No solo nos permite plasmar los objetivos y percepciones de los usuarios en el contexto de uso, sino que nos permite entender nuestro portal dentro de una relación con el cliente que más allá del propio portal e incluso del propio canal online, pero que repercute en el mismo.

En las referencias podéis encontrar artículos para seguir ampliando información sobre los Customer Journey Map.

Mapa de empatía

Una vez segmentado nuestro público objetivo es necesario empatizar con cada uno de los segmentos definidos, comprenderlos como personas en un contexto, que tienen unas necesidades, motivaciones, expectativas y aspiraciones que debemos entender.

El Mapa de Empatía es una técnica de Xplane que nace pensada para la definición del modelo de negocio. Se puede utilizar la plantilla que proponen y que podéis descargar en alta resolución: descarga de la plantilla 'The Empathy Map' de Xplane

O usar una adaptación al español:

Después necesitarás un paquete de post-it:

Nos ayuda a humanizar a los usuarios y a empatizar con ellos para que las decisiones se tomen en base a sus necesidades y expectativas, convertidas en objetivo común de todo el equipo.

Nos ayuda a evitar o minimizar aquello que les preocupa (por ejemplo el pago por Internet), a mejorar la forma en que nos dirigimos a ellos (por ejemplo en términos de lenguaje), a proponer estrategias para llegar y conectar mejor con ellos (por ejemplo a nivel gráfico o a nivel de canales en redes sociales), etc.

En las referencias podéis encontrar artículos para seguir profundizando en los Mapas de Empatía.

Personas

Esta es una de las técnicas más conocidas y habituales, que se complementa perfectamente con el Mapa de Empatía, y que nos ayudará a pensar en los “usuarios” como “personas”.

Una vez segmentado nuestro público objetivo representaremos y humanizaremos a cada uno con un personaje ficticio (Persona), un arquetipo de usuario, del cual haremos una ficha.

Por cada Persona tendremos un nombre y una foto, una lista con sus características (edad, profesión, origen y ubicación, nivel de estudios, estado civil, su experiencia en Internet, etc.) y una narrativa en tercera persona. Queremos saber sus objetivos y necesidades, sus motivaciones, sus limitaciones o frustraciones.

En esta infografía de Lane Nielsen se resumen la técnica:

Otro ejemplo en el cual se incluye ya escenarios y comportamientos:

Ficha con foto y nombre de un joven y listado de características. Enumeración de necesidades, escenarios, funcionalidades y comportamientos.

Imagen de pulsosocial.com

Podéis encontrar muchos ejemplos diferentes buscando "example personas" en Google.

Los “usuarios” están ahora representados por un número manejable de personas. No solo nos permite comprenderlos y empatizar con ellos, sino que las decisiones o los desacuerdos se resuelven referenciando siempre a estas personas.

En las referencias podéis encontrar más artículos para profundizar en la técnica de Personas.

Propuesta de integración en una sola representación visual

Esta propuesta de BMCreativity intenta mostrar de forma unificada la información extraída de las técnicas de Personas y Mapa de Empatía (en la primera columna) y Customer Journey Map (en la segunda columna). En la parte de la derecha vemos también que se identifican factores críticos de éxito, métricas y stakeholders implicados.

Basado en datos

La elaboración de estos documentos suele partir de suposiciones e hipótesis en las reuniones iniciales con el equipo y el cliente, que después se contrastan y refinan con los datos obtenidos durante el trabajo de investigación.

Pero incluso este taller de reflexión inicial y brainstorming es en sí mismo ya muy valioso, porque obliga a todo el equipo a empezar a pensar quiénes son los usuarios, qué quieren, cuándo y cómo usan nuestro producto, etc.

Definiendo "Personas" en un taller inicial con el cliente y el equipo

Enlaces de interés

Añadidos

Artículos relacionados

martes, 29 de octubre de 2013

Reseña "The Elements of User Experience"

Portada del libro The Elements of User Experience

Autor: J. J. Garrett

Nº páginas: 172

Idioma: inglés

Formato: ebook y libro impreso

Fecha de publicación: diciembre 2010 (2nd Edición)

Web del libro "The Elements of User Experience"

He reseñado otros libros antes en el blog, pero me apetecía empezar una sección en la web con reseñas de libros imprescindibles. Qué mejor libro para empezar que un clásico, un libro que debería ser de lectura obligatoria para todo profesional de la experiencia de usuario, puesto que describe como pocos nuestra disciplina y metodología de trabajo de una forma clara y concisa.

Las reseña es una forma de acercarse a la estructura y contenido del libro, pero sirve también de breve resumen y divulgación de cuál es nuestra metodología de trabajo, que tan importante es transmitir a nuestros clientes.

Podéis consultar más reseñas en: "Libros y reseñas"

Sobre el libro

En marzo del año 2000 J.J.Garrett publicaba en su web el diagrama "The Elements of User Experience" (PDF, 20 kb).

Cinco planos de abajo a arriba: Primero User Needs and Site Objetives. Segundo Functional Specifications and Content Requeriments. Tercero Interaction Design and Information Arquitecture. Cuarto Information Design, Interface Design and Navigation Design. Quinto Visual Design

Su aceptación y divulgación fue tal que no es sorprendente que la publicación al año siguiente del libro, que desarrolla y explica este esquema, fuera también un éxito inmediato, convirtiéndose en uno de los libros de referencia de nuestra disciplina.

A finales de 2010 publicaba la segunda edición revisada, con una orientación no solo centrada en la web, sino partiendo de la idea de que los temas, conceptos y principios que trata se pueden aplicar a productos y servicios de todo tipo.

Capítulo 1. User Experience and Why It Matters

En este capítulo aborda qué es y qué no es la experiencia de usuario a partir de ejemplos de la vida cotidiana, cómo afecta al producto final y a sus usuarios.

But even though we interact with countless products and services every day, we easily forget that they are made by people, and that someone, somewhere should get the credit when they work well for us—or get the blame when they don’t.

...

User experience design often deals with questions of context. Aesthetic design makes sure the button on the coffeemaker is an appealing shape and texture. Functional design makes sure it triggers the appropriate action on the device. User experience design makes sure the aesthetic and functional aspects of the button work in the context of the rest of the product, asking questions like, “Is the button too small for such an important function?” User experience design also makes sure the button works in the context of what the user is trying to accomplish, asking questions like, “Is the button in the right place relative to the other controls the user would be using at the same time?”

En este capítulo trata también qué beneficios supone para la empresa y cómo esta querrá medir el retorno de la inversión. Para ello la analítica web puede ser nuestro aliado pues nos permite definir objetivos y medir y analizar la consecución de los mismos, como la tasa de conversión.

Por último aborda el concepto de Diseño Centrado en el Usuario como la práctica para lograr una buena experiencia de usuario.

Capítulo 2. Meet the Elements

El proceso de diseñar experiencias de usuario parece mucho menos complejo si lo descomponemos en cada uno de sus elementos.

En este capítulo introduce las cinco capas de las que se compone el diagrama y que suponen las diferentes fases de nuestro trabajo: Strategy, Scope, Structure, Skeleton, Surface.

Las cinco capas de abajo a arriba (de los abstracto a lo concreto) son: Strategy, Scope, Structure, Skeleton, Surface

De abajo a arriba estos cinco planos dan un framework conceptual para tratar los problemas de la experiencia de usuario y las herramientas que usamos para resolverlos.

Van de lo abstracto a lo concreto y cada plano es dependiente del anterior. Las decisiones de estrategia deben propagarse hacia arriba y los cambios ser contrastados con las decisiones en planos anteriores.

Cada plano está divido en dos mitades:

Los cinco planos (Strategy, Scope, Structure, Skeleton, Surface) están divididos verticalmente en dos mitades. A la izquierda con el título Product as funcionality. A la derecha con el título Producto as information

  • A la izquierda se colocan los elementos específicos de la web entendida como una plataforma de funcionalidad. Aquí consideramos el producto como una herramienta o conjunto de herramientas, así como las tareas y los pasos a seguir en un proceso y cómo los usuarios los completan.
  • A la derecha se colocan los elementos específicos de la web entendida como un sistema de información: el tipo de información que el producto ofrece y lo que significa para nuestros usuarios, con el objetivo de que las personas puedan encontrar, integrar y dar sentido a la información que les proporcionamos.

De este modo llegamos al esquema final, más completo que el de la versión original del año 2000, donde todas las piezas encajan:

Cinco planos de abajo a arriba: Primero Strategy: User Needs and Product Objetives. Segundo Scope: Functional Specifications and Content Requeriments. Tercero Structure: Interaction Design (en product as functionality) and Information Arquitecture (en product as information). Cuarto Skeleton: Information Design, Interface Design (en product as functionality)and Navigation Design (en product as information). Quinto Sensory Design

Capítulos 3 - 7. Repaso de cada uno de los planos

The Strategy Plane. Product Objetives and User Needs

Esta fase gira en torno a la definición de los objetivos del producto y las necesidades de los usuarios.

En la definición de objetivos trata temas como los objetivos de negocio, la identidad corporativa y la definición de indicadores de éxito que después podamos medir para ver si estamos cumpliendo con nuestros objetivos.

En la identificación de nuestro público objetivo y sus necesidades trata temas como la segmentación de usuarios, la investigación de quiénes son nuestros usuarios y qué necesitan y esperan, o la técnica de Personas y Escenarios.

Por último hace hincapié en la importancia de que la empresa y el equipo estén involucrado en el todo el proceso.

The Scope Plane: Functional Specifications and Content Requeriments

En esta fase trasladamos las necesidades de los usuarios y los objetivos del producto a los requerimientos específicos para decidir el alcance: qué contenido y funcionalidades le ofrecemos al usuario y su priorización.

The Structure Plane: Interaction Design and Information Architecture

Una vez que hemos definido los objetivos del producto y las necesidades de los usuarios; una vez que hemos definido el alcance del proyecto concretando y priorizando los requisitos de contenido y las especificaciones funcionales; es ahora cuando nuestras preocupaciones se desplazan hacia aspectos más concretos y comenzamos a definir la arquitectura de información y el diseño de interacción.

Garrett introduce cada una de estas disciplinas y sus fundamentos, así como la forma de plasmar los resultados en entregables comprensibles. Garrett es también muy conocido por su Visual Vocabulary muy útil para la diagramación. Traté este tema en el vídeo sobre diagramación para el MOOC iDESWEB de la Universidad de Alicante.

The Skeleton Plane: Interface Design, Navigation Design and Information Design

Comienza hablando sobre la conveniencia de que los sitios se adecuen a las convenciones y al peligro del mal uso de las metáforas.

Trata también el proceso mediante el cual seleccionamos los elementos de la interfaz, definimos el sistema de navegación y de información, con especial énfasis en que el usuario sepa siempre dónde está y a dónde puede ir, para finalmente plasmarlo en wireframes.

The Surface Plane: Sensory Design

Este capítulo se centra en cómo el diseño visual debe apoyar la experiencia de usuario, puesto que no es solo una cuestión de estética.

Nuestro trabajo no consistirá en evaluar si el diseño es agradable, sino que centraremos nuestra atención en su eficacia. No es una cuestión de estética sino de estrategia.

¿A dónde se nos va la mirada? ¿qué elementos llaman la atención? ¿son objetivos estratégicos o lo que llama la atención nos distrae de los objetivos? ¿el diseño ayuda y apoya a la arquitectura o la socaba? ¿aclara las opciones disponibles y refuerza la estructura o abruma y confunde? ¿comunica la identidad de marca?

Garrett habla del contraste como herramienta importante para trabajar la atención del usuario. El contraste debe servir para guiar al ojo a través de la página, teniendo en cuenta que el uso excesivo conduce a un aspecto desordenado.

También hace hincapié en la importancia de la uniformidad del diseño, en como el uso de plantillas uniformes y consistentes permite comunicar sin confundir. Por último trata el uso del color y la tipografía, o la importancia de crear guías de estilo.

Capítulo 8. The Elements Applied

En este capítulo reflexiona sobre la metodología de trabajo y su aplicación.

Me gusta la idea de que en el momento en que no sepas contestar a la pregunta "¿Por qué los has hecho así?" es que estás haciendo mal las cosas. El enfoque correcto del proyecto depende de que sepas fundamentar cada decisión en la compresión de cada una de las cuestiones en juego en los diferentes planos del proceso.

También es fundamental saberse adaptar a los plazos, al presupuesto y a las personas disponibles, que casi nunca son los ideales. Saber sobrevivir a ese estado de emergencia permanente que parece envolver siempre a los proyectos web, en los que ya estamos retrasamos antes de empezar.

Es importante saber transmitir que este es el único enfoque sensato pues costará tiempo a corto plazo pero ahorrará mucho tiempo a largo plazo. Y al final tendrás un producto que estará a la altura de las expectativas de todos.

Garrett también reflexiona sobre los test con usuarios. Aborda el peligro de considerarlos el principal o incluso el único medio para asegurar la experiencia de usuario. Si bien es evidente que son importantes, son solo una herramienta más para lograr nuestro fin, no son un sustituto de este proceso. De lo contrario es probable que acabes haciendo las preguntas equivocadas y obteniendo en consecuencia conclusiones erróneas.

miércoles, 6 de marzo de 2013

Doctor, a mi web le pasa algo

Una madre espera con su hijo Juan de 6 años en la consulta del médico. Cuando el médico entra y le pregunta en qué puede ayudarles, la madre le contesta:

- Doctor, a mi hijo le pasa algo.

A partir de este momento puedes ponerte en la piel del doctor y leer madre por cliente, e hijo por su portal web.

Consulta 1: El doctor “Solo Test con Usuarios”

La madre ha entrado en la consulta del doctor “Solo Test con Usuarios”, así que el médico les cita dentro de una semana en el laboratorio.

El día acordado Juan está sentado en una silla del laboratorio. El doctor entra poco después con cinco niños de características similares a los que suelen jugar con Juan.

El doctor pide a los niños que ofrezcan algo de comer a Juan. Juan devora con apetito todo lo que le dan y no presenta problemas intestinales ni alergias.

El doctor les pide después que jueguen a un juego de mesa con Juan. El niño juega con desenvoltura con los demás, se muestra sociable y les contesta con fluidez a sus preguntas.

Por último el doctor les pide que jueguen con Juan a pasarse la pelota. Ningún niño puede jugar con Juan. Dicen que no devuelve la pelota, que se queja al apoyar el pie izquierdo, que lo tiene muy hinchado.

El doctor se reúne con Juan y su madre una semana después y les informa de que Juan tiene un esguince. Le receta que le aplique hielo y mantenga el pie inmovilizado durante dos semanas.

Consulta 2: El doctor “Primero Evaluación Heurística, Después Test con Usuarios”

Retrocedemos en el tiempo. La madre llega al hospital, y en vez de entrar en la consulta 1 entra en la consulta 2.

Cuando llega el doctor le dice muy preocupada:

- Doctor, a mi hijo le pasa algo.

El doctor evalúa a Juan.

Doctor: Dime, Juan, ¿qué tal comes?

Juan: Bien, doctor, como todo lo que me ponen en el plato y suelo tener bastante hambre.

El niño parece sano, tiene buen color y un peso adecuado para su edad.

Doctor: ¿Y qué tal el cole? ¿Tienes muchos amigos?

Juan: En el cole me lo paso genial. Tengo un montón de amigos, y nos encanta jugar a las adivinanzas.

El niño se expresa con fluidez, se muestra alegre y sociable.

Doctor: ¿Y te duele algo, Juan?

Juan: Sí, doctor, me duele mucho el tobillo, casi no lo puedo apoyar en el suelo.

El doctor examina el tobillo. Comprueba que tiene movilidad, que está evidentemente hinchado y que el niño presenta inestabilidad al cargar el peso sobre él. El doctor comprueba que el niño solo se queja de dolor cuando lo apoya y que la zona no presenta decoloración. El doctor descarta la fractura porque conoce las reglas de Ottawa.

El doctor informa a su madre de que tiene un esguince. Le receta que le aplique hielo y mantenga el pie inmovilizado dos semanas y vuelvan entonces de nuevo.

Dos semanas más tarde el doctor comprueba que el tobillo ya no está hinchado y que Juan anda sin dificultad. La madre le confirma que el niño está vestido tal y como va todos los días. El doctor se asoma a la sala de espera y le pide a varios niños que entren para hacer una prueba informal, un test de “guerrilla”.

El doctor les dice a los niños que jueguen a la comba con Juan. Los niños juegan con él, pero se quejan de que falla con facilidad.

El doctor les pide a continuación que jueguen a pasarse la pelota. Los niños están un rato pasándose la pelota con Juan, pero se quejan de que es algo lento y el doctor observa que muchas veces les envía el balón desviado y los niños se cansan de ir a buscarlo.

El doctor le recomienda a la madre de Juan que el niño use deportivas en vez de las botas de agua que lleva habitualmente.

Moraleja

Proponer como primera técnica de análisis un test con usuarios suele ser matar moscas a cañonazos. La evaluación heurística es más rápida, más fácil de llevar a cabo y menos costosa que un test con usuarios. Además detecta los principales problemas de usabilidad del sitio: el niño tenía un esguince. Una vez que estos problemas se han detectado y corregido es cuando se debe realizar el test con usuarios.

En el primer caso el test con usuarios solo refleja el esguince, algo que la evaluación heurística detecta fácilmente. Pero además, el problema de usabilidad era tal que el problema de las botas de agua no se podía detectar en el primer test con usuarios, quedaba camuflado porque los niños no podían jugar con él.

Una vez que se detectó y corrigió el esguince, el test con usuarios complementó la evaluación heurística, permitió detectar un problema que surgía al interactuar con los otros niños. Y no fue necesario un test formal, bastó con una prueba más informal.

Y no hay nada más persuasivo para las madres difíciles. Aquellas que no quieren quitarle las botas de agua porque son la última moda y el niño está precioso con ellas. O aquellas que alegan que fulanito, que es un crack del baloncesto, las lleva. Y le da igual que fulanito mida dos metros, lleve botas a medida que solo pesan 200 gr. y se adaptan al tipo de cancha en la que juega. Mientras que su hijo es bajito y lleva unas botas de saldo que le vienen dos números grandes.

No hay nada como enseñarle cómo Juan tropieza al jugar con otros niños y oír como estos no quieren jugar con él para que se decida a ponerle deportivas.

Por otra parte, el doctor tuvo en cuenta quién era su paciente. Si Juan hubiera tenido 85 años no le hubiera preguntado “¿y qué tal en el cole?”. Posiblemente tampoco le hubiera recomendado dos semanas de reposo, pues inmovilizar una pierna a una persona mayor suele acarrear un deterioro funcional que degenera en una rigidez articular difícil de recuperar.

Las directrices de usabilidad no son siempre reglas fijas que puedan ser aplicadas por igual en todos los sitios web, siempre habrá que tener en cuenta el tipo de sitio, su audiencia, sus objetivos o su contexto.

El diagnóstico y el tratamiento propuesto por el doctor se basó en su experiencia. El doctor es traumatólogo (o curandero con 20 años de experiencia), ha visto muchos esguinces y ha comprobado como la inmensa mayoría de sus pacientes se curaban con los tratamientos que les ha propuesto, o no, y ha aprendido de ello.

Pero también se basó en sus conocimientos médicos (adquiridos en la carrera o después de leer cientos de libros, artículos, estudios clínicos y asistir a un sin fin de conferencias  sobre esguinces de tobillo)

Si la evaluación la hubiera llevado a cabo una persona sin estos conocimientos ni esta experiencia, y aun sabiendo lo que debía preguntarle al niño, quizás hubiera concluido que al niño le había picado una abeja y había que ponerle una pomada; o que tenía el tobillo roto y había que escayolar o enyesar (guiño para mis amigos uruguayos...); o que era un esguince pero debía curarse con paños calientes; o que el niño tropezaba al saltar a la comba porque tenía los pies planos y había que ponerle plantillas en las botas de agua.

Por último, nos guste o no hablar de “estándares”,  la realidad es que existen. Un estándar es un documento establecido por consenso que prevé, para uso común y repetido, reglas, directrices y características para actividades o sus resultados, encaminada a la consecución del grado óptimo de definición en un contexto dado. Las normas se basan en los resultados consolidados de la ciencia, la tecnología y la experiencia, y tener por finalidad promover beneficios óptimos [ISO/IEC Guide 2:2004, definición 3.2]

Hay estándares oficiales o formales de usabilidad, la ISO 9241, la ISO 13407, la ISO 9126, ISO 14598 o  la ISO 25000. Las trato en Estándares formales de usabilidad y su aplicación práctica en una evaluación heurística

Y existen estándares de facto, aquellos que tienen una amplia aceptación, como las guías de usabilidad del Gobierno de EEUU, en las que cada una de ellas tiene un apartado con los estudios  en las que se basan, o las del Nielsen Norman Group, basadas todas ellas en estudios reales. Repaso las que me parecen más serias y relevantes en Web Usability Guidelines–Directrices de usabilidad web

Como profesionales de la usabilidad hay que conocerlos, pues nos ofrecen una base de conocimiento importante, son referencias y estudios que avalan nuestro trabajo, nuestros diagnósticos y tratamientos.

Que lleva mucho tiempo conocerlos. Sí, tiempo y hasta dinero.

Que sería arrogante despreciarlos. Yo creo que sí, especialmente si no se han leído.

Que muchas veces hay que contrastarlos y no pueden ser tomados como dogmas de fe. Sí, una evaluación heurística no es pasar una checklist, y se deben aplicar partiendo de un conocimiento profundo de nuestro cliente, su negocio, el tipo de sitio web que tiene, su audiencia, sus objetivos o su contexto.

Que los test de usuarios son necesarios. Si, claro, pero con unos objetivos claros y a su debido tiempo.

En este artículo he hablado de la evaluación de un producto, no del desarrollo del mismo. En el desarrollo, en el que se supone que se tienen en cuenta los criterios de usabilidad desde el principio, que se cuenta con UX Design y en el que deseamos un desarrollo ágil, los test con usuarios informales cobran una dimensión diferente.