Primera Evaluación de Usabilidad: Resultados

A continuación describimos los resultados de evaluación para los tres diseños previamente elegidos. La técnica utilizada para la evaluación de usabilidad ha sido la de test de usabilidad, en concreto la de "Pensar en voz alta". No se ha considerado el tiempo empleado por un usuario en una tarea puesto que la técnica elegida interfiere en la velocidad en la que el usuario realiza la tarea.
Para los tres diseños hemos entrevistado a 7 personas: 2 de ellas eran técnicos del SAMUR, 1 era voluntario habitual y las otras 4 eran personas que no ejercian como voluntarios pero que encajan en dicho perfil. A estas 7 personas las hemos separado en 2 subgrupos: los dos técnicos y el voluntario en un subgrupo y las 4 personas que encajan en el perfil de voluntario en otro. 

Resultados del diseño 1

En este caso y al igual que en el resto e prototipos hemos entrevistado a siete personas dos de ellas técnicos. Hemos utilizado el método de “pensar en voz alta”. Realizado nuestro test hemos obtenido una media de 3 errores entre todos los entrevistados y 1 ayuda de media.

Los datos obtenidos nos indican lo siguiente:

  • No saben en qué momento del aviso se encuentran (ultima clave dada). 
  • No les gusta que la clave 3 sede de forma automática. 
  • Les gusta la leyenda de claves. 
  • En su opinión el bolígrafo táctil para interactuar con el dispositivo, acabaría perdiéndose o robándolo alguien. En su lugar han propuesto que se puedan utilizar bolígrafos normales, ya que suelen llevar siempre alguno encima y que sea una zona de fácil limpieza. 
  • Opinan que es ineficaz que tengan que volver siempre al menú principal para enviar claves o informar. 
  • El formulario de entrada al servicio les parece correcto pero que añadirían el número de los voluntarios que entran en ese momento. 
  • Piden una opción de borrar el historial. 
  • Piensan que el sistema debería implementar más cosas como:
     
    • Botón de solicitar clave 14 (fin de servicio). 
    • Botón de clave 22(repostaje) con guía mediante GPS a gasolinera más cercana. 
    • Una forma rápida de acceder a los datos del aviso actual. 
       
  • Nos han dado muestras que para el conductor es incómodo ya que puede provocar riesgos en la conducción del conductor al distraer su atención.
  • Muestran interés en una forma de enviar los datos de las personas vía mensaje (cerrar informe).



Resultados del diseño 2
 
Para los usuarios, del segundo subgrupo, a los que se les ha hecho el test de usabilidad para este diseño, cuya interacción es de tipo conversacional, han encontrado problemas en el momento de querer realizar una acción puesto que no sabían las tareas que ofrecía la aplicación. No tiene menús, no indica las posibles  acciones o tareas que puede realizar el diseño. Un usuario sin conocimientos previos de cómo funciona la aplicación por voz no sabe cuáles son las palabras que acepta el dispositivo.
En el subgrupo de técnicos el porcentaje de errores en el momento de manejar el prototipo es muy bajo debido que la interacción del dispositivo es muy natural, lo que si producía error y nos dejaron constancia de ello es que el ambiente en el que estará el dispositivo es muy ruidoso y por tanto haría que el ratio de tareas realizadas correctamente disminuyera mucho.
En cuanto a las tareas de recuperación de errores hay que destacar que el prototipo solo realiza las acciones que percibe dentro de unos parámetros de claridad y si no se encuentra en ellos te hace repetir el mandato, pero no hay un mandato deshacer, aunque hay que destacar que el porcentaje de error de interacción con este prototipo es casi nulo.
Para todos los usuarios la interacción con este prototipo  resulto muy efectiva ya que las tareas a realizar apenas requerían esfuerzo y se realizaban con un número reducido de mandatos.





Resultados del diseño 3
 
