Defining a user research system

Knowing how your product is perceived and used is key for user experience designers. Even if you are not a UX researcher, you can do research to gain that knowledge. As soon as you start planning some of these research studies you’ll notice how difficult it could be to decide who do you want to talk to, what’s the purpose of the study or how to interpret discoveries.

However, there’s another challenge that comes with all of this that I consider equally important: how to manage all these findings coming from different sources to make them understandable and actionable for your team, as well as creating a system that encourages a culture of research.

The information gathered as a result of research sessions can come in many shapes and forms. I want to share with you how we have defined a very basic user research system to manage the results of conducted studies so you can create and work from the big picture to the specifics of an issue.

Read more

Intentar ser mejores

Estamos más obsesionados con aparentar ser buenos que a veces nos olvidamos simplemente de intentar ser mejores. Pensándolo tiene cierto sentido, nuestra identidad moral y nuestra reputación son un valor que queremos preservar porque lo que piensan los demás de nosotros nos importa.

El problema surge cuando preferimos proyectar una imagen artifical sobre lo buenos que somos o nos creemos ser (de acuerdo a unos estándares) hasta tal punto que nos impide accionar los mecanismos para crecer: el ensayo y el error.

Me gustaría rescatar una historia que siempre me ha inspirado para explicar mejor esta idea.

Read more

Not a single design process

We spend years and years exploring, trying and following guidelines about what’s right and wrong to do when “doing UX”. We look for the perfect process, the one that tells you: yes, you’re following a user-centred design methodology that will ensure the best user experience possible.

But let’s face it: there’s no one single process that helps you to solve any and every single problem, and not all designers can and must follow the same creativity path to build good solutions.

So what shall we do then? My suggestion, follow principles, not processes and get alignment, not agreement.

Read more

Cómo adoptar un proceso de diseño centrado en el usuario en equipos ágiles

Es bastante común en las empresas de desarrollo tener equipos enteros trabajando mediante metodologías ágiles mucho antes de incorporar ningún rol especializado en Experiencia de Usuario. Incluso cuando cuentan con Diseñadores Gráficos, los referentes clásicos en prácticas como Scrum o Kanban no son muy explícitos en cómo o cuándo deben participar dichos roles durante el proceso. Cuando estos equipos necesitan de una vez por todas tomar una estrategia donde el producto que desarrollan sí tenga en cuenta al usuario para el que está destinado surgen las preguntas: cómo lo hacemos.

Diseñadores de …

Hace unos años cuando preguntaba a los desarrolladores qué esperaban de mí como diseñadora respondían algo así:

Espero que los diseñadores me entreguen un diseño de las pantallas y los flujos donde quede claro cómo debe comportarse la aplicación. Todo esto lo espero antes de empezar a trabajar en una User Story.

Básicamente proponían que el lugar de un diseñador era el de crear especificaciones (las interfaces de usuario vendrían a sustituir los diagramas de casos de uso, de flujo y modelado de negocio) siempre desde el lado del producto (ya que durante el desarrollo ni se nos ve ni se nos espera).

Evidentemente hoy en día no se concibe que un desarrollador sea ajeno al qué debe tener un producto al igual que no es realista que un diseñador no participe en el cómo debe funcionar. Sin embargo, las fórmulas para combinar a estos roles tan especializados dentro del flujo de trabajo ágil no resultan aún claras y, peor aún, generan la sensación de que aún existe más carga de trabajo.

La metodología como producto

Cuando se empieza a poner en práctica algo que hasta entonces no se había hecho o no había dado resultado tenemos que tener en cuenta que pueden llegar fricciones: hay que balancear la cantidad de cosas nuevas que se tienen que adoptar, lo bien o mal que nos las llevamos a la práctica y/o lo útil que resultan para el producto o el equipo.

Si consideramos la metodología de diseño centrado en el usuario como un producto, el equipo serían nuestros usuarios, por lo tanto la ‘percepción’ que tengan es tan importante como la propia eficacia y eficiencia de la metodología.

