Marco tenía 28 años y acababa de ser contratado como desarrollador de sistemas en una institución de salud pública. Lo habían advertido: el sistema actual era un laberinto anticuado, donde nada funcionaba del todo bien. Pero él, lleno de ilusión y un par de años de experiencia freelance, creyó poder enfrentarlo.

El primer día, el caos le dio la bienvenida. El sistema se caía con frecuencia, los reportes de pacientes se duplicaban y los datos... bueno, los datos aparecían donde no debían. “Solo mantenlo a flote”, le dijeron sus superiores. Pero Marco no quería ser un rescatista: él quería ser un arquitecto.

Todo empezó con una llamada de emergencia: una madre había llegado con su hijo a urgencias, pero el sistema no encontraba su expediente. Se había “perdido” entre archivos mal nombrados. El personal tuvo que buscar en papeles, improvisar. Minutos valiosos perdidos.

Esa noche, Marco no pudo dormir. No se trataba solo de líneas de código. Se trataba de personas.

Al día siguiente, pidió permiso para realizar un rediseño total del sistema. “Solo si puedes justificarlo”, fue la respuesta. Entonces comenzó su investigación: se sentó con médicos, recepcionistas, enfermeras. Preguntó, observó, escuchó.

Descubrió lo que nadie había documentado: los verdaderos requerimientos.

Diseñar no era solo codificar. Era entender para quién se hacía el sistema, qué esperaban, y cómo lo usarían. Marco tradujo sus hallazgos en objetivos claros:

• Minimizar errores de entrada de datos.

• Facilitar el acceso rápido a expedientes médicos.

• Hacer que el sistema fuera comprensible para todos los niveles del personal.

• Asegurar que los datos estuvieran seguros, organizados y disponibles.

Marco reescribió las especificaciones. Separó entradas de salidas. Rediseñó los formularios con campos claros y filtros inteligentes. Cada archivo tenía ahora una lógica detrás: nombres estándar, fechas, campos obligatorios.

Implementó interacciones con base de datos que prevenían duplicados y errores. Creó controles automáticos que alertaban si algo no concordaba. Estableció procedimientos: ¿qué hacer si un dato faltaba?, ¿cómo corregir un expediente?, ¿cuándo hacer respaldos?

Diseñó no solo un sistema, sino un puente entre lo digital y lo humano.

Durante semanas, Marco se enfrentó a comentarios como: “esto es muy complicado”, “antes era más rápido (aunque mal)”, o “no quiero aprender otra vez”. Fue su prueba más dura: entender que el usuario final es el verdadero cliente. No el jefe. No él mismo.

Inició sesiones breves de capacitación. Simplificó la interfaz. Recibió retroalimentación, ajustó. Escuchar le costó, pero valió la pena.

Un mes después, llegó otra emergencia similar. Esta vez, el expediente apareció en segundos. La doctora miró a Marco y sonrió: “Esto nos salvó tiempo… tal vez algo más.”

Marco supo que su trabajo no estaba en las pantallas, sino en lo que pasaba fuera de ellas. Su código era invisible, pero su impacto no.

El diseño de sistemas no es una tarea técnica. Es un acto de empatía. Es entender que cada línea de código puede cambiar la vida de alguien… o ponerla en riesgo. Marco aprendió que antes de diseñar sistemas, hay que diseñar intenciones.

Y tú, ¿estás diseñando para cumplir funciones o para transformar realidades?

Para saber más:

https://www.frexus.dev/post/diseno-de-sistemas-introduccion/

Marco tenía 28 años y acababa de ser contratado como desarrollador de sistemas en una institución de salud pública. Lo habían advertido: el sistema actual era un laberinto anticuado, donde nada funcionaba del todo bien. Pero él, lleno de ilusión y un par de años de experiencia freelance, creyó poder enfrentarlo.

El primer día, el caos le dio la bienvenida. El sistema se caía con frecuencia, los reportes de pacientes se duplicaban y los datos... bueno, los datos aparecían donde no debían. “Solo mantenlo a flote”, le dijeron sus superiores. Pero Marco no quería ser un rescatista: él quería ser un arquitecto.

Todo empezó con una llamada de emergencia: una madre había llegado con su hijo a urgencias, pero el sistema no encontraba su expediente. Se había “perdido” entre archivos mal nombrados. El personal tuvo que buscar en papeles, improvisar. Minutos valiosos perdidos.

Esa noche, Marco no pudo dormir. No se trataba solo de líneas de código. Se trataba de personas.

Al día siguiente, pidió permiso para realizar un rediseño total del sistema. “Solo si puedes justificarlo”, fue la respuesta. Entonces comenzó su investigación: se sentó con médicos, recepcionistas, enfermeras. Preguntó, observó, escuchó.

Descubrió lo que nadie había documentado: los verdaderos requerimientos.

Diseñar no era solo codificar. Era entender para quién se hacía el sistema, qué esperaban, y cómo lo usarían. Marco tradujo sus hallazgos en objetivos claros:

• Minimizar errores de entrada de datos.

• Facilitar el acceso rápido a expedientes médicos.

• Hacer que el sistema fuera comprensible para todos los niveles del personal.

• Asegurar que los datos estuvieran seguros, organizados y disponibles.

Marco reescribió las especificaciones. Separó entradas de salidas. Rediseñó los formularios con campos claros y filtros inteligentes. Cada archivo tenía ahora una lógica detrás: nombres estándar, fechas, campos obligatorios.

Implementó interacciones con base de datos que prevenían duplicados y errores. Creó controles automáticos que alertaban si algo no concordaba. Estableció procedimientos: ¿qué hacer si un dato faltaba?, ¿cómo corregir un expediente?, ¿cuándo hacer respaldos?

Diseñó no solo un sistema, sino un puente entre lo digital y lo humano.

Durante semanas, Marco se enfrentó a comentarios como: “esto es muy complicado”, “antes era más rápido (aunque mal)”, o “no quiero aprender otra vez”. Fue su prueba más dura: entender que el usuario final es el verdadero cliente. No el jefe. No él mismo.

Inició sesiones breves de capacitación. Simplificó la interfaz. Recibió retroalimentación, ajustó. Escuchar le costó, pero valió la pena.

Un mes después, llegó otra emergencia similar. Esta vez, el expediente apareció en segundos. La doctora miró a Marco y sonrió: “Esto nos salvó tiempo… tal vez algo más.”

Marco supo que su trabajo no estaba en las pantallas, sino en lo que pasaba fuera de ellas. Su código era invisible, pero su impacto no.

El diseño de sistemas no es una tarea técnica. Es un acto de empatía. Es entender que cada línea de código puede cambiar la vida de alguien… o ponerla en riesgo. Marco aprendió que antes de diseñar sistemas, hay que diseñar intenciones.

Y tú, ¿estás diseñando para cumplir funciones o para transformar realidades?

Para saber más:

https://www.frexus.dev/post/diseno-de-sistemas-introduccion/