En el subgrupo de los posibles voluntarios se vio que a pesar de ser un dispositivo con un  modo de iteración relativamente sencillo, su desconocimiento de las claves, hacía que los usuarios estuviesen yendo al menú principal y consultar la leyenda de claves, para luego tener que ir al menú correspondiente para insertar los códigos.
También, tanto en el subgrupo de los usuarios que podían ser voluntarios y el subgrupo de los técnicos y voluntarios, apuntaron que la iteración con el dispositivo era demasiado larga para poder conseguir lo que ellos se proponían hacer, es decir, el número de comandos a introducir en el dispositivo en su caso es alto. De eso sacamos que en un caso real el dispositivo sería demasiado engorroso, sobre todo si es alguien que no se sabe las claves o si se está haciendo una actividad que requiere atención especial, por ejemplo conducir una ambulancia.
De nuestro dispositivo cabe destacar que los usuarios entrevistados, el porcentaje de errores en la hora de manejar el prototipo es bajo debido a la preselección y la confirmación de las acciones importantes, también decir que en situaciones de estrés el porcentaje de error se incrementa.
En cuanto al tiempo de recuperación de errores nos dimos cuenta que no había un mandato que te permitiera deshacer la última acción, lo que hace que se tenga que seleccionar la opción contraria si se quiere deshacer una acción, lo cual hace que la solución dependa del error y algunos casos como enviar una clave errónea no tienen solución.
Mirando los puntos buenos los técnicos y el voluntario, calificaron el prototipo como un dispositivo completo y cómodo.





Eleccion del diseño

Después de haber sopesado los distintos resultados de usabilidad de los tres diseños hemos elegido, seguir de aquí en adelante, con una combinación del diseño 1 y 2.

Actualización: Mejora del primer prototipo

A continuación mostramos la segunda versión del primer prototipo. Hemos reagrupado opciones y añadido otras nuevas para conseguir que el sistema sea más rápido y accesible, pensando también en los usuarios novatos que no aún no conocen bien los códigos y claves.

Estado inicial del sistema. Este mensaje aparece cuando el usuario aún no se ha dado de alta porque no ha iniciado el servicio.



Al querer darse de alta se pedirán ciertos datos que se enviarán a la base



Menú principal una vez dado de alta



Al igual que en la primera versión se recibe un aviso de la central que hay que atender. Al pulsar sobre leer automáticamente el sistema envía la clave 1 (Mensaje recibido) para agilizar tareas rutinarias.



Inmediatamente el sistema te muestra el aviso que el usuario acaba de recibir (aviso en curso) proporcionando información del lugar del susceso, heridos, etc... También te permite localizar el lugar en el GPS de forma inmediata sin tener que volver al menú. De igual forma que al leer el mensaje, al seleccionar 'Localizar en GPS' automáticamente el sistema envía la clave 2 (Dirigiéndose al lugar del suceso)



Una muestra de como estaría organizado el nuevo registro de avisos. Aparte del aviso actual se muestran los anteriores por si el usuario desea revisar datos de los que no se acuerda. Los avisos que se muestran aqui son las cabeceras; para verlo al completo habría que seleccionar aquél que se quiera revisar.



La forma de ir al lugar del suceso se realiza mediante GPS al igual que en la primera versión. Al llegar allí se enviaría la clave 3 (Llegada al lugar del suceso)



Como hemos mencionado antes, las claves que se envían de forma automática son para casos rutinarios. Para todo lo demás se accede a la opción 'Claves y códigos' que es la que se ha mejorado. Lo que se ha hecho ha sido juntar en un mismo lugar el envío de claves junto con el significado de estas. En la versión anterior si el usuario no recordaba alguna clave primero tenía que acceder al apartado 'Leyenda' para leer las descripciones de estas, y luego a 'Enviar Clave' pasando siempre por el Menú principal. En esta versión el usuario tiene toda la información en una misma ventana, lo que significa un ahorro de tiempo. De igual forma se han añadido la descripción de Códigos de valoración y otros códigos, necesarios para enviar el informe a la base una vez se ha finalizado el aviso.


Todas las tareas que realizaba el usuario despues de llegar al lugar del suceso (Ir al hospital más cercano, finalizar aviso) se realizan exactamente igual que la primera versión.

Esta versión será la que se use para la evaluación de usabilidad

Planificación de la primera evaluación de usabilidad

A continuación explicamos la planificación planeada para la evaluación de usabilidad de los 3 prototipos:


Estrategia

Haremos un test de usabilidad con distintos tipos de usuarios reales. Usaremos el protocolo Pensar en voz alta y también mediremos algunas acciones, como pueden ser el número de fallos al querer realizar una tarea en concreto, o el número de veces que necesita la ayuda del facilitador para realizar alguna tarea.


Instrucciones

Al usuario se le presentarán distintos casos relacionados con el uso del dispositivo. Se ha intentado que cada caso sea diferente, y proporcione información útil para medir la usabilidad. A continuación explicamos los siguientes casos:


Caso 1 

