KHRONOS · Responsive Design · UX / UI · Work OS
Plataforma interna multi-rol diseñada para la Gerencia de Sistemas de Salud Digna, que hace del proceso correcto el único camino posible: desde la requisición hasta el cierre en producción.
Ver Prototipo
EL PROBLEMA
Cinco roles distintos — Product Owner, Consultor de Producto, Diseñador UX, Desarrollador y QA Tester — operaban con criterios de aceptación implícitos, sin visibilidad cruzada y con comunicación distribuida en chats y correos. El resultado era entregas que llegaban a producción con defectos, retrabajo constante y responsabilidades difusas cuando algo fallaba.
LA SOLUCIÓN
Product Owner
Tres gates secuenciales — aprobación de requisitos, aprobación de diseño y autorización a producción — que solo el PO puede desbloquear. Ningún equipo puede saltarse la fase anterior.
Criterios de Aceptación
Una vez que el PO firma los criterios de aceptación, quedan bloqueados con atribución completa. Nadie puede modificarlos sin iniciar una nueva revisión trazable.
Diseñador UX
El diseñador visualiza las discrepancias entre diseño y desarrollo en tarjetas Figma con hilos de comentarios por tarea, directamente en su tablero de trabajo.
Desarrollador
Ninguna tarea puede aceptarse sin estimación previa. El sistema lanza alertas automáticas cuando el tiempo real supera en 50% lo estimado.
QA
QA trabaja con tabs específicos: Pendiente de prueba, En prueba, Aprobado y Regresión — cada uno mostrando solo las tareas relevantes al estado desde la perspectiva del tester.
Cierre y Garantía
El ciclo de vida termina con un Acta de Cierre con firmas digitales de los 5 roles y un contador de garantía de 90 días. El estado "Cerrado" es automático, nunca manual.
CONTEXTO
Imagina esto: un desarrollador empieza a codificar una funcionalidad basándose en criterios de aceptación anotados en un chat de WhatsApp o en un documento de Word. Dos semanas después, el diseñador señala que el flujo no corresponde a los diseños aprobados. El PO no tiene registro de qué versión de los criterios fue la definitiva. El proyecto regresa tres pasos y nadie puede establecer con certeza quién aprobó qué.
"Llegamos a producción con defectos que ya habíamos identificado en diseño, pero no había una forma clara de bloquear el avance si algo no estaba aprobado."— Entrevista con Diseñador UX, Gerencia de Sistemas · Salud Digna
Como Líder de Diseño UX en la Gerencia de Sistemas, conocía de primera mano las fricciones del proceso. Eso me permitió abordar la investigación con empatía real y con hipótesis concretas que validar — no supuestos genéricos sobre "falta de comunicación".
Khronos nació de la pregunta:¿qué pasaría si el sistema mismo hiciera imposible saltarse un paso crítico?
INVESTIGACIÓN
Realicé entrevistas individuales con los cinco roles clave del proceso, complementadas con observación contextual directa. El acceso al equipo me permitió recopilar evidencia de primera mano sobre los puntos de quiebre del flujo actual — sin intermediarios y con confianza establecida.
Agrupé los hallazgos de las entrevistas en seis clusters que definen los problemas centrales del proceso:
Evaluamos Jira, Linear y Monday contra los procesos internos para identificar por qué ninguna herramienta comercial era suficiente:
La primera pregunta que nos hicimos fue: ¿Por qué construir si podemos comprar? Evaluamos tres plataformas líderes. Aquí está lo que encontramos.
| Capacidad requerida | Jira / Linear | Monday | Khronos |
|---|---|---|---|
| Criterios de aceptación con autoría bloqueada por rol | No nativo | No nativo | Nativo |
| Compuertas obligatorias de PO que bloquean avance | Configurable con scripts | Parcial | Nativo |
| Estimación desglosada por componente y rol | Nativo | ||
| Bandeja diferenciada por rol (Diseñador vs Dev vs QA) | Vistas personalizadas | Filtros manuales | Por diseño |
| Acta de cierre con firmas digitales por rol | Nativo | ||
| Período de garantías con bugs de producción priorizados | Nativo | ||
| Costo de adopción (sin configuración) | Bajo | Bajo | Inversión inicial mayor |
DEFINICIÓN
Creé personas compactas basadas en los cinco roles del proceso. No son arquetipos genéricos: son representaciones directas de las personas con quienes trabajé, con sus métricas de éxito personales y sus frustraciones centrales.
Product Owner
Carlos Mendoza
Necesita trazabilidad total de decisiones y que nadie avance sin su aprobación explícita en cada gate.
Consultora
Sofía Ramírez
Necesita un tablero que le muestre el estado real de sus proyectos asignados sin depender de actualizaciones manuales del equipo.
Diseñador UX
Diego Torres
Necesita que los criterios de diseño aprobados sean inmutables y que las discrepancias queden vinculadas a las tareas específicas.
Desarrollador
Andrés Vega
Necesita claridad sobre qué tareas están listas para desarrollar y no recibir cambios de alcance una vez iniciada la estimación.
QA Tester
Valentina Cruz
Necesita recibir builds completas con criterios de aceptación documentados, sin tener que rastrear qué versión probar.
El Journey Map del estado actual mostró con precisión dónde se rompía el proceso inter-rol: los momentos más críticos eran el paso de requisitos a diseño (sin criterios formalizados), el paso de diseño a desarrollo (sin aprobación bloqueante) y el paso a producción (sin autorización explícita del PO).
| Rol | Creación | Análisis | Diseño | Desarrollo | Testing | Cierre |
|---|---|---|---|---|---|---|
CM |
Crea el proyecto y asigna al equipo por correo o reunión. | Recibe el req por correo. Aprueba verbalmente o por chat. Sin registro formal |
Se entera del avance del diseño cuando alguien le manda el link de Figma por WhatsApp. Sin visibilidad |
Sin participación en esta fase | Recibe solicitud de cierre sin resumen de QA ni historial de bugs. Aprueba a ciegas |
Firma un Word por correo. No hay cadena de custodia auditable. Cierre informal |
SR |
Sin participación en esta fase | Escribe requerimientos y criterios en un documento Word compartido. | No sabe si Diego está usando la versión correcta de los criterios. Sin fuente única |
Se entera del desvío de estimación cuando ya empezó el desarrollo. No puede renegociar. Desvío tardío |
No sabe si QA está probando contra los criterios que ella definió. | Participa en la revisión final si es convocada. |
DT |
Sin participación en esta fase | Sin participación en esta fase | Diseña en Figma y manda el link a Dev sin esperar confirmación del PO. | El PO pide cambios después de que Dev ya implementó. Re-trabajo. Re-trabajo evitable |
Sin participación activa en esta fase | Sin participación activa en esta fase |
CV |
Sin participación en esta fase | Sin participación en esta fase | Sin participación en esta fase | Recibe el req y estima sin conocer la expectativa de la Consultora. Avanza sin estándar de "terminado". Sin referencia de estimación |
Recibe bugs de QA. Algunos son trabajo incompleto, no defectos reales. Sin DoD acordada |
Corrige bugs de producción cuando le avisan, sin prioridad definida. |
VC |
Sin participación en esta fase | Sin participación en esta fase | Sin participación en esta fase | Sin participación en esta fase | Prueba contra un Word desactualizado. No puede distinguir bugs reales de trabajo incompleto. Sin fuente única de criterios |
Reporta bugs en producción al backlog general. Tardan meses en atenderse. Sin responsable ni prioridad |
Creación
Crea el proyecto y asigna al equipo por correo o reunión.
Análisis
Recibe el req por correo. Aprueba verbalmente o por chat.
Sin registro formal
Diseño
Se entera del avance del diseño cuando alguien le manda el link de Figma por WhatsApp.
Sin visibilidad
Desarrollo
Sin participación en esta fase
Testing
Recibe solicitud de cierre sin resumen de QA ni historial de bugs.
Aprueba a ciegas
Cierre
Firma un Word por correo. No hay cadena de custodia auditable.
Cierre informal
Creación
Sin participación en esta fase
Análisis
Escribe requerimientos y criterios en un documento Word compartido.
Diseño
No sabe si Diego está usando la versión correcta de los criterios.
Sin fuente única
Desarrollo
Se entera del desvío de estimación cuando ya empezó el desarrollo. No puede renegociar.
Desvío tardío
Testing
No sabe si QA está probando contra los criterios que ella definió.
Cierre
Participa en la revisión final si es convocada.
Creación
Sin participación en esta fase
Análisis
Sin participación en esta fase
Diseño
Diseña en Figma y manda el link a Dev sin esperar confirmación del PO.
Desarrollo
El PO pide cambios después de que Dev ya implementó. Re-trabajo.
Re-trabajo evitable
Testing
Sin participación activa en esta fase
Cierre
Sin participación activa en esta fase
Creación
Sin participación en esta fase
Análisis
Sin participación en esta fase
Diseño
Sin participación en esta fase
Desarrollo
Recibe el req y estima sin conocer la expectativa de la Consultora. Avanza sin estándar de "terminado".
Sin referencia de estimación
Testing
Recibe bugs de QA. Algunos son trabajo incompleto, no defectos reales.
Sin DoD acordada
Cierre
Corrige bugs de producción cuando le avisan, sin prioridad definida.
Creación
Sin participación en esta fase
Análisis
Sin participación en esta fase
Diseño
Sin participación en esta fase
Desarrollo
Sin participación en esta fase
Testing
Prueba contra un Word desactualizado. No puede distinguir bugs reales de trabajo incompleto.
Sin fuente única de criterios
Cierre
Reporta bugs en producción al backlog general. Tardan meses en atenderse.
Sin responsable ni prioridad
Creación
😐 Neutral — Flujo guiado de 3 pasos con equipo inteligente
Análisis
🙂 Baja — Criterios en sistema · bloqueados al aprobar · fuente única
Diseño
😟 Media — Strip visual de aprobación · botón bloqueado hasta PO aprueba
Desarrollo
😫 Alta — Estimación obligatoria 2×2 · alerta al superar 50% · DoD 5 puntos
Testing
😡 Muy alta — Criterios de solo lectura · timestamp por verificación · DoD como guardia
Cierre
😫 Alta — Acta de cierre con 4 firmas · garantías 90 días · bugs a Dev con prioridad alta
Journey Map: flujo pre-Khronos — 5 roles × 6 fases del proceso.
IDEACIÓN
De la pregunta de diseño a la decisión
¿Cómo podríamos...?
Hacer que cada rol sepa en tiempo real en qué fase está cada req y quién tiene la acción pendiente
Seleccionada
Bandeja personalizada por rol con strip visual de estado en cada card
Seleccionada
Bandeja personalizada donde el estado del req es visible en la card — sin abrir nada. El strip cambia de color según la fase: sin acción, esperando PO, aprobado.
Garantizar que los criterios acordados no puedan modificarse después de la aprobación del PO
Seleccionada
Criterios bloqueados e inmutables al aprobarse — ningún rol puede editarlos
Seleccionada
Los criterios quedan en modo solo lectura para todos los roles al recibir la aprobación del PO. Muestran atribución, fecha y quién los aprobó. No hay excepción.
¿Cómo podríamos...?
Hacer que saltarse una aprobación sea estructuralmente imposible, sin depender de la disciplina del equipo
Seleccionada
Botones de avance deshabilitados hasta que el PO apruebe — con guard explicativo visible
Seleccionada
3 compuertas en el flujo donde el sistema bloquea el avance hasta recibir aprobación. El botón muestra el motivo del bloqueo — no desaparece, informa.
¿Cómo podríamos...?
Alertar sobre desvíos de estimación antes de que el trabajo comience, no cuando ya es tarde
Seleccionada
Estimación obligatoria antes de aceptar · comparativa en tiempo real · alerta automática al superar 50%
Seleccionada
Bloque de estimación desglosada obligatorio al aceptar una tarea. Muestra la estimación del Consultor al lado. Si el desvío supera el 50%, la alerta aparece antes de confirmar.
¿Cómo podríamos...?
Definir un estándar de "terminado" que todos los roles entiendan igual y que el sistema verifique antes de avanzar
Seleccionada
Checklist de Definition of Done con 5 puntos obligatorios — botón de envío bloqueado hasta completarlos
Seleccionada
DoD con 5 puntos que Dev debe verificar antes de enviar a QA. El botón "Enviar a Testing" está deshabilitado hasta completar el checklist. Badge "DoD completa" visible para QA.
¿Cómo podríamos...?
Garantizar que cada entrega a producción tenga una cadena de custodia auditable y formalmente firmada
Seleccionada
Acta de cierre generada automáticamente con 4 firmas digitales + garantías de 90 días activadas en el sistema
Seleccionada
Al autorizar producción el sistema genera el acta automáticamente, activa 90 días de garantía y asigna bugs a Dev con prioridad alta. El cierre es automático al día 90.
Una de las decisiones de diseño más importantes fue establecer estados del proyecto que no pudieran coexistir, eliminando la contradicción de "cerrado hoy + 78 días de garantía restantes".
En Proceso
Desarrollo activo, gates pendientes
En Producción
Lanzado · Garantías activas (90 días)
Garantías vencidas
Día 90+ · Sin soporte activo
Cerrado
Estado automático, nunca manual
El mapa del sistema se organizó por rol, no por módulo: cada usuario tiene un punto de entrada único y solo accede a las secciones relevantes para su función en el proceso.
DISEÑO
Comencé con sketches de flujos clave por rol, priorizando acceso rápido al estado actual de cada proyecto y claridad sobre la acción disponible. La regla de diseño central: si un usuario no puede hacer algo, el sistema debe explicarle por qué — nunca simplemente ocultar el botón.
Partí de wireframes de baja y media fidelidad en Figma y desde ahí construí el prototipo interactivo completo.
🔍 Ver en tamaño completo
Wireframes low-fi en Figma — estructura y jerarquía visual por rol.
🔍 Ver en tamaño completo
Wireframes mid-fi en Figma — estructura y jerarquía visual por rol.
El sistema visual de Khronos prioriza la legibilidad del estado sobre la belleza. Las decisiones principales:
Color como señal de estado: Azul primario (#0091D6) para acciones principales, gris neutro para estados inactivos, rojo contenido para alertas de desviación. Sin color decorativo.
Tipografía Inter: Elegida por legibilidad a densidades de información alta — el sistema maneja muchas tareas simultáneas por tablero.
Tabs con estado visible: Cada rol navega su tablero con tabs que muestran contadores de tareas pendientes, haciendo visible la carga de trabajo sin necesidad de abrir cada sección.
Gates como componentes bloqueantes: Los gates de aprobación tienen un patrón visual consistente — siempre accesibles desde la vista PO, siempre bloqueantes para los demás roles hasta aprobación.
🔍 Ver en tamaño completo
Sistema de Diseño de Khronos
ITERACIONES
Realicé pruebas de usabilidad moderadas con los cinco roles del equipo, evaluando los flujos críticos: aprobación de requisitos por el PO, revisión de discrepancias por el diseñador, estimación y aceptación de tareas por el desarrollador, y registro de pruebas por QA.
01
Problema detectado: Los estados mostrados en el tablero del desarrollador incluían "En Revisión", que es un estado de la perspectiva del QA, no del Dev. 3/5 usuarios del rol Dev interpretaban mal su estado de trabajo.
Iteración: Mapeé exhaustivamente los estados desde cada perspectiva de rol. El tablero Dev ahora muestra exclusivamente "Sin estimar", "Listo para Dev", "En Desarrollo" y "Listo para QA".
Antes
Después
02
Problema detectado: En prueba con el PO, un proyecto aparecía simultáneamente como "Cerrado hoy" y con "78 días restantes" de garantía — una contradicción lógica que generaba desconfianza en los datos del sistema.
Iteración: Redefiní el ciclo de vida completo con 4 estados mutuamente excluyentes. "Cerrado" pasó a ser un estado automático posterior al día 90 de garantías, eliminando la posibilidad de estados contradictorios.
Antes
Después
03
Problema detectado: El diseñador no diferenciaba a primera vista entre la tab "Bandeja" (tareas nuevas) y "En Diseño" (tareas activas). 2/5 usuarios del rol abrían la tab incorrecta al iniciar su jornada.
Iteración: Añadí contadores de tareas pendientes visibles en las tabs y un indicador de acción requerida en "Bandeja" cuando hay tareas sin aceptar.
Antes
Después
04
Problema detectado: 4/5 usuarios del rol Desarrollador intentaban editar los criterios de aceptación después de la aprobación del PO, interpretando los campos como editables.
Iteración: Implementé un estado visual explícito de "bloqueado" con ícono de candado, tooltip explicativo y badge con nombre del PO y fecha de firma. El campo cambia de apariencia completamente al firmarse.
Antes
Después
05
Problema detectado: 3/5 usuarios — de distintos roles — no identificaban de forma inmediata cuál era la acción principal esperada de ellos en el Acta de Cierre.
Iteración: Reorganicé la jerarquía visual del Acta: el botón de firma del rol activo es siempre el elemento más prominente de la pantalla, con los demás roles en estado secundario hasta completar su firma.
Antes
Después
RESULTADOS
Tras validar el prototipo con el equipo, Khronos pasó a operación en la Gerencia de Sistemas. Hoy los cinco roles trabajan sobre los mismos tres gates de aprobación, el sistema de discrepancias, la estimación obligatoria, el panel QA por estados y el Acta de Cierre con firmas digitales. El proceso que antes vivía en documentos ahora lo hace cumplir la plataforma, y resuelve las fricciones identificadas en la investigación sin generar burocracia nueva.
equipos del área de tecnología trabajan en Khronos
colaboradores usan la plataforma
roles con flujos de aprobación propios
tiempo de aprobación de tareas y gestión de proyectos
"Ahora está claro qué puede hacer cada quien y cuándo. Ya no tendríamos que adivinar si algo fue aprobado o no."— Product Owner, sesión de validación del prototipo · Salud Digna
Trazabilidad total de aprobaciones — los tres gates bloqueantes (requisitos, diseño, producción) eliminan la ambigüedad de "¿quién aprobó qué y cuándo" que generaba defectos llegando a producción.
Cero retrabajo por criterios reinterpretados — el bloqueo inmutable de criterios tras la firma del PO cierra la fuente principal de desvíos: nadie puede modificar lo ya aprobado.
Desviaciones detectadas antes de empezar, no a mitad de sprint — la estimación obligatoria con alerta automática al superar el 50% traslada la renegociación de alcance al momento en que aún es barata.
Cierre auditable, no informal — el Acta de Cierre con 4 firmas y garantía de 90 días reemplaza el cierre por Word y correo, dando trazabilidad real al ciclo de vida completo del proyecto.
Explora los flujos interactivos por rol
REFLEXIÓN FINAL
Trabajar embebido en el equipo es una ventaja de diseño real: el contexto elimina suposiciones y acelera la validación. También aprendí que diseñar restricciones —como los gates bloqueantes— requiere tanta empatía como diseñar libertades.
Desarrollar el módulo de reportes para el PO con métricas de velocidad por rol, integrar notificaciones en tiempo real cuando una tarea cambia de estado, y refinar la experiencia móvil para el desarrollador en campo.
Haber convertido un proceso implícito y fragmentado en un sistema que lo hace explícito y trazable — sin que se sienta como una auditoría. El feedback más valioso fue: "se siente como si siempre hubiera debido funcionar así".