Modelar la investigación de usuario con Patrones de Comportamiento

Cuando hablamos de Diseño Centrado en el Usuario siempre nos planteamos un proceso de investigación de usuarios desde donde descubrir sus características, sus circunstancias, sus expectativas y sus objetivos. Sin embargo, una vez que recogemos toda esta información debemos ser capaces de ‘traducirla’ de modo que nos permita tomar decisiones en base a ella en cualquier fase del ciclo de desarrollo.

A veces, el uso de determinados artefactos como las Personas nos ayudan a recordar qué datos son relevantes en nuestra investigación al mismo tiempo que nos ofrecen una guía sobre cómo comunicar dicha información.

Algo similar sucede con los Escenarios de uso. Una forma práctica de descubrir para quién diseñamos es identificando a todos los actores que estarían involucrados en escenarios o experiencias de uso habituales. Sería parecido como cuando estudiamos Casos de Uso pero en esta ocasión ampliaremos las miras más allá de la interacción directa con la tecnología e intentaremos analizar el contexto en el que sucede la acción.

Cuando partimos de roles que definen personas, por ejemplo, para una plataforma de aprendizaje tendríamos a estudiantes y a profesores, creemos que tenemos hecho el trabajo, asumimos los prejuicios que están asociados al rol, sin embargo no todos los roles se comportan, piensan y actúan necesariamente de la misma manera.

Siguiendo con el ejemplo, no se comporta igual un estudiante que cursa una asignatura por primera vez, que el estudiante que está cursando un grado desde hace varios años.

Considerar estos matices son los que a la hora de plantear la arquitectura de la información, la estrategia de contenidos y el diseño se tienen en cuenta en el desarrollo de la plataforma que dará soporte a la nueva herramienta.

Las investigación de usuario no debería estar basada en los prejuicios asociados al rol que se espera que cumplan en el contexto de uso de la tecnología.

Patrones de comportamiento

Una forma de modelar la información relacionada con los usuarios y sus experiencias de uso de una forma mucho más amplia y objetiva es estudiando sus modelos mentales y sus patrones de comportamiento.

En el libro Designing Interfaces nos presentan catorce patrones de comportamiento que se repiten en muchas ocasiones en las personas:

  1. Safe exploration (The user feels positive to explore and discover)
  2. Instant gratification (wants to accomplish something now)
  3. Satisfying (thinks good enough instead of best)
  4. Changes in midstream (stops in the middle)
  5. Deferred choices (skips questions and come back later)
  6. Incremental construction (performs creative activities)
  7. Habituation (use shortcuts or workarounds)
  8. Microbreaks (repeats short tasks frequently)
  9. Spatial memory (remembers things where they are)
  10. Prospective memory (wants to remember things for later)
  11. Streamlined repetition (repeats complex tasks frequently)
  12. Keyboard only (wants to use keyboard exclusively)
  13. Other people’s advice (wants the advice from others)
  14. Personal recommendations (wants to share recommendations and opinions)

Podemos usarlos como referencia a la hora de identificar de qué forma nuestra solución ayuda a estos usuarios (independientemente del rol que tengan) a usar la aplicación de una forma más eficiente.

En cuanto a los modelos mentales tomemos como el ejemplo el rol ‘Desarrollador’ en un escenario en el que esta persona accede a una web con información sobre una herramienta de desarrollo. Podríamos identificar distintos objetivos:

  • Desarrolladores que desconocen la herramienta y quieren ver si les resulta útil en sus procesos habituales de desarrollo
  • Desarrolladores que con cierta experiencia en la herramienta necesita extenderla y adaptarla a sus necesidades
  • Desarrolladores que quieren comparar esta herramienta con otras para saber si es mejor o peor opción
  • Desarrolladores que tienen muchísimas experiencia en automatización pero quieren utilizar una herramienta más mantenible, más estándar, más flexible…
  • Desarrolladores que quieren simplemente ser los primero en tuitear 🙂

Todos estos patrones no son más que arquetipos que nos ayudarán a entender mejor cuáles son las necesidades que hemos de satisfacer y dónde podríamos otorgar una oportunidad de cambio o mejora.

El rol Desarrollador ya no nos dice nada en sí mismo sin el contexto, el escenario y el objetivo. Si cambiáramos la palabra ‘desarrollador’ por ‘persona’, nos daríamos cuenta de que es prácticamente irrelevante el rol, las personas que han llegado a nuestra web ya sea porque han buscado por palabras clave o han leído un artículo que enlazaba nuestra web se comportan de un modo específico según sus objetivos y su experiencia previa, pudiendo estar en modo ‘descubrimiento’, modo ‘aprendizaje’, ‘experimentación’ o incluso en modo ‘desarrollo’.

