Este proyecto no ha sido sólo un excelente trabajo de colaboración entre los miembros del grupo, sino una forma de ver en vivo la evolución de la interacción entre un dispositivo y los usuarios. Hemos podido desarrollar un producto desde la forma más abstracta de verlo, pasando por prototipos de baja fidelidad y finalizando con un prototipo de alta fidelidad y sus mejoras respectivas.

Leyendo los artículos publicados en la web hace unos meses, nos damos cuenta de cómo hemos ido refinando la interacción entre el usuario y el producto poco a poco, por capas.

Apreciamos también la flexibilidad con la que hemos podido seleccionar los proyectos a realizar, algo que ha potenciado nuestra creatividad y nuestras ganas por resolver los problemas de interacción con los que nos hemos ido encontrando.

Deseamos que en años futuros, se sigan haciendo estos proyectos que, además de involucrar de forma íntegra al alumno en la clase, ayudan a entender perfectamente el campo de la Interacción Persona – Ordenador.

Como parte del desarrollo de nuestro proyecto, se realizaron tests de usabilidad según los parámetros aprendidos en la asignatura y tomando como base el protocolo preliminar realizado previamente. Es importante destacar que tras el test piloto y el primer test de usabilidad, se refinaron ciertos elementos del test, como parte del proceso iterativo. Éstos detalles se irán desglosando en las distintas secciones.

Test Piloto

El test piloto se realizó principalmente para verificar que el protocolo preliminar para los tests de usabilidad era correcto y para refinar detalles y aspectos a considerar en los subsiguientes tests. Se realizó con 2 pacientes y 2 médicos. Tras efectuar el test piloto, se consideraron ciertos aspectos sobre el protocolo:

• Es importante familiarizar, pero de forma muy breve, a los pacientes que no conozcan un diario de dolor. Debido a que el objetivo de los tests será reproducir situaciones reales, se les familiarizará de forma ‘real’, es decir, una descripción breve de la herramienta como la que un médico o un paciente allegado le podría hacer. Esta descripción no debe entrar en detalles y debe limitarse a mencionar que funciona en un dispositivo móvil y que permite registrar el dolor. Debe evitarse ‘bias’ o parcialidad a la hora de hacer la introducción, para evitar inmiscuirnos en el test.
• En el caso de médicos, la introducción será más breve todavía, ya que éstos están familiarizados con la existencia de diarios de dolor tradicionales.
• En el protocolo se consideró únicamente la medición de rendimiento. Además de eso, se ha decidido hacer un test con “pensamiento en voz alta”, para conseguir resultados más variados y descubrir más detalles a refinar en el prototipo.

Los roles que desempeñaremos irán rotando, para evitar que una sola persona realice durante todos los tests el mismo papel.

Protocolo

Se han hecho algunas modificaciones al protocolo preliminar, por lo que el protocolo para los tests de usabilidad quedaría como se aprecia a continuación. Se ofrece un resumen con las principales características del protocolo.

• Participantes: Pacientes y Médicos. Se harán tests de usabilidad diferentes para estos dos grupos, nunca juntos. Los pacientes serán habituales usuarios del diario de dolor tradicional. Los médicos serán especialistas en dolor de distintas disciplinas: neurología, traumatología, anestesiología, etc.
• El prototipo con el que interactuarán será un iPhone con el programa correspondiente al Diario de Dolor cargado.
• El rol de los miembros del grupo irá rotando (observación – facilitador – guía).

A continuación se ofrecen los detalles de los tests para pacientes y médicos.

• Test para Pacientes: se le hará una breve introducción del propósito del test de usabilidad, tratando de ser empáticos con el usuario y haciendo que éste se sienta cómodo. La introducción tendrá las características citadas en el apartado anterior. Se le mostrará una situación real de dolor y se le pedirá al usuario que inserte el dolor en cuestión. Utilizaremos medición de rendimiento como protocolo para el test y también haremos test de “pensamiento en voz alta”.
• Test para Médicos: se le hará una breve introducción del propósito del test, siendo empáticos con el usuario. En las evaluaciones preliminares, en anteriores etapas del desarrollo, pudimos detectar que un alto porcentaje de los profesionales usaban el diario de dolor para investigación y para registrar picos de dolor con nuevos fármacos, en proyectos con compañías farmacéuticas y laboratorios. Esto nos ha llevado a decidir que en la introducción, siempre con el esquema citado en el apartado anterior de esta entrada, se mencione brevemente la facilidad de comprobación de datos en investigaciones como ventaja del prototipo. A continuación, se les mostrará una situación real donde deberán comprobar la información de cierto paciente.

Notas que tomaremos para llegar a resultados fiables y detalles en los que nos fijaremos especialmente:

• Tiempos de realización de tarea, errores, número aproximado de pulsaciones (taps en la pantalla), posibles bloqueos durante el proceso, entrevista final para calcular satisfacción.

Realización

La realización de los tests de usabilidad se hizo de acuerdo al protocolo anteriormente establecido. Se ha hecho el test mediante el prototipo de alta fidelidad creado en anteriores fases del desarrollo del proyecto.

En los tests siguientes se realizó el siguiente procedimiento: se le introdujo a cada usuario de la forma anteriormente descrita y se le pidió que realizase una tarea concreta. A continuación, medimos el rendimiento general de cada usuario midiendo el tiempo que tardaba en ejecutar la tarea. En todo momento, se observó cómo el usuario se desenvolvía con la aplicación, fijándonos en los momentos de bloqueo. Se anotaron estos errores. Finalmente, a cada usuario se le hacía una breve entrevista preguntándole su impresión general del prototipo y los obstáculos encontrados.

Los tests realizados son los siguientes:

• Test nº 1. Sujetos del test: 4 pacientes. No hay incidencias respecto a la introducción en ninguno de los usuarios. Los usuarios entienden correctamente la metáfora del diario y su objetivo.
• A los cuatro pacientes se les pide rellenar un dolor de 7, 8, 3 y 4 de intensidad, respectivamente. A dos de ellos, los de dolor 7 y 8, se les pide que rellenen el dolor como reciente, y a los de los dolores 3 y 4 se les pide que rellenen el dolor como del día antes a la misma hora y de una semana antes a la misma hora.
• Se eligieron estas tareas porque los picos de dolor (dolor irruptivo) suelen ser más destacados y el usuario suele anotarlos inmediatamente, mientras que el dolor constante y más leve (dolor basal) suele olvidarse y rellenarse más tarde, al ser un dolor que permanece.
• A uno de los usuarios se le hizo test mediante protocolo de “pensar en voz alta”.

• Test nº 2. Sujetos del test: 4 médicos. No hay incidencias respecto a la introducción en ninguno de los usuarios. Los usuarios entienden correctamente la metáfora del diario y su objetivo.
• A los cuatro médicos se les pide consultar el dolor de la paciente Lucía Fernández, de 57 años de edad. A dos médicos se les pide que averigüen cuando tuvo el paciente su punto de dolor más bajo y la media de intensidad de dolor. A otros dos se les pide que averigüen qué medicación están recibiendo actualmente y qué medicación tenían antes.

Resultados

• Pacientes: el tiempo de realización fue: 32 y 45 segundos para las casos de dolor reciente; 50 segundos y 1 minuto con 10 segundos para los casos de dolor de hace más de dos horas. En todos los casos, el número de pulsaciones en la pantalla por paso fue de 2 ó 3.
• Bloqueos durante la tarea: los dos pacientes encargados de registrar un dolor de hace más de dos horas titubearon en la pantalla de selección de fecha. Uno de ellos tardó varios segundos en darse cuenta de cómo configurar la fecha. Otro de ellos no fue capaz de entender qué columnas correspondían y fue guiado. Uno de ellos destacó que es confuso que “todo el cuerpo se resalte al seleccionar un área de dolor” al pulsar en el lugar de éste.
• Satisfacción general: los pacientes que ubicaron dolor reciente dieron una puntuación de 8 y 9  sobre 10 a la satisfacción que obtuvieron y destacaron que si esto estuviese disponible, lo usarían en vez del diario tradicional. Los pacientes que tuvieron que seleccionar fecha y hora del dolor dieron una puntuación de 5 y 6 sobre 10, uno de ellos haciendo especial hincapié en que la pantalla de selección de fecha era “demasiado lío”. Se les preguntó por la ayuda contextual ofrecida en cada paso y la calificaron como útil.