Se recibe un aviso de la base: El lugar del suceso es la estación de Chamartín. El herido no necesitará que lo lleven al hospital por lo que el aviso finalizará en ese lugar.
El usuario deberá seguir los pasos necesarios para leer el aviso, acudir de forma rápida al lugar del suceso y atender al herido. Durante todo este proceso deberá enviar las claves correspondientes a la base para informar de su situación. El usuario dará la valoración final del herido una vez vaya a finalizar el aviso.
        

Caso 2

Se recibe un aviso de la base. El lugar del suceso es Atocha.  En el lugar de los hechos se ve que hay disturbios por lo que se precisa presencia policial. Una vez ha llegado la policia, la ambulancia traslada al herido al hospital. El usuario deberá seguir los pasos necesarios para leer el aviso, dirigirse al lugar del suceso, solicitar presencia policial y dirigirse al hospital más cercano, enviando las claves correspondientes durante el proceso. Por último el usuario dará la valoración final del herido una vez vaya a finalizar el aviso, y como no recuerda uno de los códigos de valoración deberá acceder al listado de códigos.

Caso 3

Se recibe un aviso en la base. El lugar del suceso es Villaverde Alto. A mitad de camino se quieren revisar los datos recibidos del aviso en curso, por lo que se accederá al historial de avisos. Poco antes de llegar al lugar del suceso la ambulancia se estropea y queda inutlizada, por lo que habrá que avisar a la base de la situación. El usuario deberá seguir los pasos necesarios para leer el aviso, dirigirse al lugar del suceso, comprobar los datos del aviso en curso, e informar a la base de la inutilización de la unidad.


Reparto de roles

Se irán rotando las asiganciones para los distintos roles.
Para el caso 1:
  • Facilitador: Giulio Burga
  • Observador 1: Sergio Gil
  • Observador 2: Sergio Fernández
  • Guia del prototipo: Carlos Castillo
Para en caso 2:
  • Facilitador: Carlos Castillo
  • Observador 1:  Giulio Burga
  • Observador 2: Sergio Gil
  • Guía del prototipo: Sergio Fernández
Para en caso 3:
  • Facilitador: Sergio Gil
  • Observador 1: Carlos Castillo
  • Observador 2: Sergio Fernández
  • Guía del prototipo: Giulio Burga

Presentación de los tres diseños alternativos

INTRODUCCIÓN

¿Qué se quiere crear?
Se quiere crear un dispositivo que sea compatible, complemente o sustituya al tetra (el dispositivo actual) en las comunicaciones entre la base (o central) y la ambulancia. Un dispositivo que agilice las comunicaciones, ya que el sistema actual tiene aspectos que se podrían mejorar.

Nuestro dispositivo comunicará la ambulancia con la central mediante el mismo sistema que el tetra; es decir, el dispositivo usará los mismos procedimientos y las mismas claves que este.

Su finalidad es agilizar las comunicaciones para que las ambulancias puedan llegar antes al lugar del accidente, evitando situaciones como los colapsos en la malla (Cuando un usuario quiere comunicarse con la central pero no puede porque hay otro hablando) e impedirá (en las emergencias comunes) que el usuario lo utilice mal ya que le irá guiando según la situación.

SUPUESTOS
  1. A los usuarios del dispositivo les gustaría usar menos la malla para tareas rutinarias (enviar claves, pedir hospital cercano, etc...).
  2. No quieren esperar a que la malla esté desocupada.Les gustaría disponer de una leyenda de claves, con una explicación detallada de cada una.
  3. Poder localizar fácil y rápidamente el lugar del accidente, así como el hospital más cercano.
AFIRMACIONES
  1. Un sistema informático de comunicación entre la base y la ambulancia es casi con seguridad mucho más eficiente que los sistemas actuales.
  2. El sistema GPS del dispositivo es mucho más preciso y rápido que la búsqueda por callejero.
CONCEPTO DEL PRODUCTO
  • METÁFORAS
    • Coordinación, mediante el paso de mensajes.
    • Guía, entendiendo que te va mostrando el camino a la emergencia.
  • CONCEPTOS
    • Claves
    • GPS
    • Comunicación por voz
    • Cominicación por mensaje
    • Historial de claves
    • Referencias a hospitales
    • Coordenadas
    • Mensajes de la base
    • Introducir clave
    • Sonidos de aviso
    • Canal de preferencia
  • RELACIONES ENTRE CONCEPTOS
    • Referencias a hospitales, proporcionado por el GPS.
    • GPS actúa según las coordenadas.
    • Al llegar un mensaje se da un aviso.
    • Se puede enviar claves introduciendolas manualmente