A continuación expongo algunas ideas sobre cómo enfocar ciertas actividades típicas de metodologías de trabajo como Kanban o Scrum para incorporar prácticas de análisis, diseño y validación para el desarrollo de productos con una mejor Experiencia de Usuario.

User Stories

La idea de las user stories o historias de usuario en desarrollo es muy sencilla, se han usado durante muchos años en la industria, aunque no fue hasta los años 90 que comenzó a recomendarse el uso de una plantilla en la que no sólo se contaba la historia desde la perspectiva del usuario, sino que que se añadía cierto contexto e intencionalidad. La plantilla más sencilla es la siguiente:

As a [type of user]

I want to [do something]

So that I can [get some benefit]

Las historias de usuario son una oportunidad para comenzar la conversación con el equipo de desarrollo y de producto incluyendo la información que hemos obtenido en nuestra investigación.

Type of user (Persona). No hablaremos solamente de tipos de usuarios, sino que podremos ser más específicos y mencionar a la Persona protagonista (la cual lleva consigo una información de valor que podría considerarse parte de los requisitos no funcionales de la plataforma).

Do something (Motivation). Cada historia de usuario debería estar enfocada a resolver un problema concreto, éste problema vendría especificado por la necesidad de un usuario a realizar una actividad.

Get some benefit (Expected outcome). Las actividades y necesidades que los usuarios quieren poder hacer con nuestra solución buscan alcanzar un objetivo concreto, incluirlo como parte de la historia nos ayudará a entender el propósito e incluso a identificar escenarios de test.

Backlog

El backlog es la herramienta que se utilizar para gestionar las User Stories que definen el producto digital, aunque también se incluyen otros conceptos como Epics (User Story de gran tamaño) y Themes (conjunto de epics). Organizar un y priorizarlo no es una tarea menor, aunque se simplifica si mantenemos claro los objetivos y creamos ciertas convenciones.

  1. Epics y Themes deben servir para crear una visión de producto a alto nivel
  2. Las User Sotries deben facilitar la ejecución y entrega del producto

A mí me gusta trabajar con prototipos de baja fidelidad para el primer objetivo y refinar con prototipos de alta fidelidad para el segundo. Es importante considerar para este segundo caso la velocidad a la que se tienen que tomar ciertas decisiones, la cual es posible alcanzar si se han creado recursos como guías de estilo y componentes de la Interfaz de Usuario (UI en sus siglas en inglés).

Desde el aspecto de la validación también se puede trabajar a diferentes niveles de acuerdo con estos objetivos.

Para el objetivo primero definiremos los escenarios que pueden ser más interesantes testear y los KPIs que nos indicarán el resultado y para el segundo la métrica que ayudará a calcular dichos KPIs.

Hay equipos que trabajan con dos backlogs (product backlog y sprint backlog) diferentes para cada uno de los objetivos. Esto tiene como ventaja la libertad para estructurar ambos pipelines como resulten más cómodos, pero carga de mayor trabajo a la hora de priorizar y planificar. Trabajar en un solo backlog requiere sin embargo de más consenso en la convención que quiera tomarse y cuando se trata de incorporar nuevas actividades se generará aún más fricción.

Qué podemos esperar

Cuando las cosas van bien…

  • el equipo entiende el problema y forma parte de la definición de la solución óptima
  • el equipo tiene claro los requerimientos de la solución
  • el equipo sabe lo que tiene que hacer en cada momento

Cuando las cosas van mal…

  • el equipo deja cosas sin terminar
  • el equipo deja de comunicar cosas importantes
  • el equipo hace tareas sin entender de dónde viene la necesidad
  • el equipo no va alineado

Una mánager me dijo hace tiempo algo que me encantó

No hace falta estar de acuerdo sino estar alineados.

