Cómo probar un prototipo con clientes antes de desarrollar

Para probar un prototipo con clientes antes de desarrollar, elige una tarea relevante, observa cómo intentan resolverla y registra qué necesitan para terminarla. La prueba debe ayudarte a decidir qué construir, qué cambiar o qué investigar todavía. Una opinión favorable sobre las pantallas no basta para aprobar todo el producto.

Puedes empezar con un recorrido navegable que simule la experiencia. No necesitas conectar todos los sistemas para comprobar si alguien entiende una solicitud o encuentra la información necesaria. Sí necesitas dejar claro qué partes son simuladas y qué conclusiones permite sacar la prueba.

TL;DR — Preparar una prueba útil

• Define la decisión pendiente. Escribe qué tendría que ocurrir para desarrollar, cambiar o descartar ese recorrido.
• Elige participantes con el problema. Comprueba qué tarea realizan hoy y con qué frecuencia necesitan resolverla.
• Prepara solo lo necesario. El prototipo debe permitir probar la incertidumbre que condiciona la inversión.
• Plantea objetivos sin dar instrucciones de navegación. Observa cómo llega la persona al resultado.
• Registra la ayuda que das. Terminar después de una explicación no equivale a hacerlo sin asistencia.
• Separa uso y compra. Entender una pantalla no demuestra que alguien vaya a pagar o volver a utilizarla.
• Cierra con una decisión concreta. Relaciona cada cambio propuesto con una observación y una comprobación pendiente.

Qué necesitas comprobar antes de desarrollar

Empieza por la incertidumbre que podría cambiar el alcance del proyecto. En una herramienta de compras, podría ser si el empleado sabe qué información necesita para solicitar material. En otro producto, quizá lo decisivo sea si una persona externa acepta participar o si existe acceso a los datos necesarios.

GOV.UK recomienda utilizar los prototipos para explorar las hipótesis más arriesgadas y construir únicamente lo suficiente para probarlas. También distingue ese trabajo de un servicio con calidad de producción. GOV.UK: cómo funciona la fase alpha. Es una referencia de método; sus plazos administrativos no son una estimación para tu producto.

Escribe una pregunta concreta: «¿Puede quien solicita material identificar qué falta y dejar una petición lista para revisar?». Evita «¿Funciona la plataforma?», porque mezcla comprensión, necesidad, integración y operación. Si todavía estás delimitando la inversión, consulta qué diferencia hay entre presupuestar un prototipo y un MVP.

A quién invitar y qué prototipo preparar

Busca personas que realicen la tarea prevista y prepara el recorrido que necesitarían en esa situación. Antes de invitarlas, pregunta por la última vez que resolvieron algo parecido. Ese contexto permite distinguir una experiencia relevante de una opinión general sobre aplicaciones.

En B2B, quien usa la herramienta puede no ser quien autoriza la compra. Puedes necesitar conversaciones con ambos perfiles, pero registra sus respuestas por separado. La facilidad de uso para un empleado y los requisitos de compra de su responsable son evidencias diferentes.

Para el ejemplo de compras, prepara una solicitud ficticia con un dato pendiente, una forma de corregirla y un estado final comprensible. Si la notificación al responsable no está conectada, indícalo: la sesión puede mostrar qué espera el participante que ocurra, pero no confirmar que la notificación llegue.

Usa contenido plausible, sin introducir información confidencial innecesaria. Comprueba antes que el enlace abre en el dispositivo del participante y que puede recorrer los pasos previstos. Si elegir móvil u ordenador forma parte del problema, utiliza la ficha para decidir entre aplicación web y app móvil.

Guion copiable para una sesión de 35 minutos

Una sesión debe dejar espacio para observar y preguntar sin convertirse en una presentación comercial. Este reparto de 35 minutos es una propuesta de Apogeo para una tarea acotada, no una duración obligatoria ni un estándar de investigación. Ajusta el tiempo a la complejidad y a las necesidades del participante.

