Una presentación organizada en problema, solución y pruebas conecta una dificultad concreta con una respuesta propuesta y las pruebas que la respaldan. La secuencia sirve para formular una propuesta o explicar una idea, pero puede resultar engañosa cuando la supuesta «prueba» es solo una afirmación rotunda de que la solución funcionará.
Empieza con un esquema que separe los hechos observados, el cambio propuesto y lo que las pruebas permiten concluir. Cuando esas diferencias estén claras, puedes convertir el esquema en un borrador de diapositivas editable con Presenti. Una narración generada no debe inventar resultados de clientes ni convertir una prueba prevista en una ya realizada.

Define un problema que el público pueda reconocer
Indica quién encuentra la dificultad, cuándo ocurre y qué consecuencia importa. «Nuestro proceso es ineficiente» es demasiado amplio para orientar una decisión. «Una solicitud sin identificador de cuenta obliga a pedir más información antes de que el equipo de soporte pueda investigar» identifica un problema concreto.
Distingue un síntoma visible de una posible causa. La ausencia de identificadores puede explicar algunas consultas posteriores, pero no demuestra que el formulario cause todos los retrasos. Si has medido el patrón, indica la muestra, el periodo y la fuente. Si solo tienes un ejemplo, preséntalo como tal.
No amplíes el problema hasta hacer que tu solución preferida parezca la única razonable. El público debe poder entender la dificultad antes de escuchar la propuesta.
Muestra cómo responde el cambio propuesto al problema
Sigamos con el mismo ejemplo ficticio de solicitudes de soporte. La propuesta consiste en exigir un identificador de cuenta para los tipos de solicitud que lo necesiten y explicar dónde encontrarlo. El mecanismo es directo: quien investiga recibe un dato necesario en el momento del envío.
Eso no significa que todos los campos deban ser obligatorios. Algunas personas quizá no tengan una cuenta, y un formulario inflexible podría impedir una solicitud legítima. Muestra la excepción pertinente o la vía alternativa. Una diapositiva de solución debe explicar la contrapartida, no limitarse a sustituir un diagrama rojo por otro verde.
Considera al menos la alternativa práctica que probablemente planteará el público. En este caso, unas instrucciones más claras sin un campo obligatorio pueden resultar menos restrictivas, pero seguir permitiendo omisiones. Explica por qué recomiendas probar una opción, en lugar de afirmar que no existe otra.
Ajusta las pruebas a la afirmación
Cada tipo de prueba permite sostener conclusiones diferentes:
- Un ejemplo desarrollado puede mostrar cómo el formulario propuesto gestiona una solicitud. No demuestra con qué frecuencia ocurre el problema.
- Una demostración funcional puede mostrar que un campo o un proceso se comporta como se describe en ese entorno. No demuestra su adopción ni su impacto en el negocio.
- Una observación de una prueba piloto permite describir lo que ocurrió para las personas y durante el periodo observados. Hace falta contexto antes de generalizar.
- Una comparación con una referencia inicial fiable ayuda a valorar el cambio, pero las diferencias en usuarios, carga de trabajo o medición aún pueden afectar al resultado.
En esta propuesta ficticia todavía no hay resultados de una prueba piloto. Por tanto, la diapositiva de pruebas debe mostrar el ejemplo de solicitud y un plan para evaluar el cambio, no un gráfico ascendente titulado «Resolución más rápida». La decisión es si se pone en marcha la prueba, no si ya se ha demostrado un resultado que nadie ha evaluado.
Si más adelante hay resultados reales, presenta la definición y el denominador utilizados: qué se considera una solicitud que necesita una consulta posterior, qué tipos de solicitud se incluyeron y durante qué periodo. Mantén visible también la dificultad de completar el formulario; reducir las consultas posteriores sería menos convincente si muchos usuarios ya no pudieran enviar una solicitud.

Convierte el argumento en una secuencia breve de diapositivas
Tres etiquetas no obligan a usar exactamente tres diapositivas. Para proponer una prueba piloto, una secuencia de cinco da al público espacio para examinar el razonamiento:
- La petición: aprobar una prueba limitada, no un despliegue completo.
- El problema: explicar una solicitud incompleta y por qué requiere una consulta posterior.
- El cambio propuesto: mostrar el campo de identificador, el texto de ayuda y la vía para las excepciones.
- Pruebas e incógnitas: separar lo que demuestra el ejemplo de lo que debe medir la prueba piloto.
- La decisión: indicar el responsable, el alcance, el momento de revisión y las condiciones para continuar o modificar la prueba.
Conecta las diapositivas con frases que expliquen las relaciones. «Este dato que falta obliga a pedir más información» enlaza el problema con la solución. «El formulario puede recoger el dato; aún tenemos que saber si las personas consiguen completarlo» explica por qué una demostración funcional no cierra el argumento.
Para una presentación persuasiva más amplia, la guía sobre cómo utilizar pruebas en una narración con datos, en inglés ayuda a decidir qué comparaciones deben aparecer en las diapositivas principales y qué detalles conviene dejar como material de apoyo.
Conserva la precisión del argumento al redactar con IA
Proporciona a la herramienta la definición aprobada del problema, el mecanismo propuesto, las pruebas disponibles, las alternativas y las incógnitas. Pide títulos de diapositiva que mantengan esas diferencias. Una instrucción útil es: «Describe la prueba piloto como una propuesta. No inventes resultados, porcentajes, testimonios de clientes ni fuentes».
Lee los títulos en orden antes de perfeccionar el diseño. Si «podría reducir las consultas posteriores» se transforma en «elimina los retrasos», recupera la afirmación más acotada. Si una diapositiva contiene hechos que no aparecen en tus notas de origen, elimínalos o verifícalos. Esta estructura debe facilitar el examen del razonamiento, no hacer que una propuesta incierta parezca inevitable.