Cuando se trata de definir procesos, podemos estar más o menos convencidos de que van a funcionar, pero si el equipo decide conjuntamente seguirlo cualquier persona que se desalinee hará que el resto no funcione de forma óptima.

La mejor estrategia es ir incorporando nuevas técnicas poco a poco, que el equipo se acostumbre a usar ciertos términos e identificar la necesidad de hacer una mejor investigación, mejor diseño y mejor testing y por lo tanto de seguir incluyendo más y mejores técnicas de diseño centrado en el usuario.

Conclusiones

Las técnicas de diseño centrado en el usuario no deben ser incompatibles con las metodologías ágiles, la forma en la que definimos el problema y describimos la solución pueden ayudar a mantener un enfoque más dirigido hacia las personas que usan el software y a conducirnos hacia soluciones que las tengan más en cuenta. Tanto lo que hacemos en diseño como la forma en lo que lo hacemos es parte de la comunicación y el proceso de entrega, así como de la creación e identificación de necesidades del producto.

La siguiente pregunta que me formulo es ¿estamos dispuestos a asumir el esfuerzo?

The Role of Iterative Usability Evaluation in Agile Development: A Case Study :: UXmatters

The Role of Iterative Usability Evaluation in Agile Development: A Case Study :: UXmatters

User Feedback

image

¿Cuándo fue la última vez que hablaste con un usuario? ¿Has improvisado alguna vez una reunión para enseñarles algún concepto en el que estabas trabajado?

No siempre se tiene la oportunidad de planificar una sesión de testing formal ya sea por la falta de tiempo, de recursos, o la inaccesibilidad de los usuarios. Sin embargo, hay veces en los que ‘secuestrar’ usuarios durante un tiempo limitado resulta la única gran oportunidad de recibir de primera mano algo de ‘feedback’.

Recibir ‘feedback’ espontáneo de un concepto en  marcha o sin terminar debe hacerse teniendo en cuenta algunos detalles importantes para que éste nos aporte algo útil. Allá van unos cuantos factores que yo siempre trato de tener en cuenta.

Qué significa ‘Feedback’

‘Feedback’ en inglés significa simplemente ‘comentario’ u ‘opinión’, si es negativo es una crítica, si es positivo es un incentivo, un reconocimiento. En otros contextos puede traducirse como retroalimentación, aunque eso es un tipo de ‘feedback’ que no nos interesa, ya que de un usuario necesitamos sus ideas y su experiencia, y no saber simplemente que está ahí.

Recibir ‘feedback’ debe servirte para seguir adelante con alguna idea o echar marcha atrás. Pero siempre quien debe decidir es quien diseña y no quien opina.

Conoce a tu usuario y demuéstralo

Si estás pidiendo opinión es importante saber a quién se la pides y por qué ¿Necesitas que te ayude a cerrar un circuito? ¿A completar con contenidos que no aparecen? ¿Quieres que valide una de tus hipótesis?

En cualquiera de esas situaciones debes mostrarle cuáles son los supuestos de los que partes y éstos a su vez deberán estar basados en algo que tenga que ver con él o ella.

Si has llegado hasta esa idea es porque se supone que buscabas satisfacer las necesidades de un usuario muy parecido a él o ella.

Concreta

Ve al grano con tus preguntas, no des varias opciones, espera a que se explique y nunca le interrumpas para hacerle ver que no entendió tu pregunta. De la forma en la que se exprese puede que halles una respuesta aún más útil.

Tampoco es el momento de hacer un despliegue de conocimientos técnicos así que pregunta cosas sencillas y espera su reacción.

Siempre positivo

No des opiniones negativas de tu diseño. Más que parecer un gesto de humildad ante una solución no muy buena lo único que consigues es influir en una percepción negativa de la misma. Es preferible un comentario como ‘parece inacabado’ (algo que ya sabes y que tiene solución) a incentivar a los usuarios a pensar que ni si quiera tú estás convencido/a de ir por una buena dirección. Si los usuarios dudan, tenderán a reforzar la visión negativa en lugar de ayudarte a concluir tu idea.

