Prototipo o MVP manual: qué prueba necesita tu idea

Completa esta frase: «Antes de invertir en construir, necesitamos saber si una persona que hace esta tarea puede…». Termínala con una acción observable, no con «estar interesada». Por ejemplo: encontrar el paso para corregir un encargo, utilizar una lista para preparar materiales o aceptar las condiciones concretas de una prueba. Cada final pide evidencia diferente.

Si todavía no sabes quién vive el problema ni qué hace para resolverlo, no elijas una pantalla por comodidad. Vuelve a una conversación sobre una situación reciente. Un prototipo no sustituye entender la tarea; una sesión acompañada tampoco demuestra que esa dificultad se repita en todo el mercado.

• Preparar una entrevista sobre el problema antes de enseñar una solución

Usa la tabla como mapa de decisión, no como una escalera obligatoria. No hay que pasar por todos los formatos ni empezar siempre por el más vistoso. Elige la fila que corresponde a la duda que frena vuestro siguiente paso y conserva su límite al interpretar lo ocurrido.

Si dos filas importan, ordénalas: ¿cuál haría innecesaria la otra si no se cumple? No mezcles clics en una maqueta con entregas terminadas para presentar una cifra de «validación». La tabla es una propuesta práctica de Brotaria; los resultados deberán proceder de vuestra prueba, no de estos ejemplos.

Un prototipo representa una experiencia sin tener que operar todo el servicio. Puede ser papel o una secuencia navegable. La guía de prototipado de GOV.UK recomienda elegir la forma adecuada a la necesidad y distingue ese código del de producción. Aquí tomamos ese criterio de diseño, no sus obligaciones de servicio público como normas para cualquier negocio.

Prepara solo el recorrido necesario para la pregunta: empezar una tarea, corregir un dato y reconocer cuándo termina, si esos son los pasos que necesitas observar. Da contexto y pide realizarla sin explicar dónde pulsar. Anota dónde se detiene la persona, qué espera y qué ayuda tuviste que darle. Si tú haces todos los pasos, habrás demostrado tu explicación, no su comprensión.

Presenta el material como prototipo y usa datos inventados. No pongas credenciales activas ni permitas confundirlo con una contratación real. Si lo compartes, controla quién puede acceder. Que el recorrido resulte comprensible no demuestra que alguien vaya a volver la semana siguiente. Tampoco convierte su código en seguro, mantenible o listo para atender usuarios reales.

• Fuente: elegir y compartir prototipos según GOV.UK

Una prueba manual no consiste en enseñar una función que todavía no existe, sino en realizar una parte del servicio. Acordad una tarea, una entrega y cuándo termina el acompañamiento. Explica qué haréis a mano y qué queda fuera. El apartado Manual del ensayo de Paul Graham describe trabajar manualmente antes de automatizar; no establece que hacerlo así garantice un negocio.

Registra tanto la conducta del participante como vuestro trabajo. ¿Utilizó el resultado para su tarea? ¿Tuvisteis que rehacerlo? ¿Qué información faltó? ¿Cuánto esfuerzo exigió prepararlo y resolver dudas? Un resultado apreciado que solo podéis entregar con atención excepcional deja abierta una pregunta sobre su operación, no una razón automática para programarlo.

Acordad el tratamiento de la información necesaria y evitad datos sensibles o documentos de terceros. No prometáis automatización, capacidad o plazos que no tenéis. Si la prueba fuera de pago, requeriría condiciones reales y las obligaciones correspondientes a vuestra actividad; no simules un cobro ni recojas datos bancarios para aparentar compromiso. Una prueba gratuita tampoco demuestra disposición a pagar.

Ejemplo hipotético: Eva y Leo exploran un servicio para coordinar materiales de talleres creativos. Ya han hablado con organizadores, pero no saben si lo difícil es preparar la lista, entender quién aporta cada cosa o conseguir que los materiales lleguen a tiempo. No son tres nombres para el mismo problema.

• Si la duda es entender responsabilidades, muestran una maqueta con un taller ficticio y piden identificar qué debe aportar cada participante. Observan confusiones sin dar pistas.
• Si la duda es la utilidad de coordinar, acuerdan con un organizador una lista real y una revisión manual de lo que falta. Limitan el alcance y registran uso, cambios y trabajo del equipo.
• Si la solución depende de consultar existencias de un proveedor, comprueban primero esa posibilidad en un entorno de ensayo autorizado. Una lista manual no demuestra que la integración funcione.

Estas son alternativas inventadas, no sesiones realizadas ni resultados de Brotaria. El equipo podría descubrir que la libreta actual basta o que quien realiza la tarea no decide una compra. Lo útil es poder nombrar esa diferencia antes de invertir, no acumular comentarios favorables sobre el diseño.

Antes de empezar, escribid hipótesis, prueba, medida y criterio de revisión: es la separación que propone la Test Card de Strategyzer. Un criterio propio puede ser completar una tarea definida sin determinada ayuda; su exigencia depende del contexto. No hay un porcentaje universal de respuestas favorables que certifique una idea. No cambiéis el criterio al ver el resultado para hacerlo encajar.

1. Nombra una sola duda y la tarea concreta de la persona que puede ayudar a comprobarla.
2. Elige una fila de la tabla y escribe también qué NO permitirá concluir esa prueba.
3. Acuerda alcance, responsable, límite de dedicación y condiciones de participación antes de pedir datos o trabajo.
4. Define qué observarás, cómo lo registrarás y cuándo revisaréis los hechos separados de vuestras interpretaciones.
5. Al cerrar, decide si repetir con un cambio, abordar otra duda o parar; conserva el motivo y lo pendiente.

Tu salida de hoy puede ser una frase: «Elegimos esta prueba porque necesitamos observar esta acción; dejaremos pendiente esta otra cuestión». Guárdala en vuestro documento de trabajo junto al límite y la revisión. La tabla se puede leer y seleccionar sin cuenta ni JavaScript; no introduce respuestas ni guarda datos del lector en Brotaria.

Si no apareció la señal esperada, revisa también si llegaste a las personas adecuadas y si el montaje permitía observarla. Un resultado inconcluso no es una aprobación ni un fracaso personal. Automatizar tendrá sentido cuando responda a una necesidad observada y a una operación que puedas sostener, no solo porque el prototipo haya quedado bonito.

• Encajar la prueba elegida en el calendario de validación de 30 días
• Acordar dedicación, responsabilidades y revisión con un posible socio