Prueba de usabilidad al módulo del terapeuta en un ambiente virtual para la rehabilitación motriz pos-ictus del miembro superior

Usability testing for therapist module on virtual environment for poststroke motor rehabilitation ofupper limb

Esta obra está bajo una Licencia Creative Commons Atribución-NoComercial-CompartirIgual 2.5 Argentina.

Departamento de Ingeniería en Computación; Universidad del Istmo.

La rehabilitación pos-ictus busca ayudar al paciente a recuperar habilidades que perdió o vio disminuidas, a ser más independiente, y en general, a tener la mejor calidad de vida posible. El proceso de rehabilitación se aborda desde diferentes enfoques terapéuticos, ya sea con ejercicios intensivos de motricidad en el caso de la fisioterapia, o con actividades de la vida diaria (AVD) como en la terapia ocupacional (TO). Al respecto, una alternativa tecnológica a la que se ha recurrido es la Realidad Virtual (RV), la cual presume ser una oportunidad para integrar terapias que motiven al paciente a realizar las tareas virtuales (Bermudez i Badia, Fluet, Llorens, y Deutsch, 2016). No obstante, prevalece la interrogante de cómo garantizar que estas intervenciones de rehabilitación virtual satisfagan las necesidades específicas de los usuarios, siendo la incorporación de la perspectiva del usuario en el diseño, la identificación y atención a los problemas de usabilidad, dos de las líneas de estudio, que buscan hacer estos entornos virtuales “más útiles” como herramientas de apoyo en programas de rehabilitación (Aguilar, Pacheco, Acevedo, Toledo, y Nieva, 2022).

En lo que concierne a la perspectiva del usuario, un marco de trabajo usado en el desarrollo de estos ambientes virtuales ha sido el Diseño Centrado en el Usuario (DCU), el cual permite su aplicación en un gran abanico de contextos, siempre y cuando se tenga en claro quién toma el rol del usuario final, que enel contexto particular de la rehabilitación virtual puede ser el paciente y/o el terapeuta. Sobre este último enfoque, estudios como los de Korn y Tietz (2017), señalan la necesidad de que el terapeuta elija la combinación óptima de movimientos, de modo que la inmersión en la tarea virtual, no sea una distracción, mientras en Hung, Huang, Chen, y Chu (2016), señalan la preocupación que existe por parte de los pacientes sobre la correcta realización de sus ejercicios, lo cual otorga gran relevancia a las sugerencias y correcciones que el terapeuta realiza durante la ejecución de los mismos.

En lo respecta a la aceptación del producto por parte del usuario final, se ha recurrido a tanto a encuestas y cuestionarios (Sáenz, García, y Méndez, 2015), como al apego a reglas y estilos de diseño dado por expertos en el área (Shiratuddin et al., 2017). En este punto, investigaciones como la presentada en este artículo se centran en explorar alternativas de evaluación y por consiguiente variaciones en el proceso metodológico de su aplicación, que permitan identificar problemas de usabilidad, tal es el caso de la aplicación del protocolo Pensando en Voz Alta (Thinking Aloud).

En particular, el protocolo Pensando en Voz Alta ha sido un instrumento usado ampliamente en el estudio del proceso cognitivo de las personas (Jääskeläinen, 2010), que evalúa mediante la recolección de datos cualitativos (estados de ánimo mientras se realiza la prueba, gustos/disgustos, entre otros) o cuantitativos (cantidad de problemas identificados, tiempo ejercido para la realización de las tareas, número de tareas completadas, entre otros), el nivel de éxito que se obtiene en la interacción con el objeto de estudio, que para los fines de esta investigación lo representa el software presentado en (Aguilar et al., 2022), el cual es un ambiente virtual para la rehabilitación motriz pos-ictus, diseñado bajo la filosofía del DCU, y destinado a mejorar la movilidad de la articulación del codo a través de actividades virtuales relacionadas con comer, el aseo personal y vestirse.

La prueba Pensando en Voz Alta implica la intervención de dos personajes cruciales: el usuario, quienrealizará una serie de tareas previamente definidas; y el experimentador o moderador quien realizará intervenciones durante el desarrollo de la estrategia para fomentar la recolección de datos (Lauesen, 2005).