Hay otro detalle que puede que sea simple sugestión pero que a mí me ha ayudado mucho siempre. Generalmente, cuando pedimos ‘feedback’ tendemos a alertar y a justificarnos dando demasiadas explicaciones sobre lo que significa ‘wireframe’ o ‘inacabado’. Es preferible introducir las ideas con dos recursos básicos: el sentido del humor y animarles a imaginar.

No es lo mismo ‘pedirles tiempo para que te ayuden’, a ‘darles la oportunidad de ver algo impresionante’.

En conclusión…

Nunca pierdas la oportunidad de hablar con un usuario, cuéntale lo que haces pensando en las personas como él o ella, demuéstrale que la solución está basada en pequeñas decisiones y que ese pequeño momento es una excelente ocasión para ambos de avanzar en la definición de tus ideas.

Kim Goodwin – Using Scenarios to Design Intuitive Experiences

Kim Goodwin – Using Scenarios to Design Intuitive Experiences

Historias de Usuario

As a designer, I want to read meaningful user stories that talks about real people with real expectations and goals to achieve when using your software.

¿Por qué tus user stories no me dicen nada? Debo confensar que no soy una gran apasionada de Scrum. Generalmente mi desagrado no viene por los principios del desarrollo ágil y su manifesto, sino por quienes lo practican y evangelizan sin querer o saber integrar actividades de diseño en un desarrollo ágil.

¿Tan difícil resulta? Veamos…

En la metodología de Diseño Centrado en el Usuario uno de los principios fundamentales es entender las necesidades de los usuarios y diseñar los productos para satisfacer dichas necesidades o incluso ‘adelantarse’ a ellas. Todo gira en torno a los usuarios, tanto el análisis como el diseño y la evaluación del producto, convirtiéndose en protagonistas dentro de todo el elenco de actores.

En este contexto, Scrum debe ser la metodología de trabajo que guía el desarrollo, asegurando con sus principios y técnicas que se entrega a los clientes un software de calidad de forma ágil y que cumple sus expectativas.

El gap empieza a notarse en el momento en el que las principales user stories, los epics, que deberían describir una funcionalidad de valor para un producto, es decir, para un usuario, terminan convirtiéndose en frases vacías que no dicen nada o más bien dicen obviedades.

Estos son algunos ejemplos que considero insignificantes.

As a user, I want to get access to the item details easily.

As a clinician, I want to get access to the patient details easily.

Pues bien, primer problema es la ausencia de actor protagonista. Tanto la palabra user, como cualquier rol asociado a un usuario, no tienen por qué ser siempre la mejor forma de referirse a quién es el usuario que necesita dicha funcionalidad.

De hecho, las funcionalidades tienden a ser características del producto que se usarán dependiendo de la actividad, y la actividad no depende sólo de un rol sino también de un objetivo, por lo tanto, es más que probable que la necesidad ‘get access to the patient details’ formará parte (o no) de las activitidades para alcanzar algún otro objetivo más importante y relevante para el usuario.

La forma que sugiero de resolver este conflicto es incluyendo el uso de Personas para protagonizar las user stories, entendiéndolas desde un punto de vista de objetivos y patrones de comportamiento. Si asociamos objetivos a nuestros usuarios arquetipos y les dotamos de personalidad podremos referirnos a ellos de la siguiente manera:

As Stepehen King, I want…

As Peter Pan, I want…

As Morgan Freeman, I want…

Segundo problema: el valor de la user story es inexistente. Muchas veces me he encontrado user stories del siguiente tipo:

As a clinician, I want to get access to the patient details easily so I have a good overview of the patient health record.

¿En serio? Una cosa es que a los usuarios, en este caso médicos o enfermeras, les cueste expresar por qué necesitan ver los datos de un paciente, pero no quiere decir que no persigan un objetivo. Este objetivo lo da muchas veces el escenario y el contexto. Mi propuesta es enganchar aquí con los Escenarios de uso para describir qué es lo que el usuario realmente persigue con sus necesidades.