• Médicos: el tiempo de realización fue: 50 y 55 segundos para la tarea de ver información sobre el dolor de la paciente; 1 minuto y medio y 2 minutos para la tarea de ver información sobre la medicación del paciente. En todos los casos, el número de pulsaciones en la pantalla por paso fue de 3, 4 y 5.
• Bloqueos durante la tarea: los dos médicos se quedaron bloqueados en la pantalla de información sobre el dolor del paciente, y uno de ellos necesitó de guía para interpretar la gráfica de dolor.
• Satisfacción general: la nota de satisfacción tuvo un 7 sobre 10. Dos de los médicos destacaron que sería una mejor idea que el médico pudiera ver los resultados en una pantalla más grande, a lo que se les respondió que si bien este prototipo era en dispositivo móvil, estaba pensando para tener también un front-end en un dispositivo más flexible, como uno ordenador, para que el facultativo analice o imprima los datos. Se preguntó por la ayuda contextual, y aunque dijeron que era útil, dos de los médicos afirmaron que era algo escasa.

Análisis de resultados

A continuación se ofrecen los problemas de usabilidad identificados:

• La pantalla de selección de fecha de dolor para pacientes supone un obstáculo y crea confusión en el usuario. La selección de hora y minuto ofrece una exactitud de selección de tiempo innecesaria y demasiado pequeña.
• La selección de la parte del cuerpo que origina el dolor es imprecisa y se ilumina todo el cuerpo. Dicho feedback es confuso porque el usuario no sabe si ha seleccionado bien el área de dolor.
• La ayuda en profesionales es escasa y requeriría de una ayuda más extensa, a parte de la contextual ofrecida con el botón de “Ayuda”.
• La gráfica de dolor fue fruto de confusión y supone un caso complejo a analizar. La gráfica debería mostrar de forma más adecuada los datos.
• Los botones de “Ayuda” tienen un área de acción demasiado pequeña.

Mejoras propuestas

• Mejorar la pantalla de selección de fecha de dolor: eliminando la selección de minuto, clarificando mejor a qué corresponde cada columna de selección.
• La pantalla de selección de parte del cuerpo con dolor debe ser mejorada: distinguir las partes del cuerpo y que se ilumine sólo la parte seleccionada, así como poder seleccionar varias partes (en el caso de que el dolor esté en varias zonas), y que se pueda enviar tras pulsar un botón “Enviar”, y no que se envíe directamente.
• Aumentar la ayuda para profesionales haciendo una sección de ayuda extensa detallando cada paso de obtención de información.
• Mejorar la gráfica de dolor: que sea visible horizontalmente, para mejor visibilidad, y que sea más sencilla.
• Incrementar el área de acción del botón de “Ayuda”. El botón sigue teniendo la misma apariencia pero requiere de menos destreza pulsarlo.

Para llevar a cabo el test de usabilidad de nuestro prototipo realizaremos una evaluación similar a la de los prototipos de baja fidelidad.

Los participantes del test serán los médicos con los que tenemos contacto, varios pacientes (habituales del diario de dolor) y usuarios que no conocen el diario de dolor, para así también conocer los resultados en posibles pacientes que no tengan una visión anteriores del diario de dolor, para los que dicho diario es algo completamente novedoso.

A dichos participantes se les entregará el dispositivo móvil (iPhone) con el que interactuará y se le pedirá que realicen sus respectivas rutinas.

En caso de los pacientes haremos una distinción.

Para aquellos pacientes que están familiarizados con el uso del diario de dolor, realizaremos una breve introducción resaltando las ventajas que otorga la aplicación. Mediante este dispositivo se puede anotar la información que habitualmente rellenaban en su diario de dolor, de una forma discreta, cómoda y rapida en cualquier momento. De esta forma el médico recibe la información al instante, pudiendo así ir realizando un diagnóstico antes de que el paciente acuda a la consulta.

Todo ello se le informará al paciente y se le pedirá que trate de anotar un dolor, haciendo hincapié en que tan solo es un prototipo y que no tenga miedo a la hora de expresar problemas que le surjan a la hora de rellenarlo.

En caso de pacientes nuevos, que nunca hayan usado el diario de dolor, la introducción se basará en mostrar la facilidad a la hora de cumplimentar los datos mediante el dispositivo. El médico anteriormente ya le ha recomendado el uso del diario de dolor, por lo que le presentaremos la aplicación como el propio diario de dolor. Con el puede informar al médico al instante, con discreción de una forma rápida y cómoda. El mensaje es el mismo que al paciente que conoce el diario de dolor clásico, pero se adoptará otra perspectiva.

Tras ello se le pide que trate de anotar un dolor haciendo de nuevo hincapié en que es un prototipo y que no tenga miedo al expresar su opinión sincera.

Para el caso del médico, le expondremos las ventajas de poder ver el seguimiento de un paciente en cualquier momento, ya que de esta manera por ejemplo, al dirigirse a la consulta o en caso de una emergencia de algún paciente, puede ver los últimos datos del paciente, la medicación… De esta forma no necesita llegar a la consulta para conocer todos los datos y por lo tanto puede desempeñar su labor de una forma más eficiente. Tras ello se le animará para que vea los datos de un determinado paciente de un paciente.

El test de usabilidad que realizaremos será una medición del rendimiento anotando especialmente los tiempos, los errores, el número de pulsaciones y una entrevista final para calcular el grado de satisfacción.
Para dicho test, uno de los miembros actuará de facilitador y guía, ayudando al participante a que realice sus tareas cómodamente, mientras al menos uno de los dos miembros restantes observa.

Les presentamos el prototipo de alta fidelidad, basado en una plataforma de dispositivos móviles. En este caso, en concreto, para iPhone. Se recomienda verlo en un iPhone, iPod Touch o dispositivo con el sistema operativo iOS.

Las instrucciones son las siguientes: abrir Safari desde el dispositivo e insertar la web: http://www.diariodedolor.com/hiFiPrototype. Pulsar el ‘+’ en la barra de abajo de Safari y seleccionar “Añadir a pantalla de inicio”. Se añadirá a su escritorio de iconos de iPhone un icono con la aplicación del prototipo. Ahora acceda a través de ese icono y podrá interactuar con el prototipo correctamente. El prototipo también se ve correctamente en algunos exploradores Safari y Chrome en PC y Mac, aunque las ‘ruedas’ de la sección de pacientes no permiten interacción alguna. El prototipo está diseñado para iOS.

• Se han realizado los tests de usabilidad informales de los 3 prototipos desarrollados en las anteriores fases y se han analizado los resultados. A continuación se ofrecerán los detalles de cómo se han realizado los tests, las características en cuanto a participantes, los resultados con los problemas a los que nos hemos enfrentado y, finalmente, las conclusiones sobre cada prototipo.

Cabe destacar que hemos seguido las estrategias de evaluación que mencionamos en la anterior fase del proyecto. Por tanto, la evaluación de los prototipos 1 y 2 es muy similar en forma, siendo más diferente la evaluación del prototipo 3.

Evaluación del prototipo 1

Sujetos del test: 2 pacientes, 3 médicos.

Pacientes

Los pacientes entienden correctamente los dos puntos específicos de este dispositivo. Se les introduce en los aspectos básicos del sistema, con éxito:

• Interfaz web: En el sentido en que podrán rellenarlo en cualquier ordenador, no solo el suyo propio, y en cualquier momento y lugar.
• Metáfora diario: Está pensado para ser rellenado al final del día (como un diario) aunque admita ser rellenado más de una vez al día.

Entendida la parte básica se le presenta mediante cartulinas la interfaz de usuario, superpuestas en un monitor de ordenador.

De la cual se sacan los siguientes comentarios a tener en cuenta a la hora de depurar al interfaz:

• En la cartulina no todos los pacientes apreciaban correctamente las líneas en gris sibre gris.
• Los números pueden ser demasiado pequeños.
• Adicionalmente y por parte del grupo se plantea a los usuarios si el tamaño de la cuadrícula seria suficiente para poderla clicar fácilmente mediante un ratón (la prueba se hace “a dedo”), obteniendo una respuesta positiva siempre y cuando se mejore el primer punto.

Acto seguido se les invita a añadir un nuevo evento en su diario de dolor haciendo click sobre la hora y dolor correspondiente y haciendo aparecer al lado del “cursor” el cuadro de posibles causas.