EJEMPLO DE ESCENARIO

El usuario, un funcionario del SAMUR, se encuentra en la central de la ambulancia recibe un mensaje de emergencia por el dispositivo que tiene nuestra aplicación. El mensaje contendrá información de la emergencia como datos del paciente dirección donde se encuentra, códigos iniciales, etc. La aplicación trazará la ruta mediante GPS desde el punto en que se encuentra la ambulancia hasta lugar de destino. Una vez que se dirija la ambulancia hasta el punto de destino se envía la clave 1 a la base.
Ya en el lugar el usuario envía la clave 3 y procede a la atención del paciente, si es necesario dar detalles médicos sobre el paciente se usa el tetra, al necesitar este un traslado al hospital, el usuario vuelve a manejar la aplicación para pedir un hospital de referencia y enviar el clave 4.

Una vez en el hospital se envía el clave 5, se hace el informe y el hospital lo sella. Por último se envía la clave 0 en el hospital y se informa del paciente dando los códigos de valoración y el código de "aviso" por voz.

PRIMER PROTOTIPO 

El primer prototipo sigue un estilo de interacción táctil. No se usarán las manos directamente ya que los usuarios (es decir, los técnicos) suelen llevar guantes y es posible que estén manchados. Por lo tanto se usará un lápiz táctil para interactuar con el dispositivo. Será de manipulación directa: Se usarán botones grandes y vistosos, permitiendo acciones rápidas y que sean fácilmente reversible. Asimismo las acciones de interés estarán visibles de forma inmediata.

El prototipo que mostramos a continuación ha intentado plasmar estas características. La primera imagen hace referencia al menú principal. Este es el punto de inicio, cuando todavía no se ha recibido aviso alguno de la base.

Suponemos que el usuario recibe ahora un mensaje de la base

Mediante el lápiz táctil pulsa en leer y le lleva directamente al mensaje, que se encuentra dentro del historial de mensajes


El mensaje contiene datos como la edad del paciente, su sexo, y otros datos técnicos. Para mejorar la rapidez del sistema se da la opción al usuario de mostrar la dirección en el GPS directamente, que en nuestro caso es lo que selecciona




Al seleccionar esta opción se envia la clave 2 (salida hacia el lugar de la actuación) automáticamente. En cualquier caso el envío automático de claves se hará sólo en situaciones puntuales para mejorar la rapidez del sistema. En el resto de casos el usuario tendrá que acceder desde el menú a la opción Enviar Clave. Suponemos que la ambulancia ya ha llegado a su destino y quiere enviar la clave 3 (llegada al lugar del accidente), por lo que ahora sí tiene que acceder a esa opción.


Ahora al usuario se le muestra un pad táctil con el que podría enviar la clave que quisiera dependiendo de la situación. Las claves como máximo tienen una longitud de tres dígitos y algunas de ellas tienen un punto (Por ejemplo la clave 10.1). En este caso el usuario envía la clave 3 para comunicarle a la base que ha llegado al lugar de la actuación.

En este punto el técnico trata al herido. Si no necesita que lo lleven al hospital el aviso acabaría ahí, pero en nuestro caso vamos a suponer que hay que llevarle a uno. Mediante el pad se enviaría la clave 4 (salida hacia el hospital) accediendo de la misma forma que se ha mostrado anteriormente, y seguidamente el usuario seleccionaría la opción Mostrar Hospitales desde el menú principal


Aquí se da la opción de mostrar el hospital más cercano u otros hospitales. Esta última opción se proporciona por si el paciente quiere ir a otro que no tenga que ser necesariamente el más cercano. Se proporcionaría una lista de los hospitales de Madrid (o de la ciudad correspondiente) que el usuario podría elegir. Para este caso queremos ir al hospital más cercano, asi que el usuario selecciona la primera opción.



Nuevamente se abre el GPS mostrando la ruta hacia el hospital. Una vez allí enviaría la clave 5 (llegada al hospital) usando el pad de nuevo. Como en este punto ya ha finalizado el aviso, sólo le quedaría pulsar el botón Finalizar Servicio desde el Menú principal.

Análisis de usuarios, tareas y entorno: Resultados

Análisis del entorno