As Dr. Smith, I want to get access to the patient details easily so I can … diagnose a patient.

As Dr. Smith, I want to get access to the patient details easily so I can … schedule a follow-up appointment.

As Dr. Smith, I want to get access to the patient details easily so I can … check blood tests results.

Es importante que la user story siga pareciendo una historia real dentro de un contexto real, ya que incluso a este nivel, ningún desarrollador podrá escribir una línea de código sin hablar antes con el Product Owner, sin embargo, sí podrá entender e imaginar el alcance de la funcionalidad que tiene que implementar. ¿Cómo debería desarrollarse la user story para que el acceso a un paciente sea suficientemente efectivo como para saber diagnosticarlo, reservar una cita o comprobar los tests de usuarios?

Entra en juego también que el objetivo (so I can…) puede determinar el tipo de información que el Dr. Smith querrá ver para decidir o no acceder a los detalles del paciente.

El tercer problema que encuentro es el complemento de modo (condiciones de satisfacción).

As a clinician, I want to get access to the patient details easily.

Estoy segura que a estas alturas la Usabilidad forma parte de los requerimientos no funcionalidades de tu producto desde hace mucho tiempo y que no hace falta redefinirla en cada user story. Hacer algo easily no significa nada nuevo ni nada específico. Si lo que queremos es enfatizar cómo sería acceder a los datos de un paciente por el Dr. Smith de forma sencilla ¿por qué no lo escribimos tal cuál debe ser?

As Dr. Smith, I want to get access to the patient details easily so I can schedule a follow-up appointment.

Aquí podríamos incluir los condicionantes (Acceptance criteria) o bien usar una forma diferente de escribir que ayude a su validación (Acceptance stories).

As Dr. Smith, I want to get access to the patient details so I can schedule a follow-up appointment while I’m waiting for the next scheduled patient.

Aunque estoy complicando la historia intencionadamente, el ejemplo empieza reflejar ciertos factores algo más esclarecedores de lo que significa ‘fácil’ para el Dr. Smith, que espera darle la cita a su paciente entre visita y visita, lo que significará con mucha probabilidad que el tiempo será muy reducido, que tras cerrar el encuentro con ese paciente espera poder llegar su historial, consultar su agenda y reservarle una cita a su paciente.

Sé que también que desde el punto de vista del desarrollador sería más fácil ser más explícito, es decir, si sabemos bien que esos son los condicionantes, ¿por qué no lo escribimos tal cual?

Aquí insistiría en que, primero, sigue siendo necesario hablar con el Product Owner, y segundo, ¿de verdad lo sabíamos desde el principio?

Sé que estoy liando mucho este artículo con preguntas y que da para mucho más, pero querría cerrar esta pequeña deserción con el último de los problemas o, más bien, la última de mis sugerencias.

Si no crees que estos ejemplos tengan ningún sentido, quizá deberías plantearte volver a usar Casos de Uso.

Design Studio – más que una herramienta

La técnica de Design Studio ha sido introducida por primera vez en el contexto de desarrollo ágil como una herramienta de colaboración para ideación de soluciones mediante sketching. Con el paso del tiempo, he tenido la ocasión de poner esta técnica en práctica en múltiples ocasiones con equipos de diferente naturaleza: programadores y diseñadores, analistas y expertos de dominio, sólo diseñadores, etc.

Durante cada una de las sesiones, he ido experimentando cómo los participantes no sólo aportaban sus ideas, criticaban o recogían nuevo conocimiento sobre el problema, sino también, cómo se destapaban las ambigüedades, incertidumbres y las conjeturas erróneas acerca de qué es lo que necesitan los usuarios y de si las propuestas iban en algún momento encaminadas a resolverlas.