Puedes abrir con esta explicación: «Estamos probando una propuesta de herramienta. Algunas partes están simuladas. Nos interesa ver qué te resulta claro y qué necesitas para completar la tarea. Puedes parar cuando quieras». Si vas a grabar, explica su uso y confirma que la persona está de acuerdo antes de empezar. Digital.gov incluye esa confirmación, la preparación del guion y la separación de moderación y observación en su método de pruebas. Digital.gov: usability testing.

Para el contexto, pregunta: «Cuéntame la última vez que pediste material para tu equipo». Después: «¿Qué información tuviste que buscar?» y «¿Quién intervino antes de que quedara aprobado?». Estos ejemplos son un guion propuesto; adapta el vocabulario al trabajo real de la persona.

La tarea del prototipo podría ser: «Necesitas pedir material para el almacén. Hay una solicitud empezada con una fecha incorrecta. Déjala preparada para que la revise la persona responsable». No anticipes el nombre del botón ni indiques el orden de las pantallas. GOV.UK aconseja plantear tareas creíbles con un objetivo claro, sin revelar cómo completarlas. GOV.UK: pruebas de usabilidad moderadas.

Cuando la persona se detenga, puedes preguntar «¿Qué esperabas encontrar aquí?». Si necesita ayuda para continuar, dásela y anótala. Distingue un problema del recorrido de un enlace roto o una función deliberadamente ausente en el prototipo. Ambos limitan la sesión, pero requieren acciones diferentes.

Ficha para pasar de observaciones a decisiones

Registra hechos, interpretación y acción en campos separados. La ficha siguiente es un recurso de Apogeo para compartir con quien diseñe o desarrolle el producto. Permite revisar por qué propones un cambio sin convertir cada comentario en una funcionalidad nueva.

En este ejemplo no sabemos todavía si el problema está en el texto, en la ubicación o en la expectativa creada por el proceso actual. La observación justifica investigar la confusión; no demuestra por sí sola que haya que añadir una pantalla.

Al resumir una ronda, indica cuántas personas participaron y a qué perfiles pertenecen. Puedes registrar, por ejemplo, que dos de cuatro necesitaron ayuda, si eso ocurrió realmente. Esa fracción describe esa ronda; no permite afirmar que la mitad de todos tus futuros clientes tendrá el mismo problema. Conserva también las sesiones que no pudieron evaluarse y explica por qué.

Qué permite decidir la prueba y qué queda abierto

La prueba puede justificar cambios en el recorrido, pero la decisión de construir necesita considerar también necesidad, viabilidad y compra. Una persona puede entender una herramienta que no le resuelve una prioridad. Otra puede necesitarla y no tener autoridad para incorporarla a su empresa.

Strategyzer distingue entre declaraciones y comportamiento al valorar la fuerza de una evidencia. Strategyzer: cómo valorar la evidencia de una idea. Aplicado a este encargo, «me gusta» no equivale a que el cliente haya reservado tiempo para probarlo en su proceso ni a una compra confirmada.

Nuestra propuesta es cerrar la ronda con una de estas decisiones:

1. Revisar el recorrido: hay bloqueos observados que se pueden abordar con una modificación concreta y otra prueba.
2. Probar una dependencia: la decisión depende de datos, integración o participación de otra persona que el prototipo no comprueba.
3. Preparar una primera versión limitada: hay evidencia suficiente para el alcance elegido y queda definido qué uso operativo se va a observar después.
4. Replantear la solución: el problema aparece poco, se resuelve bien de otra forma o no justifica el esfuerzo de cambio para los participantes.

Antes de desarrollar algo propio, también puede convenir comparar un SaaS existente con software a medida. Una prueba útil puede terminar reduciendo el proyecto.

Preguntas frecuentes

Estas preguntas ayudan a delimitar qué encargar y qué resultado esperar de la investigación.

¿Puedo probar un prototipo aunque todavía no funcione el backend?