• Se consulta si se esperaba esa respuesta del sistema, resultando mayoritariamente que no (un paciente no tenía expectativa alguna sobre la reacción del sistema).
• Se consulta si se cree que se ha obrado bien en el paso anterior (es decir, esta es la respuesta lógica del sistema si no hay error al clickar algo que no se debe, no al haberse equivocado de cuadrícula), obteniendose unanimidad en el sí.
• Se consulta si se tiene idea de para que puede servir el nuevo cuadro: Mayoritariamente por instinto los pacientes consultados llegan por si mismos a la respuesta correcta, sin embargo uno de ellos erroneamente cree que debe anotar que hace o hacía al anotar en el diario y no en el momento de dolor. Tras una breve aclaración lo entiende y le parece razonable.
• Finalmente se les pregunta, en el caso de que creyeran que se han equivocado que deberían hacer: aquí se encuentra un problema: las flechas de avance y retroceso (incluidas para el tratamiento de errores) se encuentran bajo la fecha, dando lugar a confusión si esas flechas manejan la fecha o el avance (siendo mayoritariamente creido que se modifica la fecha).

En la cual se pide a los usuarios marcar la zona de dolor, que se hace resaltar con cartulina de color y espera a que el usuario avance mediante la flecha para poder presentarle de nuevo el comienzo del sistema para añadir otro dolor a diferente hora:

• Se genera una duda generalizada: ¿Ya está? Falta de feedback al haber concluido el registro.
• Duda minoritaria: ¿Se puede marcar más de una zona de dolor?.

Un a vez concluido todo el proceso se vuelve a la pantalla inicial con la cuadricula rellenada hora/intensidad marcada en rojo para indicar que está cumplimentada.

• Varias consultas de que significa el cuadro rojo: Quizá se deba elegir otro color u otra forma de señalar este hecho.

Se solicita finalmente que se piense que cree que debería hacer si desea cumplimentar el diario del día anterior ya que se le olvidó o no pudo hacerlo:

• Dado que ya se tuvo la duda de las flechas todos coinciden (al haber sido explicado el significado de las flechas) que se debería pinchar en el recuadro que indica la fecha, presentandosele efectivamente un calendario donde elegir al fecha que se desea cumplimentar.

Antes de agradecer nuevamente la ayuda en este prototipo se le consulta si se cree que este servicio mejoraría el actual obteniendose unanimemente que si y se le pide una valoración numérica de 1 a 5 del producto, obteniendose una media de 4 (valores entre 3 y 5).

Facultativos

Al facultativo, que ya está al corriente del proyecto que nos ocupa, se le presenta el primer prototipo de interfaz con las mismas aclaraciones previas que las hechas a las pacientes: plataforma web e idea de diario. Hecho esto se le muestra la interfaz.

Se le pide que seleccione al paciente que desea. Como se esperaba hace click en su recuadro y le aparece el siguiente paso. Se le consulta si le será útil esta comprobación, a lo que contesta que sí. Se le consulta si le parece relevante que aparezca la información del paciente en este paso, a lo que responde que si. Se le consulta que información querría tener en este paso: Edad, sexo, peso, diagnóstico, tipo de dolor y tratamiento actual. El facultativo confirma el paciente.

En esta interfaz se van ofreciendo en el recuadro inferior la información de los 3 picos de dolor segun desplaza el dedo por la pantalla incitado por el guía.
Al ver la información que solicitaba en el paso anterior le parece lógico que aparezca aquí y menos relevante en el paso anterior.

• Entiende la mecánica del cursor y la gráfica.
• Se le invita a cambiar el tratamiento al paciente.
• Clickea correctamente en el cuadro de las píldoras.
• Se le presenta la pantalla correspondiente, en la cual valora muy positivamente que se ofrezca la evolución en el tratamiento del paciente.
• Se le invita a introducir un nuevo tratamiento, lo cual hace correctamente.
• Se le invita a cambiar de paciente, lo cual realiza iguamente bien.

Se da por concluida la presentación del dispositivo y se le pide una valración de la utilidad del producto, siendo anotada una de las respuestas: “Muy sencillo y ágil, bien organizado, aunque un poco feo el color de la gráfica jeje. Seguid adelante chicos.”

Se le consulta si este sistema mejoraría el actual obteniéndose un sí rotundo. Consultado sobre la posibilidad de implantación del sistema tiene sus reservas al tener que tratarse no solo con facultativos sino con órganos gestores.

Evaluación del prototipo 2

Sujetos del test: 2 pacientes, 3 médicos.

Pacientes

Al igual que en la evaluación del prototipo 1, se les introduce a los pacientes en los puntos específicos de este prototipo y en los aspectos básicos, como la interfaz web y la métafora del diario, que entienden a la perfección. A continuación se les ofrece cartulinas superpuestas a un dispositivo smartphone (en este caso, un iPhone), para que puedan interactuar con el mismo.

De la cual se sacan los siguientes comentarios a tener en cuenta a la hora de depurar al interfaz:

• El usuario responde satisfactoriamente a la interacción con el sistema, entendiendo los pasos. No se queda bloqueado en ningún momento y el feedback del envío del dolor es correcto.
• El usuario envía correctamente su dolor sin ninguna instrucción ni guía adicional.

Se solicita finalmente que se piense que cree que debería hacer si desea cumplimentar el diario del día anterior ya que se le olvidó o no pudo hacerlo:

• El usuario es capaz de insertar este dolor con facilidad, indicando al sistema en los primeros pasos que el dolor no ha sido recientemente, a lo que el sistema le pide la fecha y hora aproximada del mismo.

Antes de agradecer nuevamente la ayuda en este prototipo se le consulta si se cree que este servicio mejoraría el actual obteniendose unanimemente que si y se le pide una valoración numérica de 1 a 5 del producto, obteniendose una media de 5, superior a la del prototipo 1.

Facultativos

De la misma forma que en el prototipo 1, al facultativo se le introduce en los aspectos básicos, aunque ya está familiarizado con los mismos debido al conocimiento del proyecto.

De su interacción con este prototipo podemos destacar aspectos similares a los del prototipo 1, con algunas diferencias.

• El especialista comprende con facilidad la interfaz a la hora de solicitar información al sistema. Selecciona correctamente al usuario y entiende bien la información presentada gráficamente por el sistema.
• La granularidad de la información presentada es adecuada.

Se da por concluida la presentación del dispositivo y se le pide una valoración de la utilidad del producto. En general, el usuario se muestra favorable de usar el sistema. 3 de los usuarios ya están familiarizados con smartphones y los utilizan para otras tareas, tanto de ocio como productividad, por lo que valoran la movilidad de la plataforma.

Se le consulta si este sistema mejoraría el actual obteniéndose un 5/5, al igual que con los usuarios. 2 de los usuarios se muestran interesados en saber más del proyecto y se ofrecen a probar la versión ‘beta’ cuando salga.

Evaluación del prototipo 3

Sujetos del test: 5 pacientes (3 de 60 – 75 años, 1 de 50, 1 de 30).

La recreación de dicho dispositivo la hicimos mediante el uso de un mando de un coche al que le añadimos pequeñas guías que simulaban el aspecto final del dispositivo móvil autónomo.

Cabe destacar que este prototipo sólo se evaluó en pacientes. Debido a su naturaleza, no podría ser utilizado por especialistas, es decir, que no podría ser utilizado para “extraer información”, sino para insertarla. El test lo realizamos con 5 participantes de forma individual. Cuatro de ellos eran personas de edad avanzada. De los cinco participantes, dos de ellos usan el diario de dolor de forma habitual.

Para este test nos centramos en las personas de edad más avanzada ya que son los que más dificultades pueden presentar a la hora de rellenar su diario de dolor de forma escrita o mediante aplicaciones web/smartphone.

En primer lugar el falicitador les expuso una situación de la vida cotidiana y como se debería utilizar el dispositivo. Para que sirve cada opción y como era su método de empleo. El participante más joven no tuvo ningún problema en comprender el manejo del dispositivo. El resto de participantes a pesar de experimentar alguna dificultad más, no se encontró ningún problema significativo. La mayor molestia fue el uso de la rueda lateral empleada para subir o bajar la graduación del dolor.

Al ser un dispositivo muy sencillo, el participante de edad avanzada que usa el diario de dolor tardó el mismo tiempo (aproximado) para entenderlo que el resto de participantes.
El participante más joven insistió también en cómo informar de los detalles del dolor, ya que al tener costumbre de rellenar su diario con detalles, tenía la sensación de que lo que hacía estaba incompleto, a pesar de la confirmación sonora.

Tras esto hicimos un simulacro. En dos ocasiones el guía pidió a los participantes amablemente que trataran de expresar continuamente lo que pensaban, pensar en voz alta, pero los resultados fueron similares a no hacerlo, ya que para los participantes de edad avanzada les costaba mucho realizar este ejercicio mental y no ganábamos ninguna información adicional.

