Proyecto: Phenyx Health

Phenyx Health · Gestión de departamentos de radioterapia

Un paciente, doce fases y una sola pantalla para saber dónde está

Rediseño de la herramienta con la que un servicio de radioterapia sigue a cada paciente desde la primera consulta hasta la última sesión en el acelerador, y planifica máquinas, turnos y personas alrededor.

  • Product Design
  • UX en salud
  • Sistema de diseño
  • Datos complejos
Ficha de paciente en escritorio (1440×900) con la barra lateral de fases a la izquierda, la fase Dosimetría abierta y el selector de estado visible. Usar un paciente ficticio con nombre, ID e historial inventados. Demuestra la idea central: todo el recorrido clínico en una sola pantalla.
Mi rol
Product Designer (UX/UI) desde Wandary. Rediseño de flujos, sistema de diseño y especificación para desarrollo.
Equipo
Una desarrolladora front-end, tecnología y producto de Wandary, el equipo de datos de Phenyx y radiofísicos y oncólogos como usuarios de referencia.
Duración
18 meses (mar 2025 – ago 2026) sobre un producto en marcha desde diciembre de 2023.
Plataforma
Aplicación web de escritorio para departamentos de oncología radioterápica. Modo claro y oscuro, español e inglés.
Stack
React 18, Vite, Redux, CSS Modules y tokens de color y texto propios.
Alcance
6 áreas, 12 fases del tratamiento, 15 estados, 10 tablas de configuración y más de 1.000 commits en el periodo.

01 — El desafío

Un proceso que nadie veía de principio a fin

Un tratamiento de radioterapia pasa por doce fases: registro, consulta, espera, simulación, contorneado de órganos de riesgo y de volúmenes, definición, dosimetría, verificación, administración y enfermería. En cada una trabaja un perfil distinto, y cada uno solo veía su parte.

La primera versión de Phenyx Health digitalizaba los formularios, pero no el proceso. Para saber por qué un paciente no empezaba en la fecha prevista había que abrir fase por fase. Los estados cambiaban sin dejar rastro de quién ni cuándo, y cada pantalla resolvía tablas, botones y colores a su manera.

−58 %

de tiempo para localizar en qué fase está bloqueado un paciente, medido en pruebas de tarea con coordinadores y radiofísicos.

El objetivo de negocio

  • Que cualquier perfil sepa en qué punto está un paciente sin preguntar a nadie.
  • Que cada cambio de estado quede firmado: quién, cuándo y por qué.
  • Que el producto pueda crecer a otros hospitales sin rediseñar cada pantalla.

02 — Restricciones y alcance

Rediseñar sin parar un hospital

El producto ya estaba en uso. Cada cambio llegaba a producción por partes, pantalla a pantalla, sin congelar el desarrollo de funciones nuevas.

Técnicas

  • Deuda heredada. Más de 500 commits previos, Bootstrap 4, estilos globales y un modo oscuro hecho pantalla a pantalla.
  • Datos que no controlamos. Estados, fases y tablas llegan de la API y del motor de planificación. La interfaz se adapta, no decide.
  • Tres idiomas en el código. Español, inglés y una variante de derecha a izquierda. Ningún texto podía depender de su longitud.
  • Gráficas de terceros. La analítica usa una librería de datos propia de Phenyx con Plotly: el estilo se ajusta desde fuera.

De negocio y clínicas

  • Vocabulario clínico cerrado. OaR, fraccionamiento o peer review no se traducen ni se simplifican: es el idioma del usuario.
  • Trazabilidad obligatoria. Un cambio de estado sin responsable ni fecha no vale en un servicio sanitario.
  • Pantallas de trabajo, no de consulta. Se usan durante toda la jornada en monitores de escritorio. Densidad antes que aire.
  • Datos sensibles. Sin acceso a datos reales de pacientes para diseñar ni probar: todo con casos ficticios.

03 — Proceso y decisiones clave

El estado importa más que el formulario

En las sesiones de observación con el servicio, la pregunta que más se repetía no era «¿qué datos tiene este paciente?», sino «¿en qué está y quién lo tiene?». Los formularios se rellenan una vez; el estado se consulta decenas de veces al día. Veníamos de diseñar pantallas por fase. El insight cambió el rumbo: el eje de la ficha pasó a ser el recorrido, y cada fase, una parada con su estado a la vista.

De ahí salieron tres piezas que ordenan el resto: una barra lateral con las doce fases y su estado, un selector de estado que exige responsable y fecha, y un código de color único para los quince estados en toda la aplicación.

Trade-offs

Una ficha con barra lateral, no un asistente paso a paso

  • Descartado: un asistente lineal que obliga a completar cada fase para pasar a la siguiente.
  • Por qué: el proceso real no es lineal. Hay esperas técnicas, reinicios e interrupciones, y varios perfiles trabajan a la vez.
  • Coste asumido: la ficha no guía al usuario nuevo. Lo compensa el estado de cada fase siempre visible.

Cambiar el estado cuesta un clic más

  • Descartado: cambio de estado directo desde el desplegable.
  • Por qué: en un servicio clínico cada cambio tiene responsable. El modal pide perfil, persona y fecha, con hoy por defecto.
  • Coste asumido: un paso más en la acción más frecuente. Lo aceptaron los propios usuarios: les ahorra preguntar después.

Quince colores de estado, no una escala de tres

  • Descartado: reducir los estados a pendiente, en curso y hecho.
  • Por qué: «propuesto» y «confirmado», o «hecho» y «revisado por pares», son decisiones clínicas distintas. Agruparlos ocultaba justo lo importante.
  • Coste asumido: el color no basta para distinguirlos. Cada estado lleva siempre icono y texto.

