2.3 · Prototipo
No pedimos que lo imaginen. Se lo enseñamos.
El prototipo existe para tomar una decisión antes de invertir en construir todo: si la solución resuelve la fricción, si la gente la usaría y si las reglas aguantan los casos reales. Es una herramienta de decisión, no una pieza de diseño.
Qué pregunta responde
Cada prototipo responde una pregunta. La pregunta define el tipo de prueba, y la prueba más barata que la responde es la correcta.
| Pregunta | Tipo de prueba | Cómo se ve |
|---|---|---|
| ¿Entienden el flujo? ¿Saben qué hacer? | Prototipo navegable | La demo funcional con datos de ejemplo, como las de naoro.mx/demos |
| ¿Las reglas producen la decisión correcta? | Repetición de casos | El motor de reglas corre sobre casos reales del último periodo |
| ¿Lo usarían en su trabajo diario? | Mago de Oz o servicio manual | La persona usa una interfaz real y el equipo hace a mano lo que el sistema haría |
| ¿La integración es posible? | Prueba técnica acotada | Una llamada real al ERP en su ambiente de pruebas, leer y escribir un registro |
| ¿El cliente ve el valor? | Demo con su caso | La prueba con sus datos (anonimizados) y su vocabulario, frente al patrocinador |
Estructura de la prueba
Toda demostración del prototipo sigue el mismo orden. El problema es el protagonista y la tecnología queda detrás.
- 01 · Fricción¿Qué no funciona bien?
- 02 · Hoy¿Cómo se hace hoy?
- 03 · Oportunidad¿Qué podría cambiar?
- 04 · PruebaDemo funcional
- 05 · Impacto¿Qué mejora y cómo se mide?
- Funcional, no maqueta. La persona decide, reasigna, cambia una regla y ve el efecto.
- Lógica visible. Cada decisión dice qué regla la produjo.
- Datos creíbles. Nombres, montos y lugares realistas. Un dato absurdo distrae toda la sesión.
- Desechable. Se conserva el motor de reglas y lo aprendido. La interfaz se reescribe sin culpa si hace falta.
El patrón técnico de las pruebas (ruta, página, aplicación y motor) está en Implementación.
Repetir casos reales
La prueba más fuerte para un motor de reglas, y la más barata. Se toma una muestra de casos reales del descubrimiento y se corre por las reglas:
- Se juntan casos del último periodo, incluidos los raros y los que salieron mal.
- Para cada caso se anota qué pasó en la realidad: quién aprobó, en qué orden, qué se rechazó.
- Se corre cada caso por el motor y se compara la decisión.
- Cada diferencia es una de tres cosas: falta una regla, la realidad hizo una excepción o la realidad se equivocó. Se decide con el dueño del proceso cuál es.
El resultado es la cobertura: qué parte de los casos reales resuelve el motor sin intervención. La meta de cobertura se acuerda en el diseño. Los casos que quedan fuera necesitan un camino manual explícito en el sistema.
Los casos usados se guardan como pruebas automáticas. Durante la construcción, cualquier cambio de reglas se vuelve a correr contra ellos.
Pruebas con usuarios
Cinco personas por grupo encuentran la mayoría de los problemas de uso. Conviene hacer varias rondas pequeñas, corrigiendo entre una y otra, en vez de una ronda grande.
- Un grupo por rol. Solicitantes y aprobadores usan el sistema distinto. Cinco de cada uno.
- Tareas reales, escritas como su trabajo: “Llegó una solicitud de $35,000 para tu área. Decide.” No “haz clic en Aprobar”.
- Pensar en voz alta, sin ayudar. Si alguien se atora, se anota dónde y por qué, y se pasa a la siguiente tarea.
- Registrar por tarea: la completó sola, con ayuda o no la completó, el tiempo y lo que dijo.
| Tarea | Sola | Con ayuda | No | Lo que se repitió |
|---|---|---|---|---|
| Aprobar una solicitud de su área | 5 | 0 | 0 | — |
| Pedir cambios con un comentario | 3 | 2 | 0 | Buscaban el comentario antes de la acción |
| Saber por qué pasó por Finanzas | 2 | 1 | 2 | No vieron la línea de reglas |
Ejemplo ilustrativo de registro de una ronda con cinco aprobadores.
Registro de objeciones
Toda objeción se anota con quién la dijo y qué se decidió. Nada se descarta en silencio, porque una objeción ignorada reaparece como resistencia en la adopción.
| Objeción | Quién | Decisión |
|---|---|---|
| “Cuando viajo no puedo aprobar y todo se detiene” | Jefa de Operaciones | Resolver: delegación en ausencia entra a la primera rebanada |
| “Quiero ver todas las compras del área, no solo las mías” | Director comercial | Anotar: tablero por área, segunda rebanada |
| “Prefiero seguir por WhatsApp” | Solicitante | Atender en la adopción: avisos donde ya están, con liga directa |
Salida
- Prueba funcional validada: las tareas principales se completan sin ayuda.
- Cobertura de reglas sobre casos reales, con camino manual para lo que queda fuera.
- Registro de objeciones con decisión en cada una.
- Mapa de historias y ficha de sistema actualizados con lo aprendido.
La compuerta pregunta: ¿quienes hacen el trabajo lo usarían mañana? Si la respuesta es no, se regresa a diseño con lo aprendido. Es más barato aquí que después.
Errores comunes
- Probar con los jefes en vez de con quienes usan el sistema todos los días.
- Explicar la pantalla antes de la prueba. Si hay que explicarla, la prueba ya dio su resultado.
- Pulir el prototipo antes de saber si la solución es la correcta.
- Confundir “les gustó” con “lo usarían”. La evidencia es completar tareas, no comentarios amables.
- Tratar el prototipo como el producto y construir encima sin revisar.