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.

Cómo hablarle a los usuarios / Cómo no informar de los errores 

De qué hablamos cuando hablamos de informar a los usuarios, cuál es el mejor modo de hacerlo para saltar de la mera muestra de información a una comunicación más natural, más humana. Siguiendo los ejemplos de la foto, estas son mis reflexiones.

Título

No estás conectado vs VimeoError

Mientras el primero de ellos sintetiza un estado general del usuario de forma clara, el segundo se decanta por usar un código del sistema para resumir lo que ocurre. VimeoError nos hace pensar que algo ha podido incluso romperse, que algo hemos hecho mal, quizá el propio hecho de haber intentado usar la app. No estás conectado no dice claramente que sin conexión no hay contenido que ver.

Mensaje

La conexión Wifi y los datos móviles están desactivados. La página se podrá cargar cuando te conectes a una red. vs Could not connect to the Vimeo server. Please check your network settings.

Obviando que uno de ellos esté en inglés, aunque resulte más inaccesible para muchos usuarios, la gramática de ambos mensajes es diametralmente opuesta también. El primero se centra en explicarte qué significa No estás conectado y qué debes hacer para volver a estarlo sin más. El segundo insiste en describirse como un fallo de la app, de algo que escapa del control del usuario (el servidor) y que miremos la configuración de la red. No sabemos muy bien si también nosotros como usuarios hemos configurado mal nuestra red de repente y tendríamos que cambiar muchos parámetros, quizá baste con ‘encender la WiFi’, quién sabe…

Icono

Dinosaurio vs Alerta!

Sin duda, el primero de ellos no sólo intenta suavizar la gravedad del mensaje explicado la situación y la forma de salir de ella sin que cunda el pánico, sino que además busca simpatizar con un recurso gráfico que recuerda a la prehistoria, relacionando el hecho de la falta de conexión a Internet como algo de otra época. Esta línea de diseño emocional contrasta con la visualización de un icono de Alerta que enfatiza la gravedad de lo que ha pasado, aunque se contradiga incluso con el nivel de gravedad: ¿es una alerta o un error?

Control de acción

Más vs Cerrar

Una vez entendido o no el mensaje, la acción se ofrece como última escapatoria para el usuario. Más sugiere ampliar la información acerca de lo que ocurre, la confianza de que es posible hacer o saber algo más acerca de lo que sucede y por tanto yo, el usuario, podré saber cómo solucionarlo. Cerrar es simplemente una señal de que eso era todo y lo que pase después de cerrar es imprevisible.

Contenedor

Dentro del contenido vs Pop Up

El contexto también es importante y en el uso de móviles incluso más debido al espacio reducido para mostrar los contenidos. Usar ventanas modales ha sido una práctica común en aplicaciones de escritorio ya que ayudaba al usuario dentro de toda esa marabunta de ventanas a centrar su atención en el mensaje y tomar una decisión y una acción concreta. Usar un Pop-Up en un móvil en el que todo el contenido visible es ese mensaje (ya que no hay ni conexión ni se han cargado datos), además de ser innecesario me fuerza a considerar el mensaje como prioritario en mis atenciones, aunque lo primero que quiera hacer no sea interaccionar con él sino salir de allí como sea.

Conclusiones

Informar de los errores sin más no significa haber alcanzado un buen nivel de usabilidad en una aplicación, el modo en que esa información se dirige a los usuarios es clave para que éstos sepan qué está pasando y cómo pueden salir de ellos. En este contexto, el tono del mensaje debe acertar con la gravedad del mismo, entender que se dirige a un humano que no tiene que entender nada de sistemas, servidores o bases de datos, sino, a lo sumo, de su micromundo móvil que lleva en la mano.

El ejemplo de Google Chrome me parece fantástico para mostrar como un Diseño Emocional no significa hablarle a los usuarios de forma ‘jovial’ o personificada, sin sólo entender el contexto, empatizar con el humano que lo está usando y reforzar la confianza de que se puede prolongar un uso satisfactorio de la app a lo largo del tiempo.

Siento que Vimeo haya salido mal parado en esta comparación a pesar de sus muchas bondades sigue estando un poco oxidad.

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.

Recordatorios

Hay gente que tiene la habilidad de no hacerte sentir parte de un equipo cuando lo que tienes que decir no les agrada. Muchas veces decir que algo está mal hecho, mal ejecutado o no funciona forma parte de nuestra responsabilidad si es que estamos convencidos de ello. Muchas veces no queda más remedio que decirlo buscando la mejor de las maneras: valorar el trabajo, explicar los razonamientos y hablar con educación (¡británica a ser posible!). Muchas otras veces, cuando no quieren escucharte el único recurso que queda es compartir los riesgos a los que queda expuesta una solución y seguir adelante. Pero siempre siempre se debe ser honesto con lo que único cree, de otra manera, las reuniones de equipo se convertirían siempre en meras luchas de poder de las que además no sacaríamos nada positivo. Y eso es lo que he aprendido hoy, una vez más. 

Kim Goodwin – Using Scenarios to Design Intuitive Experiences

Kim Goodwin – Using Scenarios to Design Intuitive Experiences

¿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 😉

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.