Rob Levine Legal Solutions · 2025 · Software de gestión de historias clínicas
Nova
Un sistema de historias clínicas que obligaba a saltar entre 7 pestañas se convirtió en un solo flujo, con 40% menos errores.
- −40% errores en solicitudes de historias clínicas
- −20% tiempo buscando la información de un caso
- US$5k al mes en reprocesos y retrasos evitados
- 7 pestañas →1 vista para completar una solicitud
- Producto
- Plataforma interna de gestión de historias clínicas
- Industria
- Legal / SaaS
- Rol
- Product Designer
- Duración
- 6 meses
- Equipo
- 3 desarrolladores full stack
- Alcance
- Investigación, arquitectura de información, UI, QA
Rediseñé el sistema con el que una firma de abogados gestiona miles de historias clínicas. Lo que antes exigía varias pestañas y pasos repetidos ahora vive en un solo flujo claro.
El problema
Un sistema que le costaba dinero a la firma
Cada error en una solicitud de historia clínica retrasaba un caso. Y el sistema hacía que equivocarse fuera demasiado fácil.
- 7 pestañas abiertas en una sola vista para gestionar una solicitud
- 3 veces aparecía “Records”, con significados distintos
- 16 filtros visibles a la vez, sin jerarquía
- 12.272 solicitudes en una lista sin prioridad ni estado claro
Antes
- Varias pestañas abiertas para completar un solo proceso
- Navegación confusa y poco intuitiva
- Pasos redundantes que causaban errores
- Sin forma clara de saber el estado de una solicitud
Después
- Un flujo lineal que agrupa las tareas relacionadas
- Arquitectura de información basada en el trabajo real
- Menos pasos y menos decisiones ambiguas
- Estado visible de cada solicitud, de un vistazo
El contexto
Una herramienta interna que no podía detenerse
Rob Levine Legal Solutions es una firma especializada en lesiones personales y casos médicos. Solicitar, gestionar y revisar historias clínicas es la columna vertebral de su operación, y cualquier retraso afecta los resultados de los casos, la satisfacción de los clientes y los ingresos.
Las restricciones
Nova es una herramienta interna que abogados, paralegales y personal administrativo usan todo el día. No se podía detener la operación para cambiarla, así que el rediseño tenía que convivir con el sistema anterior y entrar por partes. Trabajé con tres desarrolladores full stack durante 6 meses.
- Sin base de marca: la interfaz debía construirse sobre Bootstrap 5.
- Tres perfiles con tareas muy distintas sobre la misma información.
- Datos sensibles de salud: cada acción debía dejar rastro y confirmación.
- Lanzamiento gradual, sin capacitar de nuevo a todo el equipo.
Investigación
Entender la operación antes de dibujar una pantalla
-
01
Focus groups
Sesiones con todos los equipos para entender roles, responsabilidades y cómo circulan las historias clínicas.
-
02
Auditoría
Revisión completa del software: pasos redundantes, navegación confusa y saltos entre pestañas.
-
03
Arquitectura
Nueva arquitectura de información alineada con los flujos reales, validada con wireframes.
-
04
Sistema UI
Interfaz construida con ingeniería sobre Bootstrap 5, accesible según WCAG.
Lo que encontramos
-
01
Costaba encontrar funciones básicas, con pérdida de tiempo diaria.
-
02
Gestionar solicitudes requería varios pasos redundantes.
-
03
Acciones como editar cartas de solicitud eran manuales y propensas a errores.
-
04
No había confirmaciones claras del estado de cada acción.
-
05
La complejidad exigía mucha capacitación para cada persona nueva.
-
06
La falta de patrones consistentes aumentaba la carga cognitiva.
El hallazgo que cambió la arquitectura
“Para saber si una solicitud ya se pagó tengo que abrir tres pestañas y comparar a ojo.”
Por eso: el sistema estaba organizado por tipo de dato, pero el equipo trabaja por caso. Reorganizamos todo alrededor de la solicitud y del caso al que pertenece.
Decisiones clave
Dos decisiones que cambiaron el día a día
De 7 pestañas a una sola vista
- Problema
- Gestionar una solicitud obligaba a saltar entre 7 pestañas y copiar datos de una a otra.
- Hallazgo
- Las personas siempre recorrían las mismas 3 o 4 pestañas en el mismo orden.
- Decisión
- Un flujo lineal por solicitud, con el estado siempre visible arriba.
- Por qué
- Seguir el orden real del trabajo elimina los pasos redundantes, que eran el origen de la mayoría de los errores.
Anular sin sesgos
- Problema
- “Anular sin reembolso” se usaba por error y generaba pérdidas.
- Hallazgo
- Era el único botón verde de la pantalla: parecía la opción recomendada.
- Decisión
- Igualar la jerarquía, pedir el motivo dentro de cada acción y usar íconos y color según el riesgo.
- Por qué
- En una acción irreversible, la interfaz no debe empujar hacia ninguna opción: debe hacer que la persona piense.
Diseñar la experiencia
Tres piezas que cambiaron el trabajo del equipo
-
01
Un dashboard que antes no existía
Los reportes se descargaban a Excel para armar gráficas a mano. Ahora el rendimiento del equipo se ve en tiempo real.
-
02
Matters: todo el caso en un lugar
Una pantalla nueva que agrupa a los clientes de una misma familia o caso médico. Se acabó perder la conexión entre solicitudes.
-
03
Anular sin sesgos
El botón verde de “anular sin reembolso” parecía la opción recomendada y causaba pérdidas. Integré el motivo en cada acción, equilibré la jerarquía y agregué íconos.
Un sistema visual al servicio de la usabilidad
La firma no tenía una base de marca sólida, así que construí la interfaz sobre Bootstrap 5: implementación rápida, componentes consistentes y patrones accesibles. Cada decisión de tipografía, espaciado y contraste priorizó la legibilidad.
Tipografía
- H1 Título de ejemplo 40px
- H2 Título de ejemplo 32px
- H3 Título de ejemplo 28px
- H4 Título de ejemplo 24px
- H5 Título de ejemplo 20px
- H6 Título de ejemplo 16px
Color
- Primary
#2F6CF3 - Primary dark
#1553DC - Success
#28A745 - Danger
#DC3545 - Warning
#FFC107 - Gray 100
#F8F9FA - Gray 600
#6C757D - Gray 900
#212529
Botones
Validación
Probado con quienes lo usan todos los días
Hice pruebas de usabilidad con 8 personas del equipo: 3 abogados, 3 paralegales y 2 administrativos. Cada una completó las mismas 5 tareas en el sistema anterior y en el prototipo nuevo, y comparé tiempos, errores y dudas.
- Encontrar el estado de una solicitud: de 1 min 50 s a 25 s en promedio.
- Nadie eligió “anular sin reembolso” por error en el prototipo nuevo; en el anterior, 3 de 8 lo hicieron.
- El dashboard reemplazó el reporte manual en Excel desde la primera semana.
El resultado
Menos errores, menos tiempo, menos costos
-
−40%
errores en solicitudes de historias clínicas.
Cómo se midió: solicitudes devueltas o rehechas, 3 meses antes frente a 3 meses después del lanzamiento.
-
−20%
tiempo buscando la información de un caso.
Cómo se midió: tareas cronometradas en las pruebas, confirmadas con los registros de uso del sistema.
-
US$5k
al mes en reprocesos y retrasos evitados.
Cómo se midió: horas de reproceso ahorradas por la tarifa del equipo, más los costos por retrasos en los casos.
-
7 pestañas →1
vista para completar una solicitud.
Cómo se midió: comparación directa del flujo anterior y el nuevo.
Un proceso confuso y propenso a errores se convirtió en una herramienta ágil y confiable, que ahorra tiempo y dinero a la firma.
Reflexión
Lo que me llevo de este proyecto
Lo que aprendí
En una herramienta interna, el diseño se mide en errores evitados y minutos recuperados. Entender la operación con el equipo antes de dibujar fue lo que permitió cambiar la arquitectura sin frenar el trabajo diario.
Lo que haría distinto
Construiría el sistema de componentes antes de las pantallas. Partir de Bootstrap fue rápido, pero algunos patrones se resolvieron pantalla por pantalla y luego hubo que unificarlos.