El protocolo Pensando en Voz Alta es considerado un método de introspección, debido a que como se menciona en Van Someren, Barnard, y Sandberg (1994) citado en Ávila, Bianchetti, y González (2017), se puede “…observar los eventos que suceden en el subconsciente de una persona a partir de lo que puede observarse en los eventos que realiza en el mundo externo”. Esto quiere decir que no se espera que el usuario narre lo que hace sino propiamente por qué lo hace y evitar en lo posible grandes periodosde silencio, lo que puede provocar pérdida de datos valiosos dentro del proceso cognitivo. A su vez, este protocolo ofrece la ventaja de entender la toma de decisión, de resolución de problemas y de pensamiento crítico del usuario (Ávilaet al., 2017). Según Krahmer y Ummelen (2004), el protocolo Pensando en Voz Alta se concentra en tres objetivos principales: i) para encontrar evidencia de modelos y/o teorías del proceso cognitivo, ii) para descubrir y comprender patrones generales de comportamiento por parte de los usuarios en la interacción con documentos o aplicaciones con el fin de crearse bases científicas que representen reglas de diseño, y finalmente iii) para evaluar documentos o aplicaciones conel propósito de especificar problemas trascendentales y revisarlos.

En este sentido, en Boren y Ramey (2000) se presenta un estudio que destaca el tercer objetivo, concerniente a las pruebas de usabilidad, siendo el principal foco de atención el analizar las interacciones que el usuario realiza con el software, es decir, el usuario no se lleva toda la primicia, ya que el objeto de interés es el software y lo bien que está implementado para cumplir con sus funciones, por lo que el moderador encuentra una participación activa, dirigida y estratégicamente intervenida para identificar todos los aspectos que puedan impedir el éxito de la implantación de un determinado software.

En este sentido, en la variante del protocolo Pensando en Voz Alta conocida como Intervención Activa (Dumas y Redish, 1999; Olmsted-Hawala, Murphy, Hawala, y Ashenfelter, 2010), el moderador prueba obtener o concebir el modelo mental o propiamente el proceso de pensamiento del usuario para saber cómo ellos realizan una determinada actividad a través de la intervención activa (narrativa, conversación, impresiones) dentro de la prueba. Demostrando que la técnica de coaching mejora el desempeño de los usuarios e incrementa su satisfacción respecto a las otras técnicas.

Lo anterior permite confirmar la reflexión de Nørgaard y Hornbæk (2006) al mencionar que el moderador previo a la aplicación de la prueba ya puede intuir los tipos de problemas que pueden estar presentes durante la realización de la prueba y con ello, conducir al usuario hacia la confirmación de sus sospechas, por lo que aprueba la intervención oportuna y conducida del moderador.

Los argumentos expuestos sobre el protocolo Pensando en Voz Alta han dado paso a un interés por describir el procedimiento experimental que implica el uso del protocolo en su modalidad de Intervención Activa, siguiendo la propuesta de aplicación y reporte de resultados dada por Lauesen (2005), con la finalidad de obtener al cierre del protocolo una lista de problemas de usabilidad del objeto de estudio (ambiente virtual), clasificados por gravedad y prioridad de solución, ofreciendo como aportación una descripción detallada de los resultados obtenidos, así como las sugerencias inmediatas que darán solución a los problemas de usabilidad con la intención de proceder a realizar las mejoras del software, dentro del marco del DCU bajo el cual se desarrolló el ambiente virtual bajo estudio.

Es importante señalar, que al momento no se ha identificado trabajos relacionados en el campo de la rehabilitación virtual que haga uso del protocolo Pensando en Voz Alta como alternativa para medir eidentificar aspectos a mejorar en la usabilidad de estos entornos virtuales.

El objeto de estudio, lo constituye un sistema de RV de tipo no inmersivo, que emplea como periférico de interacción al sensor Kinect y como software de desarrollo al motor gráfico Unity. El diseño del software sigue la filosofía del DCU bajo el rol del terapeuta como usuario final, teniendo como propósitos ser una herramienta de apoyo que permita administrar (Figura 1), configurar (Figura 2) y realizar (Figura 3) las sesiones de terapia, teniendo como fundamento la retroalimentación visual como medio para motivar al paciente a realizar tareas virtuales relacionadas a cubrir la necesidad de ocuparse de sí mismo. Al tratarse de un software asistido (por el terapeuta), el ambiente virtual se conforma de dos módulos, el primero asociado a las tareas de administración y configuración denominado módulo del terapeuta, y el segundo relacionado con la realización de las tareas virtuales llamado módulo del paciente.

Figura 1.
Registro de paciente
(Acevedo, 2018)

Figura 2
Configuración de la terapia
(Acevedo, 2018)

