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.

Cross-experience Design – una aproximación

Cuando pensamos en diseñar para múltiples plataformas generalmente atendemos al sentido común que nos dice que el diseño debe adaptarse a la plataforma, a su tecnología y sus recomendaciones específicas de diseño. Sin embargo, si pusiéramos atención al factor humano y muy a pesar de los detractores del “No se diseñan experiencias”, me resulta inevitable pensar que existe un matiz diferente si enfocamos el diseño para la experiencia en una o múltiples plataformas.

Desde un significado literal, Cross-platform se refiere a la implementación de soluciones para múltiples plataformas. Luke Wroblewski incorpora también su término Multi-device design para referirse al diseño único que funcione para varios dispositivos. Ambos términos hablan dela forma de llevarse el concepto a la tecnología de forma que ‘puedas despreocuparte’ del dispositivo o plataforma desde la que se accede a la hora de desarrollarlo.

Ahora bien, cuando se piensa en diseñar para ofrecer experiencias de usuario concretas, el dispositivo o plataforma vuelve a estar en el punto de mira condicionando el comportamiento del usuario, de hecho forman parte de su contexto de uso, por lo que no podemos ignorarlo tan fácilmente una vez encontrada la solución técnica al diseño de un producto.

Existe un tercer término: Cross-chanel UX Design que se refiere a la interconectividad de los diferentes canales que se usan cada día y a la necesidad de consistencia entre ellos. Aunque esto tampoco es nuevo y nos devuelve a la época de los estándares y las divertidas discusiones sobre, por ejemplo, el icono para ‘Guardar’ (‘Guardar’ sigue formando parte de nuestro lenguaje ¿no es así?) y su uso en los diferentes Sistemas Operativos.

Sin embargo existe una situación que me gustaría bautizar como Cross-experience Design (perdonadme si el término ya existe y lo estoy ignorando) y, como todo término nuevo, refiere a algo que ya existe.

Cross-Experience Design sería el conjunto de prácticas para alcanzar soluciones de diseño que se adapten y transformen la experiencia de uso a lo largo del tiempo por las personas que utilizan la solución.

La forma en que estas prácticas toman forman son la Inteligencia Artificial y un diseño que llega a ser consciente del contexto del usuario, como el del Diseño Emocional y, por supuesto, el Diseño de Interacción.

Ideas sencillas en aparencia como lo que esconde Google Now es un buen ejemplos de esta consciencia inteligente.

Sin embargo el carácter temporal es un factor importante en UX, ya que un diseño cross-experience requeriría de incorporar ciertas características que evolucionaran conforme evoluciona la relación con el usuario. Por ejemplo, si diseñáramos un servicio X para un usuario con una necesidad A, una vez cubierta la necesidad A (ya sea circunstancial o temporal) ese usuario puede ‘transformarse’ en otro tipo de usuario con necesidades B, C y D. Como servicio puede que nos interese (o no) que suceda esa transformación de una determinada manera.

Todas las características que la solución ofrezca al usuario para que esta transformación tenga lugar de forma que se prolongue una experiencia enriquecedora a lo largo del tiempo son las que refiero como cross-experience design.

Puede que a estas alturas haya divagado demasiado, en cualquier caso, es posible que amenace con nuevas ideas para apoyar este concepto.

Kim Goodwin – Using Scenarios to Design Intuitive Experiences

Kim Goodwin – Using Scenarios to Design Intuitive Experiences

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)

Experiencia de Usuario para Desarrolladores

Si alguno de vosotros se ha preguntado como desarrollador qué debe saber o conocer sobre el diseño de Experiencia de Usuario, qué es el Diseño de Interacción o el Diseño Visual y qué tiene que ver todo esto con el proceso de desarrollo, le recomiendo este vídeo y los siguientes enlaces:

Espero que os resulten útiles.

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.

One design to rule them all?

image

Today I wanted to get some clarity about a way to efficiently approach the UX design when targetting multiple mobile devices. You know, to deserve my holidays.

During my research, I’ve needed to take apart aspects like the Interaction design and get focused only on the very basic initial challenge: the app structure and navigation. I’ve also centred the research within the smartphone scope by considering only Android, iOS7 and Windows Phone 8.

These are some early ideas I’d like to investigate further:

  • The commonalities and diferences between the in-built functionalities like Search, Notifications, Multitasking, Back vs Up navigation and in-app navigation.
  • A compliance layout, app structure and navigation which naturally fits into the different platforms according to their guidelines.
  • A translation (if exists) between the different navigation patterns (flat, hierarchical, etc.) and the recommended UI controls (Tabs, Toolbars, Segmented control, etc.)

So I’ll continue digging into the guidelines and trying some design to validate (or not) the hypothesis “One” design to rule them all might be difficult but not impossible, it is, actually, needed.

Cheers