La Design Studio es, más que una herramienta de colaboración, una técnica necesaria en una metodología de Diseño Centrado en el Usuario. En este artículo me gustaría recoger algunas de las claves para llevarla a la práctica y sacarle partido. Si quieres saber más sobre cómo planificarla te recomiendo el artículo The Design of a Design Studio y el siguiente recurso.

Diseño dirigido por necesidades de usuario

Como es conocido, en la metodología de Diseño Centrado en el Usuario se parte de la base de que los usuarios que van a utilizar la solución saben mejor que nadie cuáles son sus necesidades.

Independientemente de la capacidad de cada uno de saber expresar verbalmente lo que necesitan o no, las entrevistas a usuarios bien ejecutadas son una fuente directa y rica de información que debe dirigir el resto del proceso de diseño. Obviamente, no es la única fuente, la observación de campo, la comparación de productos, el análisis estadístico de comportamiento previo, o el user testing también proporcionan mucho conocimiento sobre cómo se comportan nuestros usuarios.

Las entrevistas requieren de un ejercicio de análisis posterior donde buscar cómo se expresan los objetivos, las expectativas, las restricciones, el contexto, las preocupaciones, las ideas y los problemas a los que se enfrentan los usuarios. De todos esos aspectos, se busca identificar también patrones de comportamiento para armar lo que se conoce como modelo mental del usuario.

Esta es una información de partida útil para alimentar la sesión de diseño durante una Design Studio.

Personas y escenarios

Las personas y los escenarios suelen ser los grandes olvidados a pesar de que toda solución debe partir de un problema bien formulado como una historia real que ocurre en un contexto real con un usuario real. O digamos, al menos, realista.  Sin embargo, en el momento de idear soluciones y, sobre todo, de defenderlas, tendemos a olvidar para quién se estaba solucionando. La persona y el escenario deben también dirigir la historia que se cuenta, puesto que no estamos en una fase de diseño final, detallado, o de alta fidelidad, sino, todo lo contrario, estamos conceptualizando posibles soluciones y planteando nuevas hipótesis a explorar.

Crítica y valoración de propuestas

Existen múltiples formas de valorar las propuestas de los participantes, aunque lo que es una constante es que, después de una larga jornada de diseño y creatividad las “mentes pensantes” estén poco motivadas a recibir críticas. Puntuar según criterios puede parecer a priori una forma objetiva de valorar el conjunto de las ideas pero se corre el riesgo de descartar demasiado pronto ideas que son geniales por el mero hecho de no haber convencido a la audiencia. Por otra parte, expresar críticas sin el propósito de buscar debilidades para mejorarlas suele minar la actitud de los participantes.

La mejor opción en mi opinión es buscar la validación de las propuestas según los supuestos que se han analizado anteriormente ¿satisface o no los requerimientos que se habían asumido? Posteriormente se puede hacer un planteamiento de en qué punto está la propuesta, es decir, qué haría falta para llevarla a cabo más que asociarle una nota o una ‘prioridad’. Las prioridades son de hecho la forma más macabra de acabar con las grandes ideas después de una Design Studio. Lo ideal, en este caso, es ser capaz de identificar qué supuestos siguen siendo válidos, qué aspectos hay que volver a investigar con o sin usuarios, y cuál es el beneficio que de ejecutar esa idea podría obtenerse al respecto.

Como decía, la técnica de Design Studio es más que una simple herramienta de colaboración e ideación, resulta convertirse en una representación de una parte del proceso de Diseño Centrado en el Usuario y de la formas de cooperación y estrategias de producto que va a diseñarse. Más allá de las complejidades de entrevistar usuarios, sketchear y criticar, lo que se persigue con esta técnica es mostrar las fortalezas y flaquezas de las que se parte.

Con un poco de suerte, puede convertirse en una práctica que cambie la forma de desarrollar productos digitales, no por lo ágil, sino por su orientación a desarrollar soluciones que apasionen a sus usuarios.