El prototipo que conversa: prueba con el usuario sintético antes del real, nunca en su lugar
Antes de agendar la prueba cara con gente real, simula un usuario sintético navegando el prototipo. Detecta el error grosero de flujo en minutos, pero carga el sesgo del modelo que lo simula: sirve para filtrar antes, nunca para sustituir al real.
Rediseñaste un flujo después de identificar el patrón que trababa a los usuarios, y ahora quieres probarlo antes de gastar el tiempo caro de agendar gente real. Simular un usuario sintético, una persona basada en lo que ya sabes de investigación real, corriendo el flujo por primera vez, detecta el error grosero en minutos: el botón ambiguo, el paso que nadie entiende a la primera. Solo que ese usuario sintético nunca va a reaccionar con la misma sorpresa o el mismo silencio incómodo de una persona real, porque carga los sesgos del modelo que lo simula. Sirve para filtrar antes, nunca para sustituir.
Antes de correr un nuevo proceso de aprobación de gasto con el equipo real, le pides a la IA que simule a un empleado típico intentando seguir el flujo nuevo, con el perfil real que ya mapeaste en entrevistas anteriores. Se traba exactamente en el campo de centro de costo, ambiguo desde hace meses. Ajustas antes de exponer el proceso a todo el equipo. Pero la decisión de liberar el proceso a producción nunca se apoya solo en esa simulación: un piloto con un departamento real sigue siendo la prueba que vale.
Antes de llevar una minuta de contrato nueva al cliente, le pides a la IA que simule la lectura de un cliente típico, sin formación jurídica, señalando dónde la cláusula queda confusa. Señala dos cláusulas ambiguas antes incluso de que agendes la reunión de revisión. Eso ahorra una ronda entera de idas y vueltas. Pero la aprobación final de la minuta nunca se apoya solo en la simulación: el cliente real, con su duda real, todavía revisa antes de firmar.
Antes de subir una campaña nueva, ya usas el cliente sintético para probar oferta y mensaje, tal como enseña la trilla de marketing. La misma lógica aplica aquí, con el mismo riesgo: el cliente sintético detecta error obvio de claridad rápido y barato, pero carga el sesgo del modelo que lo simula, y nunca sustituye la prueba con audiencia real antes de que el lanzamiento valga para siempre.
Antes de lanzar un nuevo proceso de onboarding de colaborador, le pides a la IA que simule a un nuevo contratado típico pasando por las primeras etapas, con el perfil que las entrevistas de salida ya mapearon. Se traba en el mismo punto que los relatos antiguos señalaban. Ajustas antes de que el primer contratado real pase por esto. Pero la validación del proceso nunca se apoya solo en la simulación: el primer grupo real de nuevos contratados sigue siendo la prueba que cuenta.
Antes de agendar la prueba de usabilidad con cliente real, le pides a la IA que simule la persona que el equipo ya validó en investigación, navegando el prototipo de la función nueva. Señala la misma fricción que treinta sesiones reales ya sugerían, en minutos. Eso confirma que vale la pena gastar el tiempo caro del usuario real probando ese flujo. Pero la decisión de lanzar la función nunca se apoya solo en la simulación: la prueba con gente real sigue siendo lo que decide.
Antes de llevar un discurso de venta nuevo al cliente, le pides a la IA que simule al comprador escéptico que generalmente traba la negociación, reaccionando al guion. Señala el punto exacto donde el discurso suena forzado. El vendedor ajusta antes de la llamada real. Pero el cierre nunca se apoya solo en la simulación: el cliente real, con su objeción real, todavía decide si compra.
Antes de correr un nuevo procedimiento con el equipo de operación, le pides a la IA que simule a un operador típico siguiendo el paso a paso escrito, señalando dónde la instrucción es ambigua. Se traba en el mismo paso que el incidente del mes pasado ya había revelado. Corriges el procedimiento antes de que el turno real lo siga. Pero la validación del procedimiento nunca se apoya solo en la simulación: el primer turno real que corre el procedimiento es quien confirma si funciona.
Antes de publicar una política nueva, le pides a la IA que simule a un colaborador típico leyendo el texto y señalando dónde quedaría en duda sobre qué está permitido. Señala una ambigüedad real en la sección de regalos. Corriges antes de que la política entre en vigor. Pero la aprobación final nunca se apoya solo en la simulación: la capacitación con colaboradores reales, y sus preguntas reales, sigue siendo la prueba que confirma si la política quedó clara.
Antes de exponer una API nueva a los equipos socios, le pides a la IA que simule a un desarrollador típico intentando integrarla, siguiendo solo la documentación. Se traba en el mismo endpoint que el equipo ya sospechaba mal descrito. Corriges la documentación antes de que el primer socio real intente integrarla. Pero la validación de la API nunca se apoya solo en la simulación: el primer socio real, con su entorno real, es quien confirma si la integración funciona.
Acabas de rediseñar el segundo paso del onboarding después de confirmar, con cita rastreable, que el problema era sobrecarga cognitiva en el formulario inicial. El prototipo está listo en Figma, la prueba con usuario real recién está agendada para la próxima semana porque la agenda de reclutamiento no avanza rápido. Antes de esperar, armas una persona sintética con base en el perfil real que apareció en las 84 entrevistas: alguien sin mucha familiaridad técnica, ansioso por terminar rápido, en el celular. Le pides a la IA que "sea" esa persona y navegue el prototipo paso a paso, narrando lo que siente en cada pantalla. En quince minutos se traba exactamente en el campo que sospechabas, y señala dos fricciones más que no habías visto. No cancelas la prueba real de la próxima semana: llegas a ella con tres hipótesis ya probadas, listas para confirmar o descartar con gente real.
Antes de presentar un nuevo modelo de decisión al directorio, le pides a la IA que simule a un consejero escéptico leyendo el razonamiento, señalando dónde el argumento es débil. Encuentra dos fallas en la lógica antes de la reunión real. Eso ahorra una ronda de retrabajo. Pero la aprobación de la estrategia nunca se apoya solo en esa simulación: el directorio de carne y hueso, con sus propias preguntas, todavía decide.
Oye, déjame contarte un giro bueno que todavía esconde una trampa adentro. El prototipo está listo, pero la prueba con usuario real recién ocurre la próxima semana, porque la agenda de reclutamiento no avanza rápido. Se puede esperar parado, o se puede correr el flujo ahora mismo con una persona simulada, basada en lo que ya sabes de verdad sobre quién usa tu producto. El problema es que esa persona simulada no es gente, y tratarla como si lo fuera es la forma más rápida de tomar una decisión equivocada con confianza de sobra.
La idea central de esta lección. Después de confirmar el tema con cita rastreable (lección anterior), construyes el prototipo y quieres probar el flujo. La IA hoy permite simular un usuario sintético: una persona basada en dato real de investigación, simulada por un modelo, navegando tu prototipo y narrando lo que siente. Es un filtro rápido y barato, que detecta error grosero de flujo en minutos, antes de gastar el tiempo caro de agendar gente real. No es sustituto: el usuario sintético carga los mismos sesgos del modelo que lo simula, y nunca reacciona con la sorpresa, la frustración o el silencio incómodo que un humano real revela. La regla de oro de esta lección es corta: sintético antes del real, nunca en lugar del real.
01Lo que el usuario sintético detecta bien, y detecta rápido
Empecemos por la ganancia, que es real. Armas una persona con base en el perfil que tu investigación ya validó, no un muñeco genérico, y le pides a la IA que navegue el prototipo como si fuera esa persona, narrando lo que entiende, lo que le extraña, dónde se traba. En quince minutos, sin agendar a nadie, sin esperar reclutamiento, ya detectaste el botón ambiguo, la etiqueta confusa, el paso que exige un conocimiento que la persona no tiene. Es exactamente el tipo de error grosero que saldría en una prueba real, solo que más temprano y más barato.
El valor aquí no es sustituir la investigación, es filtrar antes de ella. Piensa en el costo de agendar una prueba con cinco personas reales: reclutamiento, agenda, su tiempo, tu tiempo de moderar. Si el prototipo tiene un error obvio de flujo, no quieres descubrirlo en la sesión cara con gente real, quieres llegar a ella ya sin los tropiezos groseros, usando ese tiempo caro para detectar lo que solo un humano real revela.
02Por qué nunca es el real: el sesgo que carga
Aquí está el cuidado que separa a quien usa esto bien de quien se engaña. El usuario sintético no es una persona con opinión propia formada por toda una vida de experiencia: es un modelo de lenguaje representando lo que aprendió que una persona de ese perfil diría. Existe investigación que muestra que los modelos de lenguaje, cuando simulan la opinión de un grupo, tienden a jalar hacia lo más común y mejor representado en los datos de entrenamiento, y a aplanar la variación real que existe entre personas reales. Traducido a tu prototipo: el usuario sintético tiende a reaccionar de una forma más previsible, más "promedio", de lo que reaccionaría una persona real.
Y hay una brecha que ningún modelo simula bien: el silencio incómodo. En una sesión real, ves a la persona dudar, quedar insegura de si está haciendo algo tonto, o abandonar callada porque no quiere parecer tonta frente a ti. Es una señal de UX riquísima, y no existe en el usuario sintético, porque no siente vergüenza, no tiene miedo al juicio, no tiene el cuerpo que se traba. Te da una narración articulada de lo que "entiende" o le "extraña". No te da el momento en que una persona real simplemente deja de intentar.
03La regla de oro: antes del real, nunca en lugar del real
Junta las dos mitades y la regla queda corta de escribir y fácil de olvidar en la prisa: usa el usuario sintético antes de la prueba real, nunca en su lugar. No es una regla de pureza metodológica sin propósito práctico. Es protección contra un error específico y caro: lanzar un cambio de flujo a toda la producción basado solo en una simulación que pasó limpia, y descubrir después, con clientes reales, la fricción que solo un cuerpo real revela.
En la práctica, esto se convierte en una disciplina simple de seguir. Cada vez que el usuario sintético pase limpio por un flujo, pregunta: ¿esto quiere decir que el flujo está bien, o quiere decir que el modelo que simuló a esa persona no sabe reproducir la duda que una persona real tendría ahí? Si la respuesta te deja en duda, es señal de que la prueba real de la próxima semana sigue siendo lo que decide, no una formalidad que cumplir después de ya tener certeza.
Ahora construye
Toma el flujo que quieres probar en tu tarea real (o tu prototipo real) y arma una persona sintética con base en un perfil que tu investigación ya validó: nivel de familiaridad técnica, prisa, dispositivo, lo que sea relevante para tu caso.
Pídele a una IA que "sea" esa persona y navegue el flujo paso a paso, narrando lo que entiende, lo que le extraña, dónde duda, exactamente como si estuviera pensando en voz alta durante una prueba de usabilidad.
Al final, enumera los tres puntos de fricción que señaló, en el orden en que aparecieron. Para cada uno, marca: ¿es un error grosero de flujo (etiqueta, botón, paso confuso), que se puede corregir antes de la prueba real? ¿O es un punto donde sospechas que solo una persona de carne y hueso, con su frustración o su silencio, va a revelar el tamaño real del problema?
Corrige lo grosero antes de la prueba real de la próxima semana. Lleva el resto como hipótesis para confirmar con gente real. Nunca taches la prueba real de la agenda porque el sintético "pasó limpio".
Practica
1. ¿Cuál es el valor principal de probar un flujo primero con un usuario sintético?
2. ¿Por qué el usuario sintético nunca sustituye la prueba con persona real?
3. El usuario sintético pasó limpio por un nuevo flujo de checkout. Un colega sugiere cancelar la prueba real de la próxima semana para ahorrar tiempo. ¿Qué respondes?
4. ¿Qué tipo de señal de UX tiene más dificultad de reproducir de verdad el usuario sintético?
¿Listo? Cerremos juntos el mensaje de esta lección. El usuario sintético es un filtro real: detecta el error grosero de flujo en minutos, con el costo de una conversación, no de un reclutamiento entero. Pero está hecho del mismo material que el modelo que lo simula, con los mismos sesgos, y sin el cuerpo que duda, teme y a veces abandona en silencio. La regla de oro no cambia: sintético antes del real, nunca en lugar del real. Usa el filtro para llegar más limpio a la prueba que decide de verdad, y nunca dejes que el filtro decida por ti. Siguiente.
Para la pizarra
Sobre la gananciaes un filtro rápido que limpia lo obvio antes de la sesión cara con gente de verdad.
Sobre el límiteel modelo aplana la variación entre personas y no siente vergüenza, ni miedo al juicio, ni titubeo.
Sobre la regla de orosintético antes de lo real, nunca en su lugar. Pasar limpio el filtro no exime de la decisión de verdad.
Gracias por el feedback. Esto ayuda a afinar la próxima lección.