Figura 3.
Tarea de cortar carne en escenario Comedor
(Acevedo, 2018)

Respecto a la evaluación del software bajo mención, ésta la han concretado al evaluar el módulo del paciente (Aguilar et al., 2022), con participantes con y sin diagnóstico de ictus, mediante pruebas de usabilidad tipo testing a través de un prueba SUS (Bangor, Kortum, y Miller, 2008), un cuestionario de estado de flujo (Yoshida et al., 2013) y entrevistas para valorar si su interpretación del contenido e interacción con el ambiente virtual fueron de utilidad y correcta comprensión, así como para conocer sus opiniones en la efectividad de la terapia con apoyo de la tecnología de RV. Sin embargo, este primer acercamiento no ha permitido indagar la usabilidad del software desde la perspectiva del terapeuta, quienfunge como usuario final y para quien fue diseñado el ambiente virtual. Así, en este trabajo se considera la aplicación de la técnica Pensando en Voz Alta bajo la modalidad de Intervención Activa, para la descripción de los problemas de usabilidad detectados, con el objetivo de contar con un mecanismo que permita valorar las opiniones de usuarios potenciales, terapeutas, quienes no participaron en la formulación de los requerimientos del software, pero se ajustan al perfil del usuario final que pudiese emplear este entorno.

De forma particular, según (Acevedo, 2018) el entorno de RV bajo estudio cumple con los siguientes requisitos funcionales:

· Acceso como administrador del sistema por el especialista a través de una clave.

· Registro de pacientes recabando datos generales y valoración con base en las escalas de Barthel,Ashworth y Daniels (véase Figura 1).

· Búsqueda de paciente.

· Revisión del historial de terapias de cada paciente.

· Eliminar el registro e histórico de pacientes.

· Acceso a sesiones específicas por paciente a través de su clave de identificación.

· Diseño de escenas de AVD implementadas mediante el uso del sensor Kinect para la identificacióndel movimiento de flexión del codo.

· El sistema tiene la capacidad de medir el ángulo de flexión del paciente al momento en que éste se encuentre realizando el ejercicio asignado, de tal manera que se puede verificar con exactitud si se está logrando el ángulo de flexión indicado por el especialista en la configuración previa al inicio de la sesión (véase Figura 2), independientemente de que el codo lesionado sea el derecho o elizquierdo.

· El sistema retroalimenta a cada instante a través de paneles informativos sobre el ángulo de flexión logrado por el paciente al realizar la tarea virtual, un cronómetro en cuenta regresiva y el número derepeticiones realizadas (véase Figura 3).

· Genera un informe en formato Excel sobre los resultados de la sesión realizada con el resumen deestas variables

Para efectuar el protocolo Pensando en Voz Alta, se requiere como entrada principal usuarios finales o potenciales que se ajusten al perfil del terapeuta que participó en la formulación de software, así como lastareas de usabilidad que definirán las actividades que los participantes intentarán realizar durante su exploración en el ambiente virtual, obteniéndose como resultado una lista de problemas de usabilidad clasificados por su gravidez. Dicho protocolo se describe claramente en (Lauesen, 2005) y se expresa en formato de pseudocódigo en (Toledo, Rosales, Hernandez, y Arellano, 2015). Para ello, se estableció contacto con terapeutas que se ajustaran al perfil de usuario con título profesional y/o especialidad en Medicina Física y/o Rehabilitación, con un mínimo de 2 años de experiencia, y sin experiencia en el uso de un software similar. Previo al comienzo de la prueba, se procedió a entrevistar individualmente a cada terapeuta (Usuario potencial) a través de las interrogantes plasmadas en la Tabla 1, con la intención de validar su familiaridad con los conceptos propios del contexto de uso del software y por tanto con la configuración de la terapia.

Tabla 1
Resultado de encuesta inicial a participantes

Autoría propia.

Posteriormente, se explicó la mecánica de la prueba a cada uno de los participantes, en la cual tenían frente de si (por primera vez) a la interfaz de usuario del ambiente virtual a evaluar, acompañados del facilitador de la prueba quien fungió como el paciente con la intención de hacer una demostración a cada participante sobre el tipo de retroalimentación visual que la interfaz ofrecía con ayuda del sensor Kinect, para esto, se le pidió autorización a cada especialista de grabar la sesión de prueba, y así recabar con mayor detalle algunos problemas de usabilidad que no fuesen identificados de inmediato. En la Tabla 2 se describen las tareas de usabilidad aplicadas, que cubren en su totalidad las funcionalidades ofrecidas para el módulo del terapeuta.

