Este caso pertenece al mismo ecosistema de salud y diabetes de Case 01. Por acuerdo de confidencialidad no podemos nombrar al cliente ni mostrar pantallas reales. Lo que se muestra aquí describe el problema, el razonamiento y las decisiones tal como ocurrieron. Si quieres el detalle completo, hablemos.
EL PROYECTO DE UN VISTAZO
EL PROBLEMA
Tener todos los datos no equivale a entenderlos.
HCP Client es la herramienta que un profesional sanitario abre para entender cómo evoluciona un paciente con diabetes. HbA1c, CGM, BG, picos de glucosa, y todo el contexto diario que explica esos números: comidas, ejercicio, otros eventos. La cantidad de datos disponible no era el problema. El problema era que tener todos esos datos no equivale a entenderlos en el tiempo real de una consulta.
Podíamos construir un producto técnicamente completo y aun así dejar al profesional sin saber dónde mirar primero. Esa era la trampa fácil de caer: confundir cobertura de datos con claridad.
No estábamos diseñando para una sola persona. HCP Client vivía dentro de un ecosistema donde convivían profesionales sanitarios leyendo esos datos, pacientes cuya información dependía de un registro correcto, el equipo que creaba y editaba fichas de paciente, otros equipos de producto construyendo sobre la misma base, y marcas distintas que necesitaban la misma solución con identidades diferentes. Optimizar para uno de esos grupos a costa de los demás habría sido más fácil y más barato. También habría sido un error.
DE VISUALIZAR DATOS A PRIORIZAR DECISIONES
¿Qué necesita decidir esta persona, y qué le hace falta ver para decidirlo?
Nuestro primer instinto habría sido preguntar: ¿cómo mostramos estos datos? Lo cambiamos por una pregunta distinta: ¿qué necesita decidir esta persona, y qué le hace falta ver para decidirlo?
La diferencia importa. Un dashboard que muestra todo es un dashboard que no ayuda a nadie a llegar antes a lo que importa. El objetivo de diseño se convirtió en una secuencia de preguntas que el sistema debía responder en orden: qué está pasando, dónde debería mirar, qué patrón explica esto, qué contexto necesito para interpretarlo.
Para el profesional sanitario, el objetivo nunca fue ver más datos. Fue entender mejor los datos que ya tenía delante, con margen para explorar más profundidad solo cuando la necesitara.
CUATRO DECISIONES QUE GUIARON EL DISEÑO
Cuatro decisiones que guiaron el diseño.
No todas las decisiones pesan lo mismo. Estas cuatro marcaron el producto más que el resto.
01
Jerarquizar antes de añadir.
No toda la información pesa lo mismo. Antes de decidir cómo mostrar un dato, decidíamos si merecía estar en la primera lectura o un nivel más abajo. Esa disciplina, aplicada de forma constante, es lo que separa un dashboard clínico útil de uno que solo parece completo.
02
Contextualizar en vez de aislar.
Un pico de glucosa sin contexto es un número. El mismo pico, conectado con la comida o el ejercicio que lo precedió, es una explicación. Diseñamos para que los valores clínicos aparecieran siempre junto al comportamiento diario que los rodeaba, no como capas separadas que el profesional tuviera que cruzar mentalmente.
03
Diseñar estados, no solo pantallas.
Loading, vacío, error, edición, confirmación, ausencia de datos: cada uno es una decisión de producto, no un detalle técnico que se resuelve después. Esto se volvió especialmente crítico en patient creation y patient edition, donde un estado mal diseñado no es solo una mala experiencia, es un riesgo sobre datos sensibles.
04
Patrones antes que excepciones.
Cada solución nueva pasaba por la misma pregunta: ¿esto fortalece el sistema o crea una excepción más para mantener? Un flujo de creación de pacientes bien resuelto revelaba necesidades que se repetían en formularios, validaciones y feedback en otras partes del producto. Esas decisiones volvían al design system de Case 01, y desde ahí alimentaban a otros equipos. El ciclo era el mismo en ambas direcciones: el producto alimentaba al sistema, y el sistema volvía a alimentar al producto.
LA VALIDACIÓN NO ERA UN PASO FINAL
El riesgo tenía que reducirse en cada capa, no solo al final.
En un producto clínico, esperar al usability test del final para descubrir que la jerarquía no funciona sale caro. El riesgo tenía que reducirse en cada capa, no solo al final.
Antes de validar una pantalla, validábamos el problema: ¿esto responde a una necesidad real del flujo clínico, o solo añade información porque la teníamos disponible? Antes de validar la interacción, validábamos la arquitectura: ¿la jerarquía deja encontrar primero lo más relevante? Y antes de dar por buena una solución, preguntábamos si el patrón funcionaba solo en esa pantalla o si podía sostenerse en el resto del ecosistema sin que otro equipo tuviera que reinventarlo.
Preferimos ser transparentes sobre esto: no vamos a citar aquí un número de test de usabilidad o un tamaño de muestra que no podamos documentar. Lo que sí podemos defender es el modelo de validación en sí, y cómo cambió la forma en que el equipo tomaba decisiones antes de escribir una sola línea de código.
RESULTADOS
El cambio estructural.
No tenemos cifras que podamos compartir bajo NDA, y preferimos decir eso claramente antes que dar un número que solo suene bien.
Lo que sí podemos defender es el cambio estructural. HCP Client dejó de diseñarse pantalla por pantalla y empezó a diseñarse como parte de un sistema con reglas compartidas: mismos criterios de jerarquía, mismos patrones de estado, misma lógica de contextualización, disponibles para cualquier equipo que construyera sobre la misma base. Patient creation y patient edition, que antes eran de los flujos con más ambigüedad del ecosistema, pasaron a tener validaciones y estados consistentes con el resto del producto.
Un profesional sanitario con cinco minutos de consulta necesita que el sistema haga parte del trabajo de priorizar por él. Ese fue siempre el criterio de éxito real, aunque no cupiera en una cifra.
QUÉ DEMUESTRA ESTE PROYECTO
La responsabilidad no termina cuando el flujo funciona en Figma.
Este caso resume algo que tratamos como principio, no como excepción: la responsabilidad del equipo de diseño no termina cuando el flujo funciona en Figma. Termina cuando entendemos qué decisión necesita tomar la persona al otro lado, qué restricciones tiene el negocio, qué puede sostener ingeniería, y qué parte de la solución merece convertirse en infraestructura reutilizable para el resto del ecosistema.
En HCP Client esa pregunta se repitió en cada capa: producto, interacción, sistema. La respuesta fue siempre la misma.
Un sistema complejo se vuelve comprensible cuando alguien decide, de forma consciente, dónde va la complejidad y dónde no.