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

Interaction Design with Indigo Studio and GifCam

Interaction Design with Indigo Studio and GifCam.

Indigo first release was free forever, although it’s not available for download any longer. I’m one of the few who still have a Lite license and can take advantage of this powerful prototyping tool built in Silverlight.

Indigo has helped me to demonstrate design, simulate behaviour and communicate specifications with the development team and also with end users.

GifCam is just a cool resource that helps me to share microinteractions implemented with a prototyping tool.

And this ‘Hello World’ example is nothing but one of the design interactions in motion I’ve been working this morning 🙂

Un año de proyectos

Uno de los objetivos que teníamos cuando hace un año pusimos en marcha esta firma era el de dar soporte a todo esos proyectos que siempre hemos querido iniciar y nunca encuentran el tiempo, el dinero o el coraje suficiente para salir adelante.

Éste ha sido, en sí mismo, el primero de los retos, nuestro Proyecto Cero.

Como balance de un año me gustaría reflexionar sobre los resultados, los cuales creo que han sido más positivos que negativos.

Los principios nunca son fáciles, pero contamos con el empuje de mucha gente, entre los que destacaría a Braulio y su esfuerzo por crear la comunidad de Training Bubbles a través de la cual ofrecimos algunos vídeos rápidos sobre técnicas prácticas de Diseño y Experiencia de Usuario.

Healthy Design Services muestra muchas de nuestras aspiraciones y resumen los principios en los que nos gustaría comunicar nuestros proyectos. Un diseño saludable es representado por soluciones óptimas, balanceadas, perdurables con una estrategia sólida que pone atención en el detalle, que confía en los beneficios a largo plazo sostenido por pequeños logros a corto. Un diseño como servicio al igual que un producto como servicio para ser usado y utilizado bien, fácilmente, sin aditivos y sobre todo lleno de utilidades.

No ignoramos otro de los matices sobre nuestra identidad en esta ocasión relacionado con el background de esta pareja de dos en UXSALAD: ambos provenimos de la industria de software sanitario la cual nos ha dado una visión muy particular de lo que supone el diseño de interacción persona-ordenador con propósitos de servicio humanitario, es decir, cuya base fundamental reside en el tratatimiento de información y servicios que gestionan datos sensibles y vitales para la sociedad más que como oferta de entretenimiento, productividad o cultura general.

Con esta filosofía nos hemos mantenido estos doce meses, en los que entre otros, hemos dado comienzo al desarrollo de una plataforma social de cine que pasará a su fase beta a partir de mediados de 2014.

Aunque tampoco podemos ignorar los fallos (aún es pronto para hablar de fracasos). Es obvio que UXSALAD es un estudio de diseño al que no le dedicamos el 100% de nuestro tiempo, la principal razón es que necesitamos un flujo de ingresos estable para vivir. Una de las cosas que no quisiéramos que pasara es pervertir el buenhacer por culpa de la necesidad, si bien es cierto que la necesidad agudiza el ingenio y aprieta las tuercas para no relajarse demasiado, la prioridad es disfrutar del tiempo que dedicamos a nuestros proyectos y darles la atención que requieren. Fracasaremos el día en el que lleguemos tarde con alguna de nuestras ideas al mercado o a la audencia, sin embargo, trabajamos para ganarle tiempo a esta empresa (en el sentido menos mercantil del término).

¿Por qué tus user stories no me dicen nada?

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.

(via carmelhassan)

So what’s a good solution?

As a doctor working in an Emergency Department and seeing patients (sic: people) with largely preventable conditions/diseases alot of the time, I really like the idea of personalised medicine and involving patients and empowering them to take control of their healthcare. Brushing teeth is an excellent example that I wouldn’t have thought of before. However, I would echo some of the previous comments on the dangers/naivety of providing some of this info. Lab results are only relevant when married to the clinical information (i.e. the pateint’s history, symptoms, past history and examination findings). This information is far more important and lab tests should only then be done to confirm or rule out your findings from the clinical info. Therefore providing patient information printouts based on the lab results alone is foolish and dangerous.

Also the speaker makes a good point that fear does not work in health education/promotion. I think that giving a patient a printout saying that you have 15% (or whatever) chance of getting prostate cancer/breast cancer/arthritis/whatever is probably one of the most fear-inducing things you can do to a patient. Especially considering it is almost impossible to generate that kind of accurate prediction of any condition based on a blood test or even group of blood tests.

The speaker also says that they have used colour (as if to say “Duh why hasn’t this been done before”). The dept I work in has been told by hospital management to stop ordering more paper as the hospital acn’t afford it. We have had to totally rationalise the amt we are printing and handing out. I know this happens alot of places in the public health system. So we have barely enough paper to put in printers let alone colour printers and the cartridges to keep them running. he may be aiming his comments at the lab companies that make all that money but I feel his talk doesn’t take into account the practicalities that exist in an ED / other healthcare settings

John Cronin (Posted 3 years ago) on Thomas Goetz’s TEDMED talk titled: It’s time to redesign medical data.

I found this comment as a perfect example of the real challenge on Information Design in Healthcare still Today.

We have to think and design for real practice with its context, its users, its information quality. Colour sometimes is a luxury and ranges, percentages and reference values could mislead instead of giving support.

 

Interfaces de usuario en el ámbito sanitario

Diseñada para la salud

Este viernes 23 de Mayo participé en el evento de UXSpain para hablar de Interfaces Usuario en el ámbito sanitario. Me ha hecho una enorme ilusión asistir a este evento un año más y en esta ocasión como ponente para introducir un tema como el de la Experiencia de Usuario en la Industria Tecnológica Sanitaria a la que llevo dedicándome casi 5 años.

Nervios a parte, intenté comunicar con algunos ejemplos cómo las interfaces de usuario en este sector pueden llegar a representan y determinar el modelo de antención sanitaria (servicios y productos incluidos).

La Sanidad es un ámbito de caracter humanitario que, sin duda, puede y debe verse beneficiado de las disciplinas del diseño, no sólo como especilidades sino como parte de sus estrategias transformadoras. Esta es la idea que me animó a compartir mi experiencia y que espero que resultara interesante a todo/as los asistentes.

Gracias a todos por vuestros amables comentarios en en Twitter y sobre todo a los que pude verles las caras e intercambiamos impresiones. No me gustaría que se perdiera el caracter de encuentro de este evento ya que es sin duda lo que más aporta a nivel personal para construir esta comunidad tan importante a nivel profesional.

Quiero agradecer también a mi compañero de vida Antonio Benítez su apoyo y ayuda, que se ha currado la mitad de las slides y sabe tanto o más que yo lo difícil que es la toma de decisiones de diseño y procesos en este sector.

¡Muchísimas gracias a todos, nos vemos en el próximo uxspain! Por supuesto, enhorabuena a la organización.

Healthcare start-ups

The path to the well planned and designed health services of the future goes through many professions from the medical to architecture to interior design to UI and UX expertise to app development, industrial design and landscaping.

We may live in an increasibly ‘virtual world’ of connected devices and experiences, yet there are still innovators, entrepreneurs and startups focused on building the bricks and mortar of tomorrow’s healthcare experiences.