Tabla 2
Tareas de usabilidad

Autoría propia.

Se procedió a aplicar la prueba Pensando en Voz Alta, con los tres especialistas en el área y obtener retroalimentación inmediata sobre las expectativas en cuanto al diseño de la interfaz de usuario y el nivel de acoplamiento de su modelo mental respecto al programador del software. De acuerdo con (Nielsen, 1993), este número de usuarios es suficiente para obtener tantos problemas de usabilidad como estos existan, debido a que al aumentar el número de usuarios solo se obtendría la identificación de los mismosproblemas y el coste de ejecución se elevaría innecesariamente.

Tal como indica Nielsen (1993; 2012) esta prueba es un proceso muy „barato‟ para obtener información pese a su extenuante ejercicio de recopilación y desglose de los resultados, no obstante, dichos resultados pueden ser útiles para analizar estadísticamente el grado de éxito de la interfaz en términos del número de problemas de usabilidad identificados, su gravidez, y además de ello, identificar nuevos requerimientos que pudiesen ayudar a una interacción exitosa con la herramienta.

Para ello, se procedió a realizar una estimación del plan de prueba (véase Tabla 3 y 4), obteniéndose un costo de ejecución de 10hrs. 54 min para la aplicación de la prueba de usabilidad a los tres terapeutas, que, si bien resulta un costo alto de tiempo, el impacto económico requerido es prácticamente nulo y los resultados pueden ser muy útiles para establecer un prototipo cada vez más agradable y satisfactorio.

Tabla 3.
Costo de ejecución por usuario

Autoría propia

Tabla 4
Costo de ejecución del plan de pruebas

Autoría propia

Como resultado de la aplicación y recolección de respuestas por parte de los usuarios, se identificaron 19 problemas de usabilidad, mostrados en la Tabla 5.

Tabla 5.
Problemas de usabilidad identificados.

Una vez identificados los problemas, se procedió a realizar un análisis a los videos y notas de las pruebas que ofrecieran criterios para ser clasificados por el evaluador (facilitador de la prueba) como: problema menor (PM), problema medio (PMED), pérdida de funcionalidad (PF), fallo en la tarea (FT) y molestia (M), tal como se solicita y reporta en Lauesen (2005) (véase Tabla 6).

Table 6
Clasificación de los problemas de usabilidad, formato sugerido en Lauesen (2005).

Autoría propia.

En la Tabla 7 se presenta la relación entre las tareas y los problemas de usabilidad detectados. Durante la experiencia de la recolección de los problemas de usabilidad destacó la identificación del problema P2, que se relacionó con las tareas T7 y T8. Mediante estas tareas, los especialistas configuraban las características de la terapia, tales como, especificar el ángulo de flexión que el paciente debía realizar en cada repetición. Sin embargo, los terapeutas señalaron que el sistema no ofrecía ningún tipo de instrucción de cómo se debía realizar correctamente el ejercicio, es decir, el sistema necesitaba retroalimentar feedback al paciente sobre los movimientos (de hombro, de codo, de muñeca, entre otros) que debe involucrar para conseguir una repetición, ya que algunas tareas como el cepillado de dientes lo requieren.

Tabla 7.
Relación entre las tareas de usabilidad y los problemas identificados

Autoría propia.

Por su parte, el problema P3, fue detectado durante la ejecución de la tarea T3, los terapeutas indicaron que a nivel semántico, el concepto de “eliminar un registro” no es correcto, ya que ellos como terapeutas no deben perder ningún registro sobre el seguimiento de algún paciente dado que en cualquier momentopueden regresar con ellos por alguna otra lesión y requerirían conocer sus antecedentes médicos, por lo que la expresión semántica viable sería, “dar de alta al paciente” indicando con ello que aun cuando a nivel del sistema se hubiese terminado el proceso de terapia, los registros sobre los mismos deberían seguir existiendo en el histórico pero señalando de alguna manera que el paciente ha sido dado de alta curado y por tanto no requiere terapia. Este hecho involucró también al problema P4, a lo cual los terapeutas sugirieron considerar dos apartados dentro del sistema, uno que involucre a los pacientes dados de alta y otro con los pacientes que se encuentran recibiendo terapia.