En estos simulacros no detectamos ningún problema grave de usabilidad, sin contar la perdida de información por la sencillez del dispotisivo.
El observador también informó de que en dos de tres participantes de edad avanzada se detectó una pequeña vacilación en la transición de sufrir un dolor – registrar el dolor, al igual que en el momento de enviarlo. Con el último participante, al detectar tambien una ligera vacilación le preguntamos y nos respondió que no entendía que se pudiera hacer de una forma tan facil, La sencillez del dispositivo causaba incredulidad de su eficacia.
Esta vacilación podría provocar el desuso del dispositivo.

Por lo tanto, pese a ser algo sencillo especialmente diseñada para gente de edad avanzada, nos limita a la hora de rellenar información y la propia sencillez puede ser un problema al generar incredulidad, al menos inicialmente.

Conclusiones

Llegamos a las siguientes conclusiones:

• El prototipo 1 es desconcertante al principio, especialmente en la fase de la cuadrícula de dolor. El feedback es insuficiente. De continuar con este prototipo, debe ajustarse la parte de la cuadrícula o incluso sustituirla por un método similar al del dispositivo móvil. Debe haber un mejor feedback del envío del dolor y de sus características.
• El prototipo 2 es el más satisfactorio de los 3. Es capaz de mostrar la información e insertarla de forma sencilla, de forma móvil, en cualquier lugar. El usuario, tanto paciente como médico, aprecia la movilidad de la plataforma. Cabe destacar que en el caso del desarrollo del proyecto a nivel real, si se decidiese desarrollar este prototipo debería desarrollarse un front-end paralelo que permitiese al especialista ver la información en pantallas más grandes, no teniendo que ser necesariamente un ordenador personal.
• El prototipo 3 es fácil de utilizar, rayando en la simplicidad. Podría ser una buena alternativa para gente de avanzada edad, como proyecto alternativo, de forma paralela. Sin embargo, los pacientes no pueden introducir detalles ni medicación, algo que se sacrifica por esta misma simplicidad.

Continuación del proyecto

Vistos los resultados de las evaluaciones de los prototipos y de la flexibilidad de los mismos, hemos tomado uno de ellos para continuar el proyecto. Hemos considerado otros factores a la hora de tomar esta decisión, como su versatilidad, el éxito entre los usuarios y cuánto podemos sacar del prototipo para convertirlo en la continuación del proyecto. Para continuar el diseño de la interacción en la asignatura hemos elegido el prototipo 2, basado en una plataforma móvil para smartphones.

La técnica de evaluación a seguir será un test de usabilidad. Es importante destacar las variantes a seguir para los distintos prototipos. En el prototipo 1, basado en una plataforma web, se creará el interfaz con cartulina a modo de pantalla. En el prototipo 2, basado en una aplicación de dispositivo móvil, se creará la interfaz con cartulinas y se pondrán a tamaño real sobre un dispositivo móvil (iPhone). En el prototipo 3, basado en un dispositivo autónomo, se creará con cartón y otros materiales un modelo físico lo más preciso posible a lo diseñado para que el usuario interactúe con él de forma realista.

Detalles de la estrategia de evaluación:

Instrucciones que se darán a los participantes

• Se le ofrecerá al usuario los detalles del prototipo a evaluar:
• - Prototipo 1: se le indicará al usuario que el prototipo está pensado para una plataforma web, y que se imagine que está utilizando un navegador web.
• - Prototipo 2: se le indicará al usuario que el prototipo está orientado a un móvil o smartphone y se le enseñará el smartphone a usar, donde se irán poniendo las cartulinas a tamaño real de la interfaz sobre la pantalla del mismo.
• - Prototipo 3: se le ofrecerá al usuario el modelo del dispositivo y se le indicará que está pensado para llevar como elemento de llavero.

• El paciente recibirá las indicaciones de las tareas que deben realizar. En todos los prototipos a evaluar, la tarea principal del usuario será imaginarse un caso típico en su día a día donde debe anotar su último pico de dolor o su dolor en una cierta hora. Este último aspecto nos ayudará tambien a comprobar si el prototipo está bien diseñado en cuanto al momento de anotar el dolor (recordemos que el dispositivo de llavero está hecho para anotar el dolor reciente, la plataforma web para dolor en cualquier momento y la plataforma de dispositivo móvil para cualquier momento aunque con especial prioridad en dolores recientes).
• En el caso de especialistas, las indicaciones de tareas serán muy distintas. Se le indicará al especialista que se interese por los datos del diario de dolor de ciertos pacientes. A través de los dos primeros prototipos se observará la interacción del médico con la interfaz.

Reparto de roles para el test:

Para el reparto de roles se procederá a la siguiente asignación:

• Facilitador: Jorge Garrido.
• Guía del prototipo: José Arias.
• Observador: Antonio Bustamante

Si se realizasen varios tests en un mismo día, se intentaría turnar los roles.

Prioridades a observar

A continuación, detallamos, entre otras, los aspectos más importantes a la hora de tomar notas y observar al usuario:

• Si el usuario se desenvuelve correctamente en la interfaz.
• Aquellos puntos donde el usuario se bloquee o no entienda cómo continuar.
• Si el usuario es consciente del uso que se le da a cada prototipo (si usa el dispositivo de llavero para dolor reciente y la plataforma web para dolores en otros momentos, mencionado anteriormente), y en caso contrario, cuál es el concepto que el usuario tiene respecto al uso del mismo.
• Si el prototipo nº 3 (dispositivo de llavero) es de tamaño adecuado, así como sus botones y el feedback que recibe el usuario.
• Aspectos de claridad a la hora de anotar el dolor (versión de diálogo en prototipo nº 2, versión con cuadrícula en prototipo nº1).
• Tamaño correcto de los elementos gráficos en el prototipo nº 2, para dispositivos móviles. Ejemplo: es importante que el especialista vea bien la gráfica y sus detalles.
• Aspectos de usabilidad, como el anteriormente mencionado de la correcta visibilidad de los elementos.

Cabe destacar que, como se ha indicado anteriormente, aunque se tenga una estrategia global para los 3 dispositivos, se adaptará la evaluación de cada uno de los mismos a las circunstancias y características que lo rodean, para una evaluación a medida y precisa.

La presentación realizada sobre prototipos de diseño está disponible para descargar en PDF. Descargar aquí.

Supuestos:

• Llevar continuamente un diario de dolor de papel es pesado para el paciente.
• Hay pacientes que no tienen necesidad ni interés  en disponer de ordenadores o dispositivos móviles como smartphones donde rellenar el diario de dolor.
• El paciente quiere ante todo discreción a la hora de cumplimentar su diario de dolor.
• Las personas de edad avanzada no poseen conocimientos informáticos.

Afirmaciones:

El dispositivo móvil autónomo es cómodo, discreto y fácil de usar para todos los pacientes, especialmente para usuarios poco familiarizados con dispositivos informáticos.

Metáforas o analogías:

En este prototipo, además de las analogías presentes en el propio diario de dolor y el concepto que ello implica, existe la analogía del cuerpo humano, presente como dibujo en el dispositivo diseñado para este fin.

Conceptos paciente:

• Dispositivo a modo de llavero que muestra:
• Cuerpo humano con puntos de dolor.
• Graduación del dolor mediante rueda.
• Envío instantáneo del dolor sufrido.

Conceptos médico: (presentes en su interfaz para ver estos datos).

• Gráficas de dolor.
• Tablas de datos de dolor.
• Descripición de tratamiento.

Escenario:

Marcos Pérez es un anciano de 68 años con conocimientos nulos de informática que usa un dispositivo móvil autónomo para cumplimentar su diario de dolor. Desde hace 3 años rellenaba el diario de dolor manuscrito, pero al tener dificultades para escribir y recordar datos necesarios para cumplimentar el formulario, le pedía a su hijo que le ayudara a rellenarlo cuando éste se encontraba en la casa. Por este motivo no lo rellenaba todos los días. Marcos padece espondilosis (o enfermedad degenerativo del disco). Mientras daba un paseo por el parque cercano a su casa sufre un dolor en la espalda por lo que se sienta en un banco próximo. Cuando el dolor comienza a remitir, saca su dispositivo el cual se encuentra en su llavero, para registrar el dolor. Pulsa el botón para señalar la ubicación de dolor y la intensidad y lo envía, recibiendo una confirmación sonora y se envía la información mediante 3G a la base de datos. Tras ello continúa con su paseo matinal.

Una semana más tarde, acude a consulta para evaluar el método de tratamiento actual. El Dr. Vicente Ríos se conecta a su sistema gráfico y accede al paciente actual el cual ofrece una serie de fechas con sus respectivos dolores e intensidades. Mediante estos datos y las opiniones personales del paciente deciden si seguir con dicho tratamiento actual de fenitoína o probar uno nuevo como carbamazepina.