Hemos realizado un análisis del entorno asistiendo al lugar de trabajo donde la aplicación va ser usada y tomando notas sobre formas de uso, elementos del medio que interaccionan, etc.
Realizado este primer estudio hemos observado las siguientes circunstancias:
  • En ocasiones se trabaja en condiciones de poca luz.
  • La ambulancia posee un flexo que proporciona luz dentro del habitáculo. Se activa mediante interruptor.
  • Trabajan con guantes de nitrilo.
  • Trabajan en ocasiones con fluidos que manchan como la sangre, betadine, sueros, etc.
  • Poseen un tetra portátil con el que poder comunicarse en caso de estar en el exterior de la ambulancia o base de descanso.
  • Las bases poseen una radio receptora de mensajes y comunicaciones a la que llegan los avisos de todas las unidades filiadas a esa base.
  • Hemos observado que en momentos concretos las ambulancias se pisan la comunicación entre si, provocando en algunos casos confusión con la central de comunicaciones y falta de coherencia en ellas. En este caso es la central la que se ocupa de poner orden en las comunicaciones.
  • La operatividad de la unidad se da en otra cobertura (cobertura total 2). El resto de comunicaciones se producen en la “cobertura total 1”.
  • Para enviar las claves se mantiene pulsado el botón del número a enviar. En algunos casos se ve la dificultad de los más novatos para entender el sistema de envío/recepción, así que estos terminan el envío con comunicación por voz produciendo ocupación de la malla.
  • La mayoría de tareas se producen en la calle.
  • Las comunicaciones, salvo casos graves, se producen en el interior de la ambulancia.
  • Se comunica cada movimiento de la ambulancia cuando es requerido (mensaje recibido, se dirige hacia el punto, etc.) normalmente por claves (1, 2, 3...).
  • El conductor cuando se realiza un traslado del lugar del suceso al hospital, se encarga de luces, sirena, conducir y en algunos casos, cuando existe ocupación de los otros miembros de la ambulancia, se encarga de la comunicación por voz.
  • El conductor cambia de sonido de sirena con la bocina de la ambulancia.
  • El conductor posee un interruptor más manejable para permitir las comunicaciones por voz, aunque por norma general no lo utilizan.

Análisis de las tareas
Número de personas entrevistadas
El número total de personas entrevistadas ha sido un total de 10 miembros, de los cuales cinco son usuarios habituales y cinco no habituales. Los operadores no los hemos considerado.

Preguntas en la entrevista:
La entrevista tipo que hemos realizado a cada usuario ha sido:
-¿Tiene algún problema en el uso del sistema actual?
-¿Cómo utiliza usted el tetra y envió de mensajes actual?
-¿Utiliza algún atajo?
-¿Le gusta disponer en su entorno el sistema de alguna forma especial?
-¿Cada cuánto suele utilizar el sistema actual?
-¿En qué momento se produce más intercambio de información con la central?
-¿Cómo lo realiza?
-¿Qué mejoraría usted del sistema actual?
-¿Qué es lo más importante del sistema en su uso?
-¿Qué fallos? ¿Y cada cuanto se producen errores en el sistema?

Conclusiones
-Cuando se produce un fallo en él envió/recepción de mensajes, se produce un caos ya que todo se debe realizar por voz. Son fallos no muy comunes. Además hay problemas de optimización del tiempo de atención de las ambulancias (se pierde la referencia a su posición).
-Lo más importante es la comunicación eficaz con la base en caso de necesidad (apoyo de más ambulancias, llamar policía,  etc.).
-Problemas: Interrupción en las comunicaciones, espera en la comunicación.
-Las mejoras que realizarían seria no tener que esperar a que las ambulancias terminen su comunicación con la central (utilizan una malla de voz común a todas). Y que no interrumpan otros equipos cuando estas comunicando.
-El envío  de mensajes es parecido al envío por telefonía.
-En los atajos, aparentemente no existen. Aunque lo que si realizan es ocasiones es el envío por voz claves que deberían ser enviadas por SMS.
-Todos los entrevistados refieren que el posicionamiento del sistema sea el actual, por costumbre.

Estudio mediante Observación
  • Fases
    • Preparación:
Este estudio lo realizaremos mediante que uno de los integrantes del grupo esté presente en una ambulancia, una llevada por usuarios habituales y  otra por no habituales.
    • Datos observados:
El manejo del sistema difiere de cada usuario.
Problemas en la escucha de mensajes (voz)
En ciertos momentos alta ocupación de la malla.
En otros momentos baja ocupación de la malla.
Gran cantidad de mensajes, en algunos casos inservibles (los usuarios ni los leen) pasándolos por alto.
Utilizan guantes de nitrilo
Alto nivel de ruido ambiental (sirena, tráfico, conversaciones, etc.).
Los nervios en los usuarios provocan errores en el manejo del sistema por los usuarios.
Cuando el conductor conduce y va solo en ciertos momentos se tiene que encargar de llevar la sirena, conducir y comunicarse.
  • Necesidades
    • Usuarios habituales:
-Mayor corrección en las comunicaciones de los usuarios puntuales.
-Búsqueda de ruta.
-No interrupción en las comunicaciones.
-Mirar códigos o claves no habituales, normalmente en un librito personal pero que no lo da la empresa, es decir, es personal de cada usuario.
    • Usuarios puntuales:
-Mayor facilidad de interacción con el sistema, para ellos en algunos casos es lioso y deficiente en su manejo.
-Consulta de códigos, claves y dudas en la posible atención al paciente.
-Búsqueda de la ruta.
-Comunicación estandarizada, existe en la actualidad pero no la llevan a cabo.
-El conductor debe poder comunicarse sin prestar mucha atención.
Análisis de usuarios 
1.- Categoría de usuarios:
- Usuarios Habituales: En este lugar meteremos a los usuarios con alta experiencia en el manejo del sistema actual. Estos usuarios serán los denominados funcionarios.

- Usuarios Puntuales: En este grupo estarán representados los usuarios que utilizan el sistema actual pero no tienen una alta familiarización. Estos usuarios son los denominados voluntarios.

- Operador: Es el encargado de la recepción de las llamadas de emergencias y comunicárselas a las distintas ambulancias implicadas. Este usuario no será considerado posteriormente ya  que nos centraremos únicamente al ámbito de la ambulancia.

2.- Características de los usuarios: 
- Usuarios Habituales: Serán los usuarios que tienen una gran familiarización con el sistema., es decir, los consideraremos como los usuarios expertos en las comunicaciones, atajos y forma de usos.

- Usuarios Puntuales: Usuarios no expertos, su nivel de interacción con el sistema es variable, podemos encontrar usuarios que lo utilicen correctamente y usuarios que no saben ni utilizar lo básico. Aunque normalmente en el grupo de tres que van en la ambulancia, dos de ellos saben manejar el sistema.

- Operador: Son usuarios especializados con el sistema con el que trabajan. Aun así no entramos en consideración ya que no vamos a evaluar esa parte de las comunicaciones.

Escenario de tareas
Estos son dos escenarios comunes en el día a día del SAMUR en Madrid.

Escenario 1
Los voluntarios se encuentran dando una vuelta por la calle Gran Vía.
A las 00:15 reciben un mensaje por el tetra, lo leen y mandan la clave 1 a través del sistema incorporado en la ambulancia. En el mensaje reciben lo siguiente:
                8422/12146/3.9/Calle Barquillo nº9/
                Varón/ 22 años/ intoxicación
                Etílica.
Después de dar la clave 1 buscan en el mapa la calle Barquillo, encienden la sirena y dan la clave 2. Una vez dada la clave 2 (desde la ambulancia) se dirigen a la calle.
Una vez en la calle Barquillo contactan visualmente con el paciente y envían la clave 3. Atienden al paciente y deciden que se quede en el punto ya que el paciente no quiere asistencia.
Una vez atendido terminan de rellenar el informe   y lo firma el paciente. Piden comunicación:
-Central de la alfa-422-Ambulancia.
-Adelante para la alfa-422-Central.
Cuando ya tienen paso para la comunicación informan de lo siguiente:
“Clave 0 en el punto el paciente se queda en el punto.
Un paciente atendido con código inicial 3.9, código final 3.9, código de valoración India negativo, negativo y numero de informe 12146” 
A lo que contesta central.
-Negativo comunicado.
Y la ambulancia vuelve a repetir:
Un paciente atendido con código inicial 3.9, código final 3.9, código de valoración India negativo, negativo y numero de informe 12146” 
Terminando la comunicación con:
-Recibido-Central.