En el libro Mental Models, la autora Indi Young nos muestra a través de un ejemplo práctico cómo llevar a cabo dicha investigación. Recomiendo su lectura para entender mejor dicho enfoque.

¿Qué hay detrás de tu estrategia de experiencia de usuario?

image

Hoy me gustaría compartir qué tipo de información trato de comunicar cuando escribo la Estrategia de Experiencia de Usuario (UX Strategy) de un nuevo producto o proyecto que queremos empezar a desarrollar.

Generalmente esta UX Strategy se enmarca dentro de la estrategia general del proyecto por lo que cosas como la justificación del caso de negocio o tecnológica la recogen otros expertos en profundidad (ventajas de empresa grande, ande o no ande…).

Bueno allá va, por mi parte como Design Lead, intento establecer algunos conceptos básicos para que puedan entenderse los pasos tácticos y técnicos para desarrollar el diseño con éxito. No es casualidad que muchas de las cosas que aquí mencionen se asocien con las primeras fases de Investigación y Requerimientos de un proceso de desarrollo puesto que la idea es descubrir el problema de diseño.

Relación entre los usuarios y los clientes

No en todas las soluciones existe una relación clara entre una buena experiencia de usuario y un beneficio directo sobre los clientes que compran el software, principalmente porque las razones por las que se adquiere software a veces están más ligadas a cuestiones estrategicas empresariales o políticas más que por razones de usabilidad o utilidad.
Sin embargo, esto no quiere decir que se imposible hacer algo bien hecho, por lo que es importante que establezcamos los beneficios que tendrá sobre el negocio y sus clientes el hecho de que los usuarios obtengan algún beneficio.
Por ejemplo, ahorrar a un médico papeleo significa que podrá dedicar más tiempo atendiendo a sus pacientes, que la calidad del servicio sanitario sea mejor y más eficiente, etc. etc.

Personas, escenarios y contexto de uso

No sólo como input beneficioso para el equipo de diseño y desarrollo sino para ayudar a comprender el ámbito de los proyectos a nivel de management y como puente entre el problema y la solución, considero importante describir el problema y lanzar las primeras ideas de una posible solución. Las personas nos ayudarán a conectar también con los Actores de los Casos de Uso y los escenarios con las User Stories de desarrollo, guardando siempre la perspectiva que nos interesa: la del usuario.

Key performance indicators

Aunque no todo en software son webs, los KPIs pueden definirse de muchas maneras, un libro del que tiro mucho es el de Measuring User Experience. De él busco definir la mejor forma de medir el éxito de un buen diseño alineado con los objetivos de los proyectos ya que no todos son iguales. Algunos necesitan rediseñar, otros lanzar nuevas ideas al mercado, otros iterar sobre algo hecho, etc.

Finalmente incluyo una sección bastante más extensa para establecer el marco de la estrategia de diseño específica que incluye Form Factors, dispositivos, conectividad, accesibilidad, referencia a guías de estilo y supuestos de la tecnología.

Conclusión

En conclusión, la UX Strategy busca identificar y alinear objetivos y valores para establecer una visión común a través del entendimiento de las necesidades de los usuarios, el cliente y el negocio. Por lo tanto, es importante proporcionar toda esa información que, aún siendo susceptible de evolucionar durante el desarrollo, genera los primeros descubrimientos de cuáles son nuestras oportunidades para afrontarlo con éxito.

Como siempre, os dejo algunos enlaces relacionados de interés:

Personas: manteniendo el diseño centrado en el usuario

Últimamente estoy trabajando en al definición e investigación de Personas para el proyecto en el que trabajo, de ahí mis dos últimos posts (libros y UXser Stories), y debo confesar que no me está resultando un trabajo nada fácil.

Por una parte me encuentro con muchos escépticos (sobre UX en general, y Personas en concreto), que vienen a ser principalmente los responsables de conocer las necesidades de sus usuarios y, sin embargo, los primeros que no quieren saber nada de ellos. Este tipo de ir-responsables lo resume todo en 1) Dame una plantilla y 2) ¿No habrá nada por ahí que podamos copiar?

Por otra parte me encuentro con las barreras para acceder a los Subject Matter Experts (expertos de dominio), ex-usuarios contratados para aportar su conocimiento experto en el ámbito funcional. Los usuarios una vez contratados pierden cierto potencial para el testing en mi opinión, pero son más que imprescindibles para hacer escuchar la voz de los usuarios durante el desarrollo. Y es que este es el propósito de una Persona: ser el usuario cuando no hay usuarios cerca. Sin embargo, los expertos de dominio están generalmente para legislaciones, validaciones, hacer casos de uso (si saben lo que es) y traducir software.