En el caso del problema P5, surgió a raíz de que los usuarios no pudieron consultar la información de unpaciente debido a que dicha búsqueda se realizaba a partir de un código de identificación, el cual ellos tenían que buscar con apoyo de la barra de desplazamiento de la pantalla, para que una vez identificadoel código lo anexarán en la pantalla de inicio de sesión para ingresar a la información del paciente, por loque sugirieron realizar una búsqueda más efectiva por nombre y apellido del paciente que buscando unoa uno. Este problema no fue detectado de inmediato, hasta el momento de la participación oportuna del facilitador gracias a su Intervención Activa, quién les ofreció el escenario en el que se tuviesen 1000 pacientes registrados, hecho que los llevó a rectificar sobre la necesidad de mejorar el proceso de búsqueda.

Respecto al problema P7, este se activó durante la ejecución de la tarea T4, ya que los terapeutas requerían configurar la prueba del paciente ingresando con el código de éste último en el inicio de sesión mientras ellos lo buscaban dentro de su apartado como terapeutas, por lo que no se imaginaron que tenían que realizar una búsqueda por código de paciente, salir de su sesión y acceder a la sesión del paciente con dicha clave para realizar la respectiva configuración, lo que al final terminó clasificado como un fallo en la tarea, ya que esa actividad no pudo ser realizada por ninguno de los terapeutas.

Particularmente el problema P14, ofreció una impresión más allá de la funcionalidad del software, ya que estaba vinculada hacia el diseño accesible y basado en el usuario, es decir, el software fue diseñado parapersonas que no tuviera problemas visuales, hecho que representó un error, ya que el simple formato de letras y colores elegidos para el encabezado de las pantallas fue suficiente para ser detectado como un problema de usabilidad, ya que la Usuario 1 (U1) durante la tarea T4 se percató de su dificultad para leer los títulos de las pantallas que se encontraban en un fondo blanco y delineadas en negro, el terapeuta usa lentes y su problema visual combinado con la elección del formato seleccionado para el texto le impidió corroborar el sitio en el que se encontraba en un determinada pantalla (es decir, no estaba segurode si se encontraba en la sesión del paciente porque el texto que se lo decía no era legible).

Esto evidentemente no se trata del modelo mental del usuario final, sino de un característico propio como perfil de usuario que no fue valorado durante el diseño del entorno y que para futuras mejoras debe ser tomadoen cuenta.

A partir de los resultados presentados en la Tabla 6, se realizó un análisis estadístico mediante gráficos de barras. En el Figura 4 se encuentra representado el número de problemas de usabilidad identificados por los tres usuarios participantes junto con la frecuencia por tipo de problema en el que se clasificó; pudiendo notarse que el Usuario 3 (U3) fue el que identificó un mayor número de problemas de usabilidad con un total de 14, considerando que el total de los problemas detectados fueron 19, por lo que la variación de problemas de usabilidad detectados por U3 respecto a los otros dos usuarios solo dependen de los cinco problemas restantes, coincidiendo con el señalamiento de Nielsen (1993) sobre el número de usuarios necesarios para identificar tantos problemas de usabilidad como estos existan.

Dentro del mismo gráfico se puede observar que la mayoría de los problemas detectados fueron clasificados como problema menor (PM), lo que indica que los usuarios pudieron concluir con la tarea deusabilidad asociada, pero en un tiempo mayor al esperado, señalando detalles de diseño que pueden corregirse en breve tiempo.

Figura 4
Frecuencia de problemas de usabilidad detectados por usuario.
Autoría propia

Por su parte, en la Figura 5 se muestra la frecuencia de clasificación global dada a cada problema de usabilidad respecto a la moda de la clasificación en la que recayó una vez identificada por los diferentes usuarios finales, es decir, si un mismo problema de usabilidad fue identificado por los tres usuarios, la clasificación más frecuente es la que se consideró en la clasificación global ubicada en la última columna a la derecha de la Tabla 6. Este hecho confirma la presencia de un mayor número de problemas de usabilidad con clasificación Problema Menor (PM), lo cual también es visible en el Figura 4, de igual forma, se reafirma la presencia de un problema clasificado como pérdida de funcionalidad (PF) y otro como fallo en la tarea (FT), los cuales corresponden a los problemas P3 y P7 respectivamente, y que requieren especial atención y pronta corrección para obtener una mejor versión del software.

En la Figura 6 se representa la frecuencia de usuarios que pudieron detectar cada uno de los problemas de usabilidad, sobresaliendo entre ellos los problemas P2, P3, P4, P7, P9, y P18, los cuales fueron identificados por los tres usuarios y por ende serán problemas a priorizar, al ser reconocidos por su gravidez y/o su frecuencia de detección entre los usuarios.