Escenario 2
El equipo de funcionarios se encuentra tomando una coca cola en un bar de la avenida de la albufera. En ese momento reciben un aviso que leen desde el tetra portátil. Dan la clave 1 a través del tetra portátil y se dirigen hacia la ambulancia. El aviso es el  siguiente:
8413/13333/Calle Pico Cejo/
2.4/ Pelea con brecha en la cabeza.
Una vez dentro de la ambulancia  buscan la calle y lo meten en el GPS esperando a que se encienda y localice el satélite. Dan la clave 2 y se dirigen al punto.
Durante el trayecto se comunican con central:
-Central de la alfa-8413
-Adelante para la alfa que llama
-¿Nos podría confirmar si 10.1 en el punto?
-Afirmativo
-Recibido
Una vez en el punto dan la clave 3 y hablan con la policía. Atienden a los dos pacientes y uno de ellos se queda en el punto y al otro hay que trasladarlo. Como el paciente no conoce su hospital de referencia se vuelven a comunicar con central.
-Central de la alfa-8413
-Adelante para la alfa 8413.
-Nos podría indicar hospital de referencia en el punto.
En ese momento se introduce otra ambulancia por medio teniendo que esperar la respuesta de la central. Una vez hay silencio en la malla la central comunica el hospital de referencia.
-Alfa 8413 de Central
-Adelante para alfa 8413
-El hospital de referencia es el Infanta Leonor
-Recibido apúntenos la cuatro
-Recibido.
Una vez terminada la conversación llevan al paciente al hospital. Al llegar al hospital envían la clave 5 por el tetra de la ambulancia.
Terminan de completar el informe del paciente trasladado, pero se les olvida el identificativo de la policía municipal por lo que suprimen ese dato.
Filian al paciente en el hospital y la recepción sella el informe. Una vez en la ambulancia se comunican con central pero tienen que esperar 10 minutos a que acabe la conversación con otra ambulancia.
-Central de la alfa-8413
-Adelante para la alfa 8413.
“Clave 0 en el punto dos pacientes atendidos
Un paciente atendido con código inicial 2.4 código final 2.1, código de valoración Tango negativo, negativo y numero de informe 13333/1. El paciente se queda en el punto
El segundo paciente con código inicial 2.4 código final 2.1, código de valoración Tango negativo, negativo y numero de informe 13333/2. Es trasladado”
-Recibido.


Perfiles de usuarios

 
Daniel Sanchez


Edad: 19 años
Educación: Estudia Biología en la Universidad Complutense de Madrid. Posee título técnico de emergencias médicas (TEM).
Ocupación: En su tiempo libre ejerce como voluntario en SAMUR PROTECCION CIVIL. 

Vive en Madrid desde hace cuatro años, empezó a ser voluntario hace un año, con la mayoría de edad. Como no posee el carné de conducir entra como sanitario en las guardias.

Tecnología usada: Se considera usuario básico en tecnología, suele utilizar un ordenador de mesa, le gusta mucho el móvil, pero no le gusta encargarse de las comunicaciones en la ambulancia. 

Problemas: Debido a que entra de forma esporádica, en sus tiempos libres, se queja de que el sistema de comunicación no es muy intuitivo.
Cuando le toca hablar por malla tiene miedo a equivocarse en la comunicación.
Suele olvidarse de los códigos de valoración y otro tipos de claves/códigos.

Mejoras:
El sistema de comunicación debería se mas fácil de manejar.
Le gustaría que no fuese tan necesario la comunicación por voz.
Cree que una leyenda de códigos e instrucciones de como utilizarlos le seria muy útil.

Sucesos:
Hace unos meses, llevaba tiempo sin entrar a realizar una guardia y se había producido un cambio en el sistema de envío de mensaje. A él no le gusta la comunicación por voz en la ambulancia así que tardo bastante tiempo en aprender el nuevo funcionamiento del sistema.
      


 
Carmen Molina


Edad: 32 años
Ocupación: Funcionaria del SAMUR.
Estudios: Técnico en emergencias(TEM).

Vive en Getafe desde que nació. Le gusta conducir y por eso se suele encargar de la conducción en ambulancias.

Tecnologías que usa:
Usa de forma avanzada el tetra y tecnologías relacionadas con la música.
Le gusta utilizar el GPS para tardar menos en los avisos.

Problemas:
Tiene dificultad a la hora de conducir, comunicar y encargarse de la sirena al mismo tiempo. Le da miedo tener un accidente grave y causar daños mayores al enfermo y al resto de personas dentro de la ambulancia.
Debido a que en ocasiones van dos en la ambulancia se ocupa de las comunicaciones de manera asidua mientras que sus compañeros atiende al paciente.
No le gusta manchar de sangre u otros líquidos la ambulancia.
Se pone nerviosa cuando no puede comunicarse por malla debido a que hay otras ambulancias hablando por ella.

Mejoras:
Le gustaría tener todo mas a mano cuando conduce y de manera mas sencilla.
Desea mayor usabilidad con el sistema actual.
Le gustaría no tener que esperar para comunicarse tanto para mensajes importantes como livianos.