Prototipo de baja fidelidad: descargar en PDF.

Este prototipo es especialmente interesante para gente con trabajo a jornada completa o con actividades fuera del hogar, por la movilidad que ofrece al usuario a la hora de cumplimentar el diario de dolor.

El presente prototipo está pensado para un ordenador de sobremesa, para mostrarse en un navegador como plataforma web.

Supuestos:

• Existe una necesidad por parte de los usuarios de diarios de dolor y de sus facultativos de poder rellenar y analizar en tiempo real, de forma sencilla y a bajo coste material y temporal la información obtenida de los diarios de dolor.
• Los usuarios actuales asumen como acertado el modelo actual de los diarios y un diseño similar les ayudará a cumplimentarlo de forma más eficiente.
• Los médicos o encargados de extraer la información de los diarios requieren de un método rápido y claro para poder analizar los datos y actuar en consecuencia.

Afirmaciones:

• Se generará un diseño sencillo y evidente dadas las necesidades de ambos gurpos de usuarios que les resultará eficiente y de gran utilidad médica.

Metáforas o analogías:

• Como hemos dicho se toma como analogía el diseño actual de los diarios de dolor .

Conceptos paciente:

• Página del diario del dolor.
• Cuadros de información.
• Tipos/causas de dolor.

Conceptos médico:

• Gráficas de dolor.
• Tablas de datos de dolor.
• Descripición de tratamiento.

Escenario:

• Lucía Fernández García es una paciente de 57 años que lleva 5 años rellenando regularmente su diario de dolor de forma manual y lleva 2 meses aplicando el sistema informático desde su ordenador personal. Hoy se dispone a rellenar antes de acostarse su diario de dolor, recordando que especialmente tubo un fuerte dolor mientras volvía del trabajo. Así, se conecta a la aplicación web diariodedolor.com donde se autentifica con su nombre y contraseña. A continuación la aparece el comienzo de la página que habitualmente rellenaba, y un prompt que le pregunta si es la página de hoy la que quiere rellenar. Como es asi acepta y se encuentra con la imagen centrada en el cuadro de horas y hace click sobre el 7 a las 7 de la tarde, tras lo cual le aparece otro prompt con diferentes iconos para indicar que actividad estaba realizando en ese momento, pinchando en el coche que significa “de viaje”. A continuación avanza a la sección anatómica donde hace clic en la cabeza para indicar que fue en ese lugar donde sintió el dolor. Una vez recogida esa incidencia el sistema le pregunta si desea introducir algún otro dolor, a lo que contesta que no, y mediante otro prompt se le pregunta si ha tomado el Ibuprofeno recetado, a lo que contesta que sí. El sistema se despide cordialemnte.
• Al día siguiente acude a la cita que previamente tenía concertada con su doctor, el Dr. Vicente Ríos Afluentes, que al recibir a su paciente se conecta igualmente al sistema, autentificandose, seleccionando en el menú gráfico la opción de cargar datos de paciente e introduciendo el identificador de de esta, recibiendo un prompt con su fotografía, nombre y edad, confirmando la identidad del paciente requerido. A continuación se le ofrece la visión de la gráfica histórica de dolor de las ultimas 3 semanas donde identifica un pico el día anterior, posando el cursor sobre el pico recibe más información sobre ese dolor, contrastándolo con doña Lucía y evaluando de forma rápida el resto de la gráfica decide aumentarle la dosis de Ibuprofeno, para lo cual pincha en un icono de con dibujo de una pildora, donde le aparece el tratamiento actual, posibilidad de buscar anteriores y de modificar el actual, como asi hace y queda registrado. Ambos se despiden.

Prototipo de baja fidelidad: descargar en PDF.

Comprensión del espacio de problema

Como se comentó en anteriores fases del desarrollo del proyecto, queremos crear una plataforma que permita a los pacientes registrar sus dolores, incluyendo picos de dolor, las horas y días de los mismos, de manera informatizada, siendo fácil compartir estos datos con el especialista. A continuación se ofrecen afirmaciones y supuestos de partida generales. Más adelante se ofrecerán estos elementos para cada uno de los prototipos expuestos.

Supuestos de partida:

• Cumplimentar el diario de dolor de manera informatizada no sólo es más práctico, sino más ligero para el usuario.
• En cuanto al especialista, tanto en seguimiento del paciente como en labores de investigación, una plataforma de diario de dolor informática le es útil y sustituirá métodos más tradicionales, dándole estadísticas directas sobre su conjunto de pacientes.
• Este sistema mejorará la eficiencia del paciente con su diario de dolor y se incrementará el porcentaje de pacientes que lo completan de forma correcta y habitual.
• La comunidad científica se interesará por el proyecto, al tratarse de una innovación en el campo médico.
• Aquellas personas con diversidad funcional podrán comunicarse con el sistema e incluso los pacientes que antes no podían cumplimentar un diario de dolor en papel ahora sí lo podrán hacer.
• En este último aspecto, la plataforma ofrecerá el mismo front-end a todos los usuarios y será lo suficientemente flexible para poder ofrecer el servicio a personas de cualquier condición, física o mental.

Afirmaciones:

• El Diario de Dolor es el sistema ideal para la evaluación de pacientes con dolor, tanto en consulta como en proyectos de investigación.
• El especialista encuentra en el Diario de Dolor una herramienta indispensable para el desarrollo de su labor profesional.
• El paciente es un usuario recurrente del Diario de Dolor y cumplimentarlo no le supone esfuerzo alguno.

Problemas de usabilidad y experiencia de usuario

Este proyecto es especialmente interesante en cuanto a experiencia previa del usuario. Los diarios de dolor se usan desde hace años en consultas e investigaciones, pero hasta ahora han tenido un éxito muy limitado en los usuarios. Al tratarse de un método estrictamente tradicional, a mano, la experiencia del usuario ha sido primitiva. El usuario, generalmente, abandona su diario de dolor por el esfuerzo que le supone cumplimentarlo. Además, las personas con discapacidad que tienen dificultades para escribir a mano, se encuentran con un fuerte obstáculo a la hora de lograr sus objetivos.

Por tanto, nuestra propuesta de diseño tiene que cubrir de forma completa a los usuarios con y sin diversidad funcional. Esto se logrará adaptando los estilos de interacción a sus necesidades específicas. En la fase previa de gestión de la diversidad funcional, se cubrieron posibles casos de discapacidad y soluciones, que se aplicarán en nuestras propuestas, como el uso de atajos de teclado o la adaptación estructural de la plataforma para ser compatible con dispositivos como un Screen Reader.

En cuanto a la experiencia de usuario, éste ya tiene una imagen mental del diario de dolor como un ‘incordio’. Aunque el usuario conoce las ventajas de cumplimentarlo y es consciente de que puede mejorar su calidad de vida, no está suficientemente motivado. Para evitar esto, nuestros prototipos de diseño deben ser de uso rápido, con un aprendizaje nulo, es decir, que sean fáciles de usar y directos. Esto se logrará empleando distintos estilos de interacción que se centren en ofrecer comodidad al usuario, en su contexto. Uno de los métodos que se usarán, explicado más adelante en los prototipos, será el diálogo con el paciente.

Objetivo: reinventar el diario de dolor

Como parte de nuestro marco de análisis del problema, estamos considerando que estamos reinventando los diarios de dolor. Esto es especialmente importante en el proyecto porque es necesario trasladar ciertos elementos tradicionales a la nueva forma de hacer las tareas del usuario. Como se discutió en fases anteriores, nos enfocaremos en el uso y refinamiento de metáforas, siempre evitando que el usuario cree imágenes mentales incorrectas. En el caso del Diario de Dolor, el propio diario es una metáfora, y habrá que compatibilizar la imagen mental que el usuario ‘arrastra’ desde la versión manual a nuestra plataforma, pero sólo en sus aspectos positivos o necesarios. Éstos se complementarán con nuevas formas de desarrollar la misma tarea, tal como se explicaba en el punto anterior.

En el siguiente artículo se ofrecerán las características y aspectos del prototipo nº 1.

El Diario del Dolor que se proporciona a continuación es un formulario de muestra creado por un miembro del equipo hace unos meses para una web de pacientes con dolor. Estos formularios se ofrecen a los pacientes como recurso para una mejor visita preliminar a su especialista.

Se adjuntan dos PDF’s, un diario vacío y otro de demostración para que el paciente sepa cómo cumplimentarlo.

