¿Quién debe probar el prototipo de un sistema interno?
Pruebe el prototipo con quienes van a operar el sistema todos los días, y no solo con quienes aprueban el presupuesto. Una demo para la dirección mide si la idea convence. Cinco sesiones cortas con operadores reales, con tareas reales, muestran dónde se traba el sistema, y eso es lo que sostiene la decisión de invertir.
¿Por qué no basta una demo para la dirección?
Porque prueba persuasión, no uso. En una demo, quien conoce el prototipo conduce los clics, usa datos limpios y sigue el camino feliz. La dirección ve una pantalla que funciona. El operador, un martes a las cuatro de la tarde, tendrá un registro incompleto, un cliente que no está en la lista y un caso urgente que no cabe en el flujo diseñado.
Esto no es una falla de quien aprueba. Aprobar es un trabajo legítimo, y la dirección necesita ver el conjunto. El problema es usar la aprobación como si fuera la prueba. Son dos preguntas distintas: la dirección pregunta "¿esto resuelve el problema del negocio?", y el operador pregunta "¿esto cabe en mi día sin retrasarme?". Solo la segunda decide si el sistema se usa.
Si usted lidera innovación, hay un agravante. Quien firma suele ser a quien más fácil llega. Quienes operan suelen estar en un área que no le reporta. Probar con el grupo que queda a mano es el camino natural, pero es el que menos informa sobre el uso real.
¿Qué dice la investigación sobre cuántos usuarios probar?
Dice que pocas personas de un mismo perfil ya revelan buena parte de los problemas, y que el perfil importa más que el número. Los datos tienen límites, y conviene decirlos a la vez.
Jakob Nielsen, en un artículo de 2000 del Nielsen Norman Group, usa la fórmula N(1 - (1 - L)^n), donde L es la parte de los problemas que encuentra un solo usuario. En los proyectos que él y Thomas Landauer estudiaron, L promedió 31%. Con ese valor, cinco usuarios encuentran cerca del 85% de los problemas, y después del quinto los hallazgos empiezan a repetirse. Nielsen recomienda dividir el presupuesto de pruebas en rondas: probar con cinco, corregir, volver a probar con otros cinco, porque una corrección puede no funcionar o crear un problema nuevo.
El mismo artículo trae la salvedad que más importa aquí. La fórmula vale para usuarios comparables. Cuando el sistema sirve a grupos muy distintos, hay que probar cada grupo, con 3 a 4 usuarios por grupo cuando son dos.
Laura Faulkner, en un estudio de 2003 en Behavior Research Methods, Instruments, & Computers, probó con 60 usuarios y sorteó conjuntos a partir de ellos. Algunos conjuntos de cinco encontraron el 99% de los problemas, otros solo el 55%. Con diez usuarios, el peor conjunto subió al 80%, y con veinte, al 95%. La lectura práctica: cinco es un punto de partida barato, pero la variación es grande, y un grupo operativo heterogéneo pide más gente.
Ambos trabajos miden problemas de usabilidad encontrados en una prueba. No miden si el sistema encaja en el proceso ni si después aparece un resultado de negocio. La cifra de Nielsen es de 2000 y viene de los proyectos que él estudió, no de los sistemas internos de una empresa concreta. Úsela como orden de magnitud para planificar la ronda, no como promesa.
¿Y la evidencia sobre involucrar al usuario en el diseño?
Es favorable, pero limitada. Bano y Zowghi publicaron en 2013 una revisión sistemática de 87 estudios empíricos publicados entre 1980 y 2012. Solo 13 investigaron específicamente la participación del usuario en la ingeniería de requisitos. De ellos, 9 confirmaron beneficios y 4 no fueron concluyentes.
Ese resultado no aísla el prototipo, y la revisión trata de requisitos, no de pruebas. Nuestra lectura, que no sale del estudio: el costo de escuchar a cinco operadores antes de construir es pequeño frente al costo de descubrir el mismo problema después de la puesta en marcha, con el sistema pagado y el equipo volviendo a la hoja de cálculo.
¿Quién debe estar en la sala y con qué papel?
Tres papeles, con funciones distintas. El operador prueba: es quien hará la tarea todos los días y quien sabe qué pasa cuando el caso se sale del patrón. El jefe directo prueba la vista de control, el informe y la pantalla que usa para seguir los resultados. El aprobador observa, de preferencia sin hablar, porque ver al operador trabarse suele convencer más que un argumento de presentación.
Tres reglas cambian la calidad de la prueba. Use datos reales, anonimizados si hace falta, porque un prototipo con datos de ejemplo nunca se topa con el registro torcido. Pida tareas sacadas de la semana real del operador, no un guion que el prototipo ya sabe superar. Y no ayude: cada vez que alguien explica qué hacer, la prueba pierde el punto en que el sistema, solo, no se explica.
Cada sesión debe dejar un registro breve: la tarea, si se completó sin ayuda, dónde se detuvo la persona y qué camino antiguo intentó usar en su lugar. Ese registro es lo que usted lleva a la dirección, y pesa más que una opinión sobre el prototipo.
Un ejemplo práctico: la recepción de la clínica
El escenario siguiente es hipotético. Las cifras y los resultados son supuestos ilustrativos, no mediciones. Una red de seis clínicas prototipa una agenda con verificación de autorización previa de la aseguradora. En la demo, la directora ve al paciente agendado, la autorización consultada y el documento de aprobación adjunto en pocos clics. Aprueba.
Ahora imagine cinco personas de recepción de clínicas distintas, cada una con la lista real del día. Dos se detienen en el mismo punto: el paciente llega sin el número de autorización, y el prototipo exige el campo para guardar. Su salida es anotarlo en papel y cargarlo después, que es justo el camino que el sistema debía reemplazar. Una tercera nota que la pantalla muestra la autorización, pero no el plazo que la aseguradora dio para usarla.
Ninguno de estos problemas apareció en la demo, porque quien conducía los clics nunca llegó sin el número. En este escenario, corregir el campo obligatorio en el prototipo es un ajuste de pantalla. Descubrirlo en producción es un papel en el mostrador y una hoja de cálculo paralela. La decisión de invertir pasa a apoyarse en lo que el operador logró hacer, no en lo que la dirección opinó de la pantalla.
¿Cómo organizar una ronda de pruebas en una semana?
Empiece por la definición, antes de cualquier sesión. Liste de cinco a ocho tareas reales de la semana del operador, elija el criterio de éxito de cada una (completada sin ayuda, tiempo hasta trabarse, camino antiguo usado) y registre el punto de partida del proceso actual. Sin esa cifra de referencia, el resultado de la prueba se vuelve opinión.
Después, invite a cinco operadores del mismo perfil y, si hay más de un perfil, repita el grupo. Sesiones de 45 minutos, una persona a la vez, con el aprobador y el jefe directo observando. Esa estimación de tiempo es nuestra recomendación de diseño, no una cifra de investigación. Al final de la semana, corrija lo que trabó a más de una persona y haga una segunda ronda con otros operadores, como sugiere Nielsen.
La prueba responde a la pregunta de usabilidad. La pregunta de arquitectura, de dónde viene el dato verdadero y qué pasa en la excepción, es otra distinta. En el caso de Reatop, la app móvil nativa con uso sin conexión se diseñó para quienes operan en campo, ligada a un backoffice integrado, y es el tipo de sistema en el que probar con la primera línea más importa.
Preguntas frecuentes
Mi equipo se resiste al cambio. ¿Poner operadores en la prueba no abre espacio a más resistencia?
En nuestra lectura, el efecto tiende a ser el contrario. Quien prueba ve su propio pedido de ajuste convertirse en un cambio del sistema, y eso crea apropiación. La resistencia que queda aparece pronto, cuando corregir es barato, y no después de la puesta en marcha. Elija operadores respetados por sus compañeros, no solo a los más entusiastas.
La implementación exigirá demasiado tiempo del equipo. ¿Se puede probar sin detener la operación?
Sí, si la ronda es corta. Cinco sesiones de 45 minutos, acordadas con el jefe directo, ocupan a cada operador menos de una hora. Ese dimensionamiento es una recomendación nuestra de diseño. El tiempo que cuesta la prueba es menor que el de mantener dos caminos después de la puesta en marcha.
No veo cómo medir el resultado de una prueba de prototipo. ¿Qué registro?
Registre por tarea: si se completó sin ayuda, dónde se detuvo la persona y qué camino antiguo intentó usar. Mida antes el proceso actual, para tener comparación. El registro no mide el retorno financiero del proyecto, pero muestra si el sistema cabe en la rutina, que es la condición para que aparezca cualquier retorno.
El siguiente paso
Si tiene un prototipo aprobado por la dirección y quiere entender qué no ha visto aún el operador en él, el Diagnóstico de Arquitectura Operacional, una conversación de 30 minutos, es una invitación para empezar: hable con Yowpi.
Cases relacionados
¿Reconociste tu operación en este artículo?
Agenda el Diagnóstico de Arquitectura Operacional: 30 minutos para mapear dónde está el cuello de botella de tu operación. Sin propuesta en la primera conversación.
Agendar diagnóstico