Sí, cuando la pregunta se puede resolver observando la interacción simulada. Debes identificar qué acciones funcionan y cuáles solo muestran un resultado preparado. No presentes un mensaje de éxito ficticio como prueba de que se guardan datos, se cobra o se avisa a alguien. Esas capacidades necesitan comprobaciones adicionales.

¿Cuántos clientes necesito para dar por validado el producto?

No hay una cantidad que convierta por sí sola el producto en validado. Define qué perfiles necesitas observar, qué decisiones dependen de la prueba y qué casos faltan. Una ronda pequeña puede descubrir obstáculos concretos. Para estimar porcentajes del mercado o comparar variantes estadísticamente hace falta otro diseño de investigación.

¿Sirve enseñarles el prototipo y preguntar si les gusta?

Sirve para recoger una opinión, pero aporta poca evidencia sobre cómo lo utilizarían. Si guías cada clic, no sabrás qué parte habrían resuelto solos. Separa la observación de la tarea de la conversación posterior y relaciona los comentarios con situaciones concretas. La preferencia visual tampoco demuestra necesidad ni intención de compra.

¿Puedo hacer la prueba con amigos o con mi equipo?

Pueden ayudarte a ensayar la sesión y detectar fallos del prototipo. Para aprender sobre clientes, necesitas además personas que encajen con el uso previsto y que no conozcan de antemano el recorrido. Si un amigo también es usuario potencial, registra ese encaje y la relación: la familiaridad puede influir en lo que expresa.

¿Qué debería entregarme una agencia después de estas pruebas?

Pide las preguntas investigadas, los perfiles participantes, la versión probada y los hallazgos vinculados a observaciones. La entrega debe diferenciar hechos, interpretaciones y propuestas, además de señalar lo que sigue sin comprobarse. Solicita una recomendación sobre el siguiente alcance y el motivo. No necesitas conservar grabaciones personales indiscriminadamente para tener una decisión documentada.

¿Cuándo paso del prototipo a un MVP?

Cuando la siguiente incertidumbre importante requiera observar un servicio operativo y puedas delimitar esa primera entrega. Documenta los problemas pendientes y las dependencias que condicionan el uso. Haber completado una tarea simulada puede respaldar una decisión de diseño, pero no garantiza repetición de uso, captación, ingresos ni viabilidad técnica.

Recomendación final

Antes de encargar el desarrollo, pide una ronda de prueba orientada a una decisión concreta y una devolución basada en observaciones. Reserva margen para corregir el recorrido. La entrega debería permitir explicar qué merece construirse ahora, qué se aplaza y qué evidencia falta para avanzar.

En resumen

• Elige una incertidumbre. La prueba debe influir en una decisión del proyecto.
• Comprueba el encaje del participante. Su trabajo actual aporta contexto a lo observado.
• Delimita la simulación. Un prototipo no acredita capacidades operativas que no ejecuta.
• Observa una tarea. Las instrucciones deben dejar que la persona encuentre el camino.
• Anota las ayudas. Diferencia terminar solo de terminar después de una explicación.
• Conserva los límites. Una ronda cualitativa no predice el comportamiento de todo el mercado.
• Decide el siguiente alcance. Cada cambio o inversión debe responder a una evidencia o incertidumbre identificada.

Fuentes y referencias

Las fuentes respaldan el método de prueba y sus límites; el guion, la ficha y el ejemplo son propuestas de Apogeo. Consultadas el 13 de noviembre de 2026.

• GOV.UK: How the alpha phase works.
• GOV.UK: Using moderated usability testing.
• Digital.gov: Usability testing.
• Strategyzer: How strong is your innovation evidence?.

El siguiente paso

Trae el proceso que quieres mejorar y la decisión que necesitas tomar antes de construir. En desarrollo de producto y MVPs podemos ayudarte a definir el recorrido, diseñar el prototipo y preparar su validación. Cuéntanos qué producto estás planteando.