Sucesos:
Hace un año tuvo un accidente de trafico con la ambulancia cuando intentaba responder a la base. Se tiro una semana de baja debido a lesiones.

Planificación de la observación de usuarios

Descripción de usuarios a los que va destinado el sistema:

1. Funcionarios del SAMUR: Personas dedicadas profesionalmente y reciben una remuneración por el trabajo.  Tienen jornada de trabajo.

2. Voluntarios del SAMUR: Personas no dedicadas profesionalmente y no reciben remuneración por su trabajo. Además entran por decisión propia y con intervalos de tiempo no mayores a dos meses.

3. Operadores de la central: Los encargados del envío y recepción de mensajes, ya sea de voz o vía SMS, en la base.

Dentro de los grupos 1 y 2, antes mencionados, cabe  distinguir cuatro subgrupos de usuarios diferenciándolos por su actividad desempeñada en la ambulancia:
  • Conductor: El conductor de una ambulancia es un poseedor del título TEM y realiza las funciones de conductor e interacciona con las comunicaciones en algunos casos a la vez que conduce. 
  • Técnico de emergencias: Con este nombre diferenciamos a los poseedores del título TEM pero que no van conduciendo y dedican más tiempo a las comunicaciones.
  • Enfermero/a: Persona con titulación de enfermería (título universitario) y va acompañando a un médico y al conductor. Se encarga de las funciones de enfermería.
  • Medico: Usuario con título en medicina (universitario) que va acompañado de un enfermero y conductor. Se encarga de comunicaciones, y realizar valoraciones médicas.
Además de los usuarios expuestos con anterioridad hay que reseñar la existencia de lo que llamaremos usuarios no comunes o especiales. Estos usuarios son aquellos que su función es de coordinación, o realizan una labor más específica (casos psiquiátricos, psicológicos, etc.).

Enfoque de la observación de usuarios:

La observación la realizaremos con los siguientes métodos:

1. Entrevistas a los distintos usuarios expuestos anteriormente. Realizaremos el siguiente tipo de preguntas:
  • Problemas más comunes en la comunicación.
  • Frecuencia de la utilización del tetra (aparato electrónico con el que se realiza las comunicaciones).
  • Momentos en los que se realiza más intercambio de códigos/ comunicaciones en la relación base-ambulancia.
  • Qué valoran más los usuarios que utilizarán la aplicación en su jornada laboral.
  • Que mejoras se les puede aplicar, desde su punto de vista,  al sistema.
  • Frecuencia de fallos en la malla y mayores pérdidas de tiempo en el sistema actual

2. Observación del entorno de trabajo: Aprovechando la pertenecía de uno de los componentes del grupo a los usuarios voluntarios, el componente de nuestro grupo realizará una observación exhaustiva y en varias ocasiones del entorno de trabajo.

Proyecto Comunicación Base-Ambulancia (Bambú)

El proyecto tratará de mejorar las comunicaciones entre la central (donde se recogen las llamadas a emergencias y avisan a los servicios de urgencia) y las ambulancias.

Actualmente la comunicación entre ambas se basa en comunicación por voz a través de radio y recepción-envío de mensajes. Para mejorar este sistema hemos planteado las siguientes soluciones:
  • Reducir las comunicaciones por voz para evitar el colapso de la malla y dejar más tiempo libre la malla para emergencias más importantes.
  • Realizacion de un sistema más interactivo con el que se puedan enviar claves, operatividad, etc... el cual tenga comunicación directa con la central y sea más eficaz que el actual.
El sistema interactivo a realizar debe de tener unas características concretas debido al uso que se va a realizar del software. Estas características son:
  • Sistema de respuesta inmediata.
  • El sistema tiene que poder enviar claves (ya diseñadas por los protocolos de SAMUR) y recibir.
  • Incorporación de un GPS en el que se reciba directamente el lugar al que dirigirse. Mejorando el tiempo de actuación.
  • El sistema debe disponer de una base de datos e historial en los que consultar dudas (número de códigos, emergencias en el punto de actuación, etc ).
  • Implicitamente el sistema debe ser seguro para evitar la intrusión de software dañino o la incursión de usuarios no unidos al grupo de emergencias.

En un primer contacto con el proyecto hemos pensado que lo ideal para poder desarollar dicho proyecto es que la propia ambulancia posea un navegador de abordo o Tablet pc que realice las funciones descritas anteriormente.