El problema
En el escenario analizado, buena parte del transporte sanitario no urgente se coordinaba mediante llamadas, documentos en papel y hojas de cálculo. La asignación, el registro del servicio y su posterior transcripción formaban parte de un proceso fragmentado.
El parte de transporte es la pieza que permite justificar y facturar el servicio. Si el técnico lo completa con un campo vacío, un tiempo incoherente o una firma ausente, el problema puede no detectarse durante el traslado, sino semanas después, durante la liquidación.
Esto separa el momento en el que se produce el error del momento en el que aparecen sus consecuencias. Cuando se detecta, reconstruir lo sucedido resulta más difícil y requiere revisar información de diferentes fuentes.
Además, quien cierra el parte trabaja con un contexto especialmente exigente: puede estar dentro de la cabina, disponer de pocos minutos entre servicios y no tener una conexión estable. La interfaz debía reducir las decisiones y mostrar únicamente la información necesaria para completar correctamente el servicio.
Investigación: el pliego, y nada más
Este proyecto todavía no cuenta con trabajo de campo. No se realizaron entrevistas con coordinadores, acompañamientos en vehículo ni sesiones de observación dentro de la sala de operaciones.
La investigación se centró en auditar el marco documental que regula el servicio. El pliego de la concesión y la normativa aplicable se tradujeron a un modelo de dominio: qué información debía registrarse, quién era responsable de hacerlo y en qué momento del servicio.
Este análisis proporcionó una base sólida para definir qué debía contener el producto, pero no permitía conocer con precisión dónde se bloqueaban los usuarios durante su trabajo cotidiano.
Por tanto, las decisiones de este caso están razonadas a partir de los requisitos documentales y del contexto previsto de uso, pero no han sido validadas mediante pruebas con técnicos y operadores. Esta es la principal limitación metodológica del proyecto y el siguiente paso necesario.
Fuente normativa consultada: Real Decreto 836/2012, de transporte sanitario por carretera .
Dos contextos, un dominio
La decisión estructural del producto fue asumir que el panel del operador y /abordo necesitaban dos interfaces distintas. Comparten información, estados y reglas de negocio, pero responden a contextos de uso opuestos.
Panel del operador
- Escritorio dentro de una sala de coordinación
- Turnos prolongados
- Conexión estable
- Múltiples servicios visibles simultáneamente
- Decisiones basadas en comparar unidades y horarios
Densidad. El operador necesita consultar numerosos servicios reduciendo al mínimo los desplazamientos.
/abordo · el técnico
- Dispositivo móvil dentro del vehículo
- Poco tiempo disponible entre servicios
- Conectividad intermitente
- Un único servicio visible: el actual
- Decisiones orientadas a confirmar y continuar
Vistazo. El técnico necesita identificar la siguiente acción sin detenerse a interpretar la interfaz.
El operador necesita comparar muchos servicios. El técnico necesita resolver uno sin dudar. Ese contraste define el diseño del producto.
Tres decisiones de diseño
El verde deja de competir con las acciones y queda reservado para comunicar que el parte está cerrado.
El verde solo significa «parte cerrado»
En /abordo, el técnico consulta la pantalla rápidamente entre servicios. Si el verde aparece tanto en los botones como en el estado del parte, no permite distinguir de un vistazo entre una acción disponible y una tarea ya completada.
El verde se reservó para un único significado: parte cerrado. Las acciones utilizan tonos neutros y se diferencian mediante su tamaño, posición y jerarquía visual.
El trabajo habitual se guarda localmente; la excepción informa de que necesita una conexión activa con la central.
«Cerrar sin traslado» exige una conexión activa
La mayoría de las acciones de /abordo pueden guardarse sin conexión y sincronizarse posteriormente. Sin embargo, cerrar un servicio sin traslado requiere una autorización de la central y pierde su sentido si se procesa varias horas después.
La interfaz comunica esta excepción antes de iniciar la acción. Diseñar offline-first no significa permitir todo sin conexión, sino identificar qué operaciones pueden diferirse y cuáles necesitan respuesta inmediata.
La prescripción queda fuera de la primera versión. El alcance empieza con la recepción de la demanda y termina en la liquidación.
La primera versión comienza en la recepción de la demanda
Incluir la prescripción del transporte habría ampliado el producto hacia un proceso clínico con requisitos y responsabilidades diferentes. En esta versión, la información clínica se recibe y se gestiona, pero no se origina dentro de Nexo Ops.
El alcance se definió desde la recepción de la demanda hasta la asignación, el traslado, el cierre del parte y la liquidación. Decidir dónde comienza y termina el producto también es una decisión de diseño.
Qué aprendí
Dos contextos opuestos no se resuelven solo con responsive
El panel del operador y /abordo comparten el mismo dominio, estados y permisos, pero requieren decisiones de interfaz diferentes. La alta densidad de información y la consulta rápida de un único servicio son objetivos incompatibles dentro de una misma pantalla adaptada únicamente mediante breakpoints.
El trabajo offline obliga a clasificar cada acción
No existe una respuesta válida para todas las operaciones. Es necesario analizar cada acción y decidir si puede aplazarse sin perder su propósito o si necesita una respuesta inmediata del sistema.
El cierre del parte merece una atención prioritaria
El parte de transporte permite justificar y liquidar el servicio. Un dato incompleto puede no producir consecuencias inmediatas y aparecer como un problema semanas después. Diseñar un cierre difícil de completar incorrectamente aporta más valor que muchas mejoras visuales secundarias.
La normativa es un punto de partida, no un sustituto del trabajo de campo
El pliego y el marco normativo permiten determinar qué información debe registrarse y bajo qué condiciones. Sin embargo, no muestran dónde se bloquea una persona al utilizar el producto dentro de su entorno de trabajo. Esa validación continúa pendiente.
¿Tienes dos usuarios que no se parecen en nada?
Cuéntame en dos líneas y te respondo en 24 h.