Tablas editables en línea, no formularios en modal

  • Descartado: un modal por fila para editar las tablas de configuración.
  • Por qué: los radiofísicos ajustan valores comparando filas: duración de sesión, complejidad, asignación de aceleradores.
  • Coste asumido: estados de solo lectura, deshabilitado y edición dentro de la misma celda. Más casos que diseñar y probar.

Evolución: de lógica a interfaz

  • Mar 2025 · Auditoría y modo oscuro. Inventario de pantallas, fichas por pestañas y variables de color revisadas para el tema oscuro.
  • Jun 2025 · Fundamentos. Tokens de color, 15 estados, fondos y escala tipográfica. Con ellos, la nueva ficha de paciente fase a fase.
  • Sep – Oct 2025 · Departamento. Recursos humanos, tecnologías, turnos y tablas, y el calendario de citas.
  • Nov – Dic 2025 · Operación diaria. Citas manuales, filtros comunes y la nueva área Info en tiempo real.
  • Feb – Ago 2026 · Densidad y datos. Tablas editables, analítica por programa y ajustes finos de la administración del tratamiento.

04 — Solución final

Cada decisión, sobre la pantalla

Tres pantallas concentran el trabajo diario: la ficha, donde se decide; el listado, donde se prioriza; y la vista en tiempo real, donde se reacciona.

Ficha con la fase Definición de tratamiento abierta: campos de acelerador, patrón de fraccionamiento y revisión por pares. Paciente y datos clínicos ficticios.
  1. Visibilidad del estado (Nielsen #1)

    Las doce fases, siempre a la vista

    La barra lateral muestra cada fase con su estado en color, icono y texto. Se sabe dónde está el paciente sin abrir nada.

  2. Carga cognitiva

    Pestañas dentro de cada fase

    Consulta, definición y contorneado separan sus bloques en pestañas. Se ve solo lo que toca ahora, sin perder el contexto de la ficha.

  3. Prevención de errores (Nielsen #5)

    El estado se cambia con responsable

    El selector abre un modal con perfil, persona y fecha, con hoy por defecto. Ningún cambio queda sin firmar.

  4. Reconocer antes que recordar

    Campos que se repiten, piezas que se repiten

    Acelerador y fraccionamiento aparecen en la propuesta tentativa y en la definición. Son el mismo componente: se rellenan igual en las dos.

Listado en vista Timeline con filtros abiertos y una fila por paciente. Nombres e IDs ficticios.
  1. Flexibilidad (Nielsen #7)

    Dos vistas del mismo listado

    Lista para buscar a un paciente concreto; línea de tiempo para ver cuellos de botella entre fases. Cambiar de vista no pierde los filtros.

  2. Preatención

    El color del estado salta antes de leer

    Interrumpido en naranja y cancelado en carmesí destacan sobre azules y verdes. Lo que requiere acción se ve primero.

  3. Consistencia (Nielsen #4)

    Un solo patrón de filtros

    El mismo panel lateral en Pacientes, Programas e Info en tiempo real: abrir, filtrar y restablecer siempre en el mismo sitio.

Calendario del día por acelerador, con las citas coloreadas por estado y el detalle de una cita abierto. Pacientes ficticios.
  1. Ley de Hick

    Primero el recurso, después el detalle

    Recursos humanos o tecnológicos, y luego la máquina o la persona. Dos elecciones cortas en vez de un calendario con todo.

  2. Proximidad (Gestalt)

    Una columna por máquina

    Las citas de cada acelerador se leen en vertical. Un hueco libre o un retraso se ven como una ruptura del ritmo.

  3. Divulgación progresiva

    El tratamiento, a un clic

    Clasificación, complejidad y transporte en la cita; el tratamiento completo en «Ver información del tratamiento», sin salir del calendario.

05 — Resultados y aprendizajes

Menos preguntas en el pasillo

Resultados medidos en el servicio piloto seis meses después de desplegar la nueva ficha, frente a los tres meses anteriores, con pruebas de tarea y registros de uso.

−58 %

tiempo para localizar la fase en la que está bloqueado un paciente (de 94 s a 39 s de media).

100 %

de los cambios de estado con responsable y fecha registrados. Antes, un 41 %.

−3 días

de mediana entre consulta e inicio de tratamiento, al detectar antes las esperas técnicas.

SUS 79

de usabilidad percibida con 14 usuarios del servicio. La primera versión se quedaba en 58.

Lo que cambió en el servicio

  • La reunión diaria de coordinación se hace con la vista en tiempo real proyectada, no con una hoja de cálculo.
  • Las pantallas nuevas se montan con piezas existentes: Info en tiempo real salió sin componentes propios de interfaz.
  • La revisión por pares dejó de ir por correo: queda registrada en la propia fase.

Retrospectiva

  • Diseñar con el vocabulario del usuario. Intentar simplificar términos clínicos generó más dudas que ayuda. La claridad venía de la estructura, no de las palabras.
  • Fundamentos antes que pantallas. Sin tokens, el modo oscuro se hizo dos veces. Con ellos, cada pantalla nueva nació en los dos temas.
  • La deuda también se escribe. Parte de las etiquetas de estado siguen en inglés en la versión española y conviven dos librerías de gráficas. Están listadas, no olvidadas.
  • Lo siguiente. Llevar el color de estado más allá del color: patrones o formas para quien no distingue bien el naranja del carmesí.

Del formulario al recorrido

Phenyx Health dejó de ser un conjunto de formularios por fase para convertirse en una herramienta que muestra el recorrido completo de cada paciente. Un sistema de estados con color, icono y responsable, una ficha única y piezas compartidas que permiten al servicio crecer sin rediseñar cada pantalla.