Figura 5.
Frecuencia de problemas de usabilidaCdlarseifsicpaecciótno galosbualclasificación global.
Autoría propia.

Figura 6
Problemas de usabilidad Frecuencia de usuarios que detectaron cada problema de usabilidad
Autoría propia.

De la misma forma, en la Figura 7 se representa la frecuencia de problemas detectados por cada tarea, trascendiendo las tareas T1, T4, y T9 como las más informativas, con un total de cuatro problema de usabilidad cada una, lo que en conjunto representa más del 50% del total de los problemas de usabilidad detectados, lo que se corrobora en el despliegue de la Figura 8, marcando un precedente de los escenarios de evaluación que deben ser revisados con mayor detenimiento para evitar futuros problemas de usabilidad.

Por tanto, y como propuesta de solución para el conjunto de problemas de usabilidad detectados, en la Tabla 8, se presenta, el orden de prioridad bajo el cual se deberán atenderse los problemas y la solución a nivel de diseño de interfaz que las resolverá. Tomando en consideración que la mayoría de los problemas fueron clasificados con un nivel de gravidez leve, se considera que es posible resolver todas las necesidades especificadas por los usuarios finales.

Figura 7
Tareas de usabilidad Frecuencia de problemas detectados por cada tarea de usabilidad .
Autoría propia.

Figura 8.
Tareas de usabilidad Frecuencia de problemas detectados por cada tarea de usabilidad rotulados por los problemas de usabilidad.
Autoría propia.

En este artículo se describió el plan de pruebas efectuado mediante el protocolo Pensando en Voz Alta en su modalidad de verbalización activa al módulo de terapeuta de un ambiente virtual no inmersivo queofrece terapia basada en actividades de la vida diaria a pacientes con pérdida de movilidad en el codo debido a un ictus.

Como resultado de la prueba de usabilidad, se lograron recolectar 19 problemas de usabilidad, dentro delos cuales dos fueron considerados directamente de suma prioridad debido a que representaron un fallo en la tarea y pérdida de funcionalidad; cinco con prioridad media ya que fueron identificadas por la mayoría de los usuarios y doce de prioridad baja que están orientadas a pequeñas modificaciones a nivelde interfaz. Con ello, se logró un primer acercamiento a la expectativa del usuario potencial respecto al ambiente virtual bajo estudio, con miras a obtener una mejor versión en una próxima iteración del desarrollo del software, que permita reducir o anular los problemas de usabilidad identificados.

Tabla 8
Solución a problemas de usabilidad ordenados por prioridad

Por su parte, el método de introspección denominado Pensando en Voz Alta logró cumplir con su propósito de entendimiento del modelo mental del usuario final (terapeuta), respecto al del programador- diseñador, haciendo notoria su rápida aplicación y bajo costo económico. Dicha estrategia permitió identificar los factores a nivel de diseño e inclusive de implementación que pueden promover el éxito de su implantación una vez liberado el software.A su vez, se logró tener testimonio de la crucial intervención del moderador durante la aplicación del protocolo, debido a que tuvo intervenciones oportunas que permitieron confirmar ciertos detalles de diseño que se sospechaban podrían causar problemas de usabilidad, como es el caso de la búsqueda del paciente a través de un identificador en vez de realizar la búsqueda por nombre y apellido, donde el moderador requirió ofrecer un escenario a futuro para que el usuario potencial confirmara la necesidad dehacer ajustes en el diseño.Los resultados obtenidos revelan que el módulo del terapeuta del ambiente virtual cubre las expectativasdel usuario potencial, salvo la reestructuración necesaria a nivel de diseño y conceptual algunos elementos dentro de la interfaz, junto a la adhesión de algunas metáforas, lo que permitiría en una iteración subsecuente aplicar pruebas indagatorias o de testing, en conjunto con pruebas funcionales.

Así, como trabajo a futuro se esperan aplicar al ambiente virtual los cambios identificados en la Tabla 8, bajo una nueva iteración del DCU, recabando resultados que permitan la liberación del software.

7. Agradecimientos

Agradecemos a la Clínica Therafix y al equipo de trabajo dirigido por el licenciado en terapia física Adrián Castillejos Pineda por su amable y entera disposición para la aplicación de las pruebas de usabilidad y con ello la recolección de datos que fomentaron la discusión de resultados presentados.