Repository navigation
Usability Testing
Esta página describe el protocolo planeado para las pruebas de usabilidad de Sentinel. Es importante aclarar desde el inicio que en el Sprint 2 únicamente se planea el protocolo: la ejecución real con usuarios se hará durante el Sprint 3, según pide el documento maestro.
Las pruebas automáticas verifican que el código hace lo que dice que hace, pero no nos dicen nada sobre si un ingeniero de guardia (oncall) realmente entiende qué está pasando cuando abre el dashboard a las 3 de la mañana. Para responder esa pregunta hay que sentar a usuarios reales frente al producto y observarlos.
El objetivo concreto es validar que un ingeniero DevOps o SRE pueda identificar, entender y resolver un incidente sin entrenamiento previo, en menos de 5 minutos por flujo. Si no lo logramos, el producto no resuelve el problema que prometimos resolver.
Vamos a invitar a 6 personas con perfiles distintos para tener triangulación de feedback:
Tres ingenieros SRE o DevOps con uno a tres años de experiencia. Esta es nuestra audiencia primaria. Si ellos no entienden el dashboard, el producto no funciona.
Dos estudiantes de últimos semestres con experiencia básica en Docker. Nos sirven para evaluar la curva de onboarding: si alguien junior puede usar la herramienta, eso valida que el sistema reduce la dependencia de expertos.
Una sesión con Leon Daniel Jaramillo, el Product Owner de SoftServe. Esta sesión es presencial y sirve para validar el ajuste con la visión del cliente.
Antes de las sesiones definimos cuatro hipótesis específicas, cada una con una forma concreta de validarse:
La primera es que el usuario identifica el incidente más crítico en menos de 10 segundos al abrir el dashboard. Lo medimos cronometrando el tiempo hasta el primer click sobre el incidente correcto.
La segunda es que el usuario entiende la causa raíz propuesta por el agente sin necesidad de abrir documentación externa. Lo medimos pidiéndole que describa la causa con sus propias palabras y comparándolo con lo que el agente realmente concluyó.
La tercera es que el usuario aprueba o rechaza una acción con confianza, sin decir cosas como "no sé qué hace este botón". Lo medimos con observación directa más un cuestionario de uno a cinco después de cada tarea.
La cuarta es que el flujo aprobación a ejecución a verificación se percibe como una sola pantalla, no como módulos separados. Esta es importante porque uno de los principios arquitectónicos de Sentinel es que los Labs son fases internas, no pantallas separadas para el usuario. Lo validamos con una pregunta directa al final de la sesión.
Además de las hipótesis cuantitativas, hay preguntas más abiertas que queremos responder con la observación cualitativa:
¿El layout deja claro dónde está el usuario, qué incidente está mirando y en qué fase va el agente? ¿El razonamiento del agente, que viene en markdown, es legible o se siente demasiado técnico? ¿El nivel de riesgo que muestra el modal de aprobación es comprensible antes de aprobar, o el usuario aprueba sin entender? ¿El timeline del incidente cuenta una historia coherente o es solo una lista de eventos? ¿Los runbooks que muestra el visor aportan valor o son ruido visual?
Las tareas están redactadas como objetivos del usuario, no como instrucciones paso a paso. La idea es ver cómo navega el usuario por su cuenta, no validar que pueda seguir un instructivo.
Tarea 1: triaje rápido. "Acabas de iniciar tu turno de oncall. Abre el dashboard y dime cuál de los incidentes activos atenderías primero y por qué". Tiempo objetivo menos de un minuto. Criterio de éxito: selecciona un incidente con severidad critical o el más reciente sin atender.
Tarea 2: entender un incidente. "Selecciona el incidente de app-demo. Cuéntame con tus palabras qué pasó y qué propone el sistema". Tiempo objetivo menos de dos minutos. Criterio de éxito: menciona el tipo de incidente, la causa raíz y al menos una acción propuesta.
Tarea 3: aprobar una acción. "El sistema propone reiniciar el contenedor. Decide si la apruebas o no, y explica tu razonamiento". Tiempo objetivo menos de un minuto. Criterio de éxito: lee el riesgo, revisa el comando, deja un comentario y toma una decisión informada.
Tarea 4: crear un incidente manualmente. "Recibiste una llamada del cliente reportando un fallo en su base de datos customers. Crea el incidente en Sentinel". Tiempo objetivo menos de dos minutos. Criterio de éxito: llena título, target con formato postgres/customers, severidad high y guarda.
Tarea 5: revisar incidentes pasados similares. "Encuentra si este tipo de incidente ya había ocurrido antes". Tiempo objetivo menos de un minuto. Criterio de éxito: localiza la sección de incidentes similares y abre uno.
Los criterios de evaluación son medibles y combinan lo cuantitativo con lo cualitativo:
La tasa de éxito por tarea, calculada como porcentaje de usuarios que completan cada tarea, debe ser de al menos 80%. El tiempo promedio por tarea debe estar dentro del tiempo objetivo definido. Los errores críticos, entendidos como pasos que llevan a abandono o frustración visible, deben ser máximo uno por sesión.
Aplicaremos el cuestionario SUS (System Usability Scale), que es estándar en la industria, y esperamos un puntaje mínimo de 70 sobre 100, que es el umbral de "buena usabilidad" en la literatura.
También aplicaremos un NPS interno con la pregunta "¿Recomendarías esta herramienta a un colega oncall?" en escala de 0 a 10, esperando un mínimo de 7.
Los comentarios cualitativos del observador se analizarán por temas para identificar patrones, no como anécdotas sueltas.
Las sesiones son remotas a través de Microsoft Teams con compartir pantalla, excepto la del PO que es presencial. Cada sesión dura 45 minutos: 5 de introducción, 25 de tareas, 10 de cuestionario y 5 de preguntas abiertas.
Las sesiones se graban con consentimiento explícito (audio y pantalla), porque revisar la grabación después permite capturar detalles que el observador no alcanzó a notar en vivo.
Nicol Garcia Tabares es la moderadora, encargada de guiar al usuario sin influir en sus decisiones. Jacobo Montes es el observador, encargado de tomar notas estructuradas mientras la moderadora se enfoca en el usuario. Esta separación de roles es importante porque mezclarlos suele degradar la calidad de ambas.
El entorno de pruebas es una instancia de staging con 10 incidentes ficticios sembrados, para que todos los participantes vean exactamente el mismo estado del sistema y los resultados sean comparables.
La fecha estimada de ejecución es la semana del 13 de mayo de 2026, dentro del Sprint 3.
La sesión arranca con una bienvenida de dos minutos donde se explica el contexto del proyecto y se aclara algo crucial: no se evalúa al usuario, se evalúa al producto. Esto reduce la ansiedad y mejora la calidad del feedback.
Luego viene el consentimiento firmado para grabar. Después una pregunta inicial de tres minutos sobre el rol del participante y su experiencia con herramientas similares como PagerDuty, Datadog o Grafana, que sirve para contextualizar sus reacciones.
Después vienen las cinco tareas, 25 minutos en total, con la técnica de "pensar en voz alta": el usuario va narrando lo que ve y lo que piensa hacer, sin recibir ayuda salvo si se bloquea totalmente.
Al terminar las tareas se aplica el cuestionario SUS más NPS, en cinco minutos. La sesión cierra con cinco minutos de preguntas abiertas: qué cambiarías, qué falta, lo usarías mañana en tu trabajo real.
Después de las sesiones, consolidamos las métricas cuantitativas en una hoja de cálculo y triangulamos con las citas literales de los participantes. La idea no es generar un reporte interminable, sino destilar entre tres y cinco hallazgos accionables, priorizados por severidad alta, media o baja.
Los hallazgos se presentan en la retrospectiva del Sprint 3 para que el equipo decida cuáles entran en el Sprint 4 como ajustes al producto.
Antes del 13 de mayo necesitamos tener: los datos sembrados en Supabase con 10 incidentes variados, las cuentas de prueba creadas para cada participante, la plantilla de notas del observador, el cuestionario SUS preparado en Google Forms, el calendario de sesiones agendado con cada participante, y los consentimientos firmados en formato digital.
El documento de referencia completo, con la versión más detallada de este protocolo, está en docs/sprint2-pruebas/03-protocolo-pruebas-usabilidad.md dentro del repositorio.