Sin embargo es cierto que a veces insistir tanto en una buena práctica de diseño trae su recompensa. Ver, por ejemplo, que sin definición de los target users no se puede justificar un Business Cases o que algunos compañeros que sí confían en el valor de las Personas (léase con doble sentido), son los mejores describiendo lo que necesitan los usuarios hasta el punto de emocionarte al leer ciertas historias es reconfortante..

¿Qué debe tener una buena descripción de una persona? Pues como soy muy fan de leer libros para formarme e informarme os comparto otro recurso muy aprovechable y lleno de ideas sobre como integrarlas en el desarrollo del producto:

image

The Persona Lifecycle (en Amazon)

Dos libros imprescindibles sobre Personas

Seguramente hayas oído hablar alguna vez del uso de Personas como técnica de investigación de necesidades de usuario.

En el caso de que quieras aprender algo útil más allá de los cientos de artículos que sólo buscan posicionarse a favor o en contra, te recomiendo que leas los siguientes libros:

Alan Cooper es dios, la religión es cosa tuya 😉

What’s Your Sign? The everyday personas in the stars | UX Magazine

What’s Your Sign? The everyday personas in the stars | UX Magazine

Lean Documentation: Personas in Twitter

What would you do if you find out that your users are following you on Twitter? Would you read them, listen to them, attend their petitions? 

I’ve asked myself hundred times why we need to create heavy amount of documents even  when we’re using Agile methodologies like Scrum or Lean UX. Documents, in the most classical way are pure literature, graphs, concept maps, sketches (maybe), and tables with data and some lines of code.

Using social networks to document, share and make content alive might be a good strategy for a long life and fast-pace changing project.

One funny example is the Cat User Story twitter profile. Of course, it is made for un, but it could be found both funny and useful for some nice projects like animalvitae.com, is your user like after an animal? 🙂

Eventually, I’m an active follower of some real people that looks like “my target users” to know more about them, so why not to create a “fake” profile to support the user requirement definition for a specific design process?

Personas as Twitter profiles

This is only an experimental practice, so here is the list of actions that I’ll try:

  • User personal data
  • User picture – likely smiling
  • Header picture – my user in a daily scene of his/her life
  • Bio – the quote to resume the main goal of the user
  • Followers – Profile where to find additional information about user’s activities
  • Tweets – (daily) User stories, acceptance criterias, and personal and professional details to know the user better.

Personas’ Remote Research

To build a persona can be tricky; you can just look how actors need months to put in the shoes of a their new characters. In UI design, personas’ creation is part of the analysis stage: they will be used to define requirements, to prepare user tests, to support decisions and to establish a meeting points between designers, developers, and stakeholders.

What is a persona?

Personas are fictitious users you create based on your user research. Personas summarize your user research findings and provide a practical approach to understanding the requirements of your target audience and keeping user perspectives in mind when designing products and creating documentation for them.

By Niranjan Jahagirdar and Arun Joseph Martin for UX Matters.

I wanted to include this definition just as an introduction, because what matters to me now is how to perform personas’ research when you cannot access to any focus group, you cannot do direct interviews or observe users.

Beyond the discussion about whether this artifact is useful or not, I think that even for large organizations is a wothwhile investigation which will help to the team to be closer to the real and target user. So, this is basically my suggestions whenever you need to face a persona’s modeling:

  • Identify primary and secondary individuals to give importance to product requirements
  • Identify behavioural variables and patterns by reading blogs, analysing the professional/gender/demographics statistics associated, and understanding the complexity of their tasks beyond the technology
  • Undestand how business rules, and work environment can affect to the performance and frequency of their tasks
  • Learn how subjects like politics can affect to the user daily work (tasks, goals, attitudes and motivations)

Tips from above are not new, you can find more precise ones in the Chapter 5: Modeling Users: Personas and Goals, of the book About Face 3.

Creating persona’s is not an obscure or expensive procedure but a powerful tool wich will help designers to make decisions confidientially. 

What do we mean when we talk about men and women?

What do we mean when we talk about men and women? Generalization is easy and risky, even though we are in the middle of a fast pace discussion about anything else and totally unrelated we should be careful for two main reasons: respect (it sounds me so Ali-G) and an effective communication.

So think twice at least once, to not to fall in a fuzzy speech.