La gestión de la diversidad funcional en un proyecto como éste, del ámbito médico, es muy importante. Tenemos dos perfiles: especialista y paciente. Ambos pueden presentar características de diversidad funcional, especialmente en el caso del paciente, cuya propia condición de paciente con dolor responde a un entorno determinado: por ejemplo, muchos pacientes de dolor son también pacientes oncológicos.

Por tanto, ninguno de nuestros dos perfiles de usuarios está restringido en cuanto a diversidad funcional. Por esta misma razón, hemos decidido tratar las distintas discapacidades y características que se presentan en la diversidad funcional y, en cada una de ellas, explicar cómo se considerarán éstas en nuestro sistema para los dos perfiles.

Diversidad funcional

Dentro de la diversidad funcional sensorial, podemos tener fallos en la vista, el oído y el tacto. El tacto no representa mayor problema en nuestro caso, ya que se trata de un entorno virtual donde la interacción del usuario se realiza a través de un hardware determinado; será ese hardware el encargado de resolver los problemas sensoriales del tacto. El oído, aunque importante, tampoco presenta dificultades en nuestro proyecto, ya que la interacción del usuario con el sistema será gráfica, principalmente. El principal problema será con las personas con dificultades con la vista.

En esta última faceta, será importante utilizar una paleta de colores que ofrezca bastante contraste, con letras grandes (que además se puedan redimensionar sin problemas de pérdida de información). En el caso de una ceguera parcial o completa, debido al aspecto cerrado del sistema, esto se solucionaría con un sencillo esquema de reconocimiento de voz. Además, esta solución sería también válida para aquellas personas con problemas de movilidad o destreza. El sistema establecerá una conversación sencilla con el paciente e irá anotando los valores correspondientes. Una conversación posible sería la siguiente:

- Sistema: ¿Quiere anotar el dolor de hoy?
- Paciente: Sí.
- S: Por favor, indique del 0 al 10 la intensidad del dolor.
- P: Cinco.
- S: Se ha seleccionado una intensidad de 5 sobre 10. ¿Es correcto?
- P: Sí.
- S: Si el momento del dolor ha sido recientemente, diga ‘Ahora’. Si no, diga de 0 a 24 la hora aproximada del dolor.
- P: 15.
- S: Se ha seleccionado como hora del dolor las 3 de la tarde. ¿Es correcto?
- P: Sí.
- S: ¿Desea hacer alguna observación o comentario sobre este dolor?
- P: No.

En el caso de que el paciente indicara que el dolor no ha sido hoy, sino ayer u otro día, el sistema le pedirá paso a paso la fecha. Asimismo, el paciente podrá realizar comentarios que se grabarán como archivos de audio en el sistema. Debido al aspecto previsible del usuario y al determinismo del comportamiento de la conversación, el conjunto de valores posibles pronunciados por el usuario es cerrado y, por tanto, el reconocimiento de voz será preciso y de uso sencillo.

Respecto al perfil de usuario de especialistas, la información producida por el sistema de otros pacientes será textual y podrá ser leída fácilmente por un Screen Reader o software similar. Se ofrecerá además la estructura correctamente validada para facilitar la tarea de dicho software.

Finalmente, indicar que en cuanto a diversidad funcional cognitiva, no habrá problema alguno, debido a la sencillez del sistema y la iniciativa del mismo a tomar los datos del paciente y guiar al mismo a través de los distintos pasos. En cuanto a la diversidad funcional motriz, la solución es la comentada anteriormente, con reconocimiento de voz. Adicionalmente, algo muy fácil de implementar, se habilitarán atajos de teclado que el usuario pueda usar de forma sencilla para marcar los valores deseados y navegar por el sistema. Estos atajos también pueden ser usados por usuarios sin discapacidad.

La gestión de errores es de vital importancia para este proyecto, especialmente si consideramos el factor humano del mismo. Analizando en contexto con las fases anteriores del proyecto, se ha procedido a clasificar los posibles errores que los usuarios pueden cometer, y se ha clasificado estos entre críticos y no críticos. Se recuerda que los errores no críticos generalmente permiten seguir realizando el flujo de tareas del usuario en el sistema (si estos se manejan bien, en el aspecto técnico y de interfaz) y que los errores críticos no permiten seguir con el flujo de tareas, interrumpiendo la labor del usuario.

Caso ideal: que el número de fallos críticos sea 0, que el número de fallos no críticos sea lo suficientemente pequeño (y su gravedad sea leve), como para que el usuario apenas se de cuenta de los mismos.

Errores críticos:

• En interfaz web (en navegadores web de ordenadores personales): que el servidor esté saturado o que no responda a una llamada desde AJAX para modificar los datos del diario de dolor. Gestión del error: que el código Javascript tenga un timeout para cada petición y que intente varias veces acceder al servidor si las llamadas fallan. En última instancia, si no hubiera comunicación con el servidor, no quedaría otra opción que mostrar un mensaje de aviso al usuario.
• En interfaz de dispositivos móviles: en navegadores de dispositivos móviles, el mismo error que acaba de ser mencionado. Como aplicación del dispositivo, un error crítico en tiempo de ejecución (Java, Cocoa Touch, dependiendo de la plataforma). Gestión del error: en dispositivos de la marca Apple, donde la mayor parte de errores se producen por una mala gestión de memoria, hay que extremar la precaución con este aspecto y testearlo en distintos modelos. En otros dispositivos, donde se podría usar Java, la mayor parte de errores se producen porque la aplicación puede ser ejecutada en cientos de modelos distintos, y el fabricante de software no considera los distintos entornos posibles para el sistema. En este último caso, deberá ser testeado en todos los modelos posibles.

Como se puede apreciar, los errores críticos vienen producidos principalmente por razones de software, y rara vez por culpa del usuario. De hecho, una de nuestras labores como desarrolladores del sistema es protegerlo contra acciones erróneas del usuario.

A continuación, se enumeran los errores no críticos:

• El usuario trata de establecer un valor para su dolor que está fuera de los márgenes de la escala EVA (0 a 10). Gestión del error: la interfaz debe impedir que el usuario pueda intentar poner valores fuera de dicho rango, obligando a éste a anotar el dolor mediante un formulario que obligue a un conjunto restringido de opciones.  La escala de dolor debe ponerse como un dropdown box, o en una matriz de horas e intensidad de dolor, donde el usuario marque el valor deseado y éste aparezca de forma gráfica. [Este error puede ser tanto un fallo como un despiste].
• El usuario, al anotar el dolor para el día actual, ve los dolores que ha anotado en días previos y los compara con el nuevo. Los vuelve a pensar y cree que son erróneos. Cambia los valores previos. Al final de una etapa del diario, los valores han sido modificados varias veces, dando resultados imprecisos. Gestión del error: no permitir al usuario cambiar valores que ya han sido introducidos. [Este error es claramente un mistake]
• El usuario se equivoca al anotar el dolor en ese mismo momento, de ese día. Gestión del error: En este caso, sí se debe permitir que el usuario altere el valor. Es fácil que el usuario se equivoque de casilla.
• El usuario autoriza a un especialista equivocado a acceder a su diario de dolor. Gestión del error: permitir al usuario desautorizar a un especialista a acceder a sus datos.

La mayor parte de errores no críticos van a ser despistes instantáneos, y como regla general debemos permitir al usuario revertir los cambios que se han hecho en esa misma sesión de trabajo. Respecto a errores de captura, corremos el riesgo de que el usuario se acostumbre a poner siempre el mismo valor de dolor al ver los anteriores días. Ha de tratarse de ocultar parcial o totalmente los valores de días anteriores mientras se inserta el nuevo. Debido a la faceta del sistema de tomar la iniciativa para obtener los datos, los errores de pérdida de activación o asociativos van a ser raros o nulos. Respecto a los errores de modo, no sucederán, ya que el usuario, mientras rellena el diario de ese día, se mantendrá en una misma página en el navegador, alterándose los valores mediante AJAX y técnicas similares. Esto es especialmente importante para no modificar el contexto de uso del sistema, sobretodo en usuarios con poca experiencia en informática y no acostumbrados a procesos de este tipo.

Hemos decidido que la mejor forma de analizar las tareas es diseñar situaciones prototipo que se correspondan con lo observado en los usuarios. Estas situaciones prototipo son recreaciones de casos de uso, correspondientes a los perfiles de usuario descritos previamente en el proyecto.

Paciente

Escenario: Cualquier lugar de la vida cotidiana.

Descripción: El paciente siente dolor, creciente o sin previo aviso.

Task Flow:

1. El paciente detecta la sensación de dolor. Este dolor puede ser incremental a lo largo de un periodo de horas, o tratarse de un caso de dolor irruptivo (fuente externa) [El Médico Interactivo], es decir, un ataque de dolor insoportable y repentino.
2. El dolor es mitigado con la medicación asignada por el especialista.
3. Posteriormente, sobretodo a una hora regular a diario, el paciente recuerda la necesidad de cumplimentar el diario de dolor.
4. El paciente se dispone a cumplimentar el diario y anota los datos relevantes en el mismo, con las horas que recuerda, los picos de intensidad y características que recuerda sobre los mismos.
5. Esta última fase del flujo de tareas implica que el paciente evalúe el dolor de 0 a 10. Esto es especialmente importante porque el diario de dolor debe y deberá tener una pequeña escala recordatoria que centre al usuario en el margen de valores que debe anotar.

Este proceso se repite de forma diaria, generalmente, durante una etapa intermedia entre consultas. En la próxima consulta, el paciente llevará consigo el diario de dolor. Cabe destacar que este fujo de trabajo está intimamente centrado en el objetivo del usuario, que en este caso consiste en un convencimiento de que completar el diario mejorará su calidad de vida.

Posibles dificultades: es importante destacar que el perfil de paciente es de un dominio básico de la informática doméstica, por lo que tendremos que considerar una interfaz donde el sistema tome la iniciativa y el usuario no deba ‘investigar’ para poder realizar su cometido. El inicio de sesión del usuario en el sistema deberá intentar ser automático (con una cookie, o similar) para evitar pasos intermedios.

Requisitos de usabilidad: Respecto a personas con diversidad funcional, el sistema deberá contar con shortcuts, o atajos de teclado, que faciliten a una persona con dificultades de movilidad completar el diario con facilidad.

Conclusiones preliminares sobre el task-flow: el sistema deberá emular en lo máximo posible el actual mecanismo del paciente en cumplimentar su diario. Deberá ser rápido y cumplimentarlo no deberá tomar más tiempo ni esfuerzo que en su versión manual.

Especialista

Escenario: Consulta médica

Descripción: El especialista recibe el diario del dolor de mano del paciente y lo evalúa, junto con la descripción oral del paciente sobre los picos de dolor más intensos.

Task Flow:

1. El paciente llega a la consulta y tras las presentaciones, se le pregunta por su actual estado, su tolerancia con la medicación, la efectividad de la misma.
2. El especialista pregunta por su diario de dolor o el paciente toma la iniciativa de mostrárselo.
3. El especialista revisa el diario y comprueba picos intensos de dolor mientras el paciente le explica brevemente sus impresiones, las circunstancias de los dolores, las posturas y actividades que realizaba, inquietudes sobre la medicación, entre otros.
4. Tomando como guía los distintos datos ofrecidos por el paciente, el médico mantiene la dosis de medicación, la altera o cambia el analgésico.
5. El especialista recomienda al paciente que siga escribiendo su diario, citándole para la próxima consulta.

Posibles dificultades: el especialista tiene que revisar muchos días en el diario, lo que impide que obtenga una imagen clara global del dolor del paciente sólo a través del mismo. Esto se puede solucionar ofreciéndole ya las estadísticas del diario y los datos más importantes, detallados en la observación de usuarios.

Requisitos de usabilidad: Debe ser, asimismo, sencillo de uso y rápido, ya que el especialista no puede perder tiempo de consulta o revisión de diarios de dolor en detalles técnicos.

Conclusiones preliminares sobre el task-flow: el sistema deberá emular en lo máximo posible el actual mecanismo pero ofreciéndole estadísticas que le den una visión global de los diarios, y no los diarios uno a uno.

Al emplear las técnicas de observación de usuarios, se fueron refinando las preguntas y el esquema general para las entrevistas en contexto. Se tomaron notas y se utilizaron cuestionarios como información complementaria, uno para cada rol de usuario: pacientes y médicos. Finalmente, tras ser refinados de forma iterativa, obtuvimos una versión final de los mismos.

Descargar cuestionarios (PDF): Pacientes, Médicos.

Resultados

De la observación de usuarios, junto con nuestras notas y los cuestionarios, se han podido hallar importantes conclusiones que nos serán útiles en próximas fases del desarrollo del proyecto:

Pacientes

• Respecto al perfil del paciente, hablamos de una persona mayor de 40 años.
• El dolor más frecuente es el de tipo musculoesquelético, y dentro de esta categoría, el dolor lumbar.

Se insistió en aquellos pacientes que están siendo tratados por un especialista, ya que aquellos que no lo están no serán usuarios, en su gran mayoría, de un diario de dolor.

• El paciente que acude a un especialista en dolor acude de forma regular y tiene un seguimiento constante de su dolor. La gran mayoría completan diarios de dolor satisfactoriamente, siendo cómoda la representación en escala numérica de su dolor, y escribiendo en el diario de forma diaria durante una etapa intermedia entre consultas.
• Considera que el aspecto más importante del diario es el dato numérica de la intensidad del dolor, aunque es importante destacar que en casos más severos, el aspecto más importante serían los picos de dolor insoportable y su relación con la actividad en ese momento.
• Todos coinciden en que sería más cómodo cumplimentarlo de forma informática, aunque una pequeña minoría no utiliza el ordenador frecuentemente y tiene dispositivo móvil pero no lo usa para interactuar con aplicaciones web.

Especialistas

Actualización (1): un gran porcentaje de especialistas utilizan el diario de dolor sobretodo en estudios de investigación, siendo también revisado por el coordinador o coordinadora de la investigación. Esto se tendrá en cuenta en fases posteriores, considerando este posible uso por parte del especialista en dolor.

Actualización (2): debido al nivel sociocultural de muchos pacientes, algunos especialistas no recomiendan el diario de dolor. Por tanto, habrá que tener esto en cuenta para posteriores iteraciones en la observación de usuarios y el refinamiento del análisis de tareas.

• En cuanto al especialista, estaríamos hablando de un dominio constante de informática, en tareas sencillas, como herramienta de trabajo. Recomiendan el diario de dolor a sus pacientes y éstos anotan por días, sus picos de dolor, sin tratarse de datos a horas constantes. Hay una cierta flexibilidad en cuanto a lo que el paciente debe cumplimentar, sobretodo dependiendo de su patología.
• Algunos pacientes acuden a consulta sin diario de dolor o esbozado levemente, pero son capaces de describir oralmente las circunstancias de su dolor, las horas de mayor incidencia y las actividades relacionadas.
• Como en los pacientes, la información más relevante del diario varía según la patología del paciente, destacándose la intensidad del dolor y los picos de dolor intenso.
• El diario de dolor se suele usar para el seguimiento de dolor y aspectos como el ajuste de medicación. No se suele usar para diagnóstico.
• Es el especialista el que revisa el diario de dolor.
• Se coincide en un interés por un diario de dolor cumplimentado informáticamente.
• Respecto a la forma de recibir los resultados de los pacientes, no hay criterio conjunto y varía desde recibirlo por e-mail a analizarlo visitando una plataforma web.

Estamos muy satisfechos con los resultados obtenidos, ya que indican que habría destacado interés en un servicio de las características del proyecto, y porque se han refinado y corregido aspectos importantes de concepto sobre el proyecto. Con estos datos se procederá a realizar el análisis de tareas y a refinar detalles del enfoque del proyecto.

Habiendo construido la información del entorno del proyecto, como las especificaciones, sus requerimientos y los perfiles de usuario, previamente detallados en el artículo de Perfiles de Usuario, procedemos al análisis y observación de usuarios. Esta fase del proceso es especialmente importante para recabar información del usuario y analizarla.

A continuación se especifican las técnicas de observación que vamos a emplear:

Entrevistas en contexto

Se va a presentar el proyecto a un grupo reducido de usuarios. Esta presentación debe hacerse de forma individual, y al menos a 2 ó 3 usuarios de cada rol especificado en los Perfiles de Usuario. Debido al carácter privado de la interacción del usuario con el proyecto, se hará esta breve presentación de forma individual, y nunca en grupo, a cada uno de los sujetos. Cabe destacar que estos usuarios han sido identificados como actores principales en la etapa de creación de perfiles.

Las notas que se tomarán en la entrevista están intimamente relacionadas con las necesidades del diagnóstico del paciente. Se ofrecerá al paciente un ‘mockup’ básico de un diario de dolor impreso y las notas comprenderán los campos correspondientes al usuario.

En el caso del usuario Médico, las notas especificarán la siguiente información.:

• Qué información es más importante para el diagnóstico: los picos de dolor, la frecuencia, el tipo de dolor, entre otros.
• La granularidad de esta información necesaria para el diagnóstico. Es decir, si el especialista necesitará información concreta basada en horas y minutos o, por otro lado, necesitará una abstracción de esa información basada en estadísticas diarias o semanales generadas por el sistema.
• La organización de la información, en base a la eficiencia del médico. Este aspecto es especialmente importante porque el médico, al contrario del paciente, manejará grandes cantidades de información. El sistema le mostrará los datos de todos sus pacientes con diario de dolor. Es importante conocer la forma de organización que tiene este sector médico y, sobretodo, analizar cómo el software usado hasta ahora por el especialista le administra la información. En base a estos datos, se construirá un sistema de organización de información que se adapte a una estructura ya familiar para el especialista.

En el caso del usuario Paciente, las notas serán las siguientes:

• Se observará la forma de rellenar el formulario. Esta información nos servirá en pasos posteriores para extrapolar el comportamiento del usuario en un diario manual a un diario sistematizado.
• Se verán los siguientes datos sobre la forma de completar el formulario: el orden en el que se rellena, cuándo se rellena – en el momento del dolor o posteriormente -, la cantidad de información que rellena comúnmente, la frecuencia diaria de la misma, entre otros.
• Se analizará también la atención del usuario a los datos que debe rellenar. Esto servirá para evaluar la granularidad de la información que vamos a exigir al usuario, que afectará al margen de error de los datos.

Cabe destacar que el contenido de las notas y el formulario complementario usado para la entrevista en contexto se irá modelando y refinando de forma iterativa según se observe la reacción del usuario. Interrumpiremos frecuentemente al usuario para evaluar los detalles sobre ciertas acciones que realiza.

Mediante el modelo estructurado de roles de usuario, especificamos los perfiles de usuario de nuestro sistema. Los perfiles principales de nuestro sistema van a ser dos:

Perfil de usuario 1: Paciente

Descripción: el paciente goza de conocimiento básico o nulo en informática doméstica. No suele navegar por Internet y utiliza el ordenador sólo cuando es estrictamente necesario, como herramienta y no como entretenimiento. En la gran mayoría de los casos, el paciente está en la edad de adulto mayor.

Competencia: Está acostumbrado a rellenar un diario de dolor, motivo de este proyecto, pero de forma manual, a papel y lápiz. Conoce la mecánica y el procedimiento del proyecto, así como los motivos para realizarlo. Es consciente de la importancia de usar el sistema y ha sido aconsejado por su especialista previamente a que lo utilice. Es decir, una figura profesional de confianza le ha aconsejado usar el sistema y el paciente conoce las ventajas del mismo. Está motivado.

Interacción: la frecuencia de uso será diaria, por lo menos dos veces al día. La frecuencia de aparición de este rol es la anteriormente mencionada, ya que este rol será el principal usuario del producto. La interacción del usuario con el sistema es continua, ya que así se lo ha especificado el especialista. La concentración es instantánea, ya que el tiempo de uso del sistema por sesión no superará los 5 minutos. La complejidad de las interacciones va a basarse en que el usuario usará la totalidad de las funciones del sistema; sin embargo, estas funciones están directamente relacionadas con su patología y es totalmente consciente de las mismas. Las acciones son totalmente predecibles, ya que el sistema sólo tiene una finalidad principal: registrar la información diaria sobre el dolor del paciente. Al ser tan predecible, el sistema es el que toma la iniciativa debido a la simplicidad de las operaciones en el mismo.

Información: la naturaleza de la información administrada por el usuario proviene del mismo y es relativamente simple. Esta información ha sido recomendada por su médico especialista. La cantidad de información es pequeña, debido a que el usuario sólo insertará información 1 ó 2 veces diarias y la mayor parte de la información la asumirá el sistema.

Criterios de usabilidad: el sistema tiene que estar adaptado al rol de usuario, poco experimentado en el manejo informático, y debe concentrarse en la efectividad de su uso. Es eficiente debido a la simplicidad de la interacción entre el sistema y el usuario, así como su frecuencia. Es fácil de recordar debido a su frecuencia diaria. La utilidad es máxima y es una de las motivaciones del usuario, ya que su principal objetivo la mejora de su calidad de vida.

Soporte funcional: el sistema debe almacenar la información enviada por el usuario en un servidor externo para evitar la pérdida de datos y asegurar que el especialista pueda acceder a los mismos para realizar el diagnóstico.

Perfil de usuario 2: Médico

Descripción: el médico goza de conocimiento básico o medio de informática doméstica. Suele navegar por Internet y utiliza el ordenador como herramienta para analizar diagnósticos.

Competencia: Es consciente de la importancia de usar el sistema y conoce la mecánica de los datos a insertar, así como de las necesidades del paciente. Asimismo, es él el que toma la iniciativa hacia el paciente de utilizar el sistema. El producto es, en este rol, su herramienta de diagnóstico.

Interacción: la frecuencia de uso será constante, ya que deberá comprobar los datos de sus múltiples pacientes. La frecuencia de aparición de este rol será ligeramente menor a la del paciente pero igualmente importante. La concentración es constante ya que el usuario conoce previamente la mecánica del sistema. La complejidad de las interacciones va a basarse en que el usuario usará la totalidad de las funciones del sistema. Las acciones son totalmente predecibles, ya que el sistema sólo tiene una finalidad principal en este rol: mostrar la información de los pacientes que han insertado sus datos sobre dolor. Al ser tan predecible, el sistema es el que toma la iniciativa debido a la simplicidad de las operaciones en el mismo.

Información: la naturaleza de la información administrada por el usuario proviene de sus pacientes y es relativamente sencilla. Además, es el propio sistema el que hace las estadísticas de interés al especialista. La cantidad de información es relativamente grande, debido a que se trata de la información de todos sus pacientes. Al ser informativo y al necesitar el especialista inferir los datos, requerirán una organización adecuada para su aprovechamiento y diagnóstico.

Criterios de usabilidad: el sistema tiene que estar adaptado al rol de usuario, experimentado en el manejo informático a nivel medio, y debe concentrarse en la efectividad de su uso, especialmente considerando que debe de hacer diagnósticos con el mismo. Es eficiente debido a la simplicidad de la interacción entre el sistema y el usuario, así como su frecuencia. Es fácil de recordar debido a su frecuencia constante. La utilidad es máxima y es una herramienta esencial para el especialista.

Soporte funcional: el sistema debe mostrar la información de los pacientes al médico y debe soportar múltiples consultas a una base de datos, por lo que deberá ser seguro y eficaz en las mismas.

Contexto

El dolor es una importante parte de la sociedad, especialmente en el ámbito médico. Campo de la medicina abandonado durante décadas, desconocido y sujeto a superstición y mito urbano, se ha convertido en la primera causa de consulta médica a nivel mundial. Actualmente, hay un auge en la investigación y tratamiento del dolor, que se caracteriza por una explosión de nuevos medios y terapias.

Innovación

Sin embargo, uno de los aspectos más importantes para el diagnóstico del paciente es la observación de los dolores del mismo. Muchos médicos encargan a sus pacientes llevar un pequeño diario de dolor, donde apuntan sus momentos de dolor más intenso, sus actividades y circunstancias, para posterior análisis, con el fin de averiguar su origen y patología. Estos diarios son manuales. No existe un método online y eficaz para sistematizar esta tarea y facilitar el diagnóstico al médico.

Target

El target al que se dirige el proyecto está dividido en dos sectores claramente diferenciados:

• Pacientes del área de dolor, en sus distintas patologías, que requieren un diario de dolor constante y actualizado.
• Médicos especializados en investigación y terapia del dolor, interesados en las estadísticas de dolor, para diagnóstico en consulta del paciente.

Objetivos

• Crear un prototipo para una aplicación de ‘Diario de Dolor’, especialmente orientada a dispositivos móviles, con el fin de que el paciente pueda registrar con facilidad y flexibilidad sus picos de dolor y las circunstancias de los mismos.
• El proyecto se basará en los principios de Interacción Persona – Ordenador estudiados en clase durante el semestre.
• El prototipo consistirá en una interfaz orientada a pacientes y a especialistas. Los pacientes podrán registrar sus picos de dolor y escribir comentarios sobre los mismos, que arrojen luz a las circunstancias que rodean a la patología. Los especialistas, a través de un código que identifica al paciente de forma anónima, podrán ver las estadísticas y comentarios sobre el dolor de sus pacientes, para hacer un diagnóstico adecuado.

La web del proyecto de grupo ha sido creada. Próximamente se publicará aquí una descripción detallada del proyecto, con contexto y objetivos.