Respuesta breve
Antes de construir un producto completo, escriba las hipótesis de las que depende y elija la que más daño haría si fuera falsa y menos pruebas tiene a su favor. Conviértala en una afirmación que pueda fallar, elija el prototipo más pequeño capaz de refutarla, sea un boceto en papel, una maqueta navegable o un servicio prestado a mano, y fije los criterios de éxito y de fracaso antes de la prueba. Después actúe según el resultado: parar, volver a probar o construir.
Una plataforma es una pila de conjeturas con pantalla de acceso
El plan de una plataforma nueva se lee como una lista de hechos: los clientes lo necesitan, dejarán lo que usan ahora, los datos se pueden conseguir, el socio se integrará, el precio cubre el coste. Ninguno de ellos es todavía un hecho. Cada uno es una hipótesis, y el producto solo funciona si casi todas se cumplen.
Construir el producto completo es una forma de averiguarlo. También es la más lenta y la más cara, porque pone a prueba todas las hipótesis al mismo tiempo y entrega la respuesta cuando el presupuesto ya se ha gastado. Kara Pernice, de Nielsen Norman Group, hizo la comparación en 2016: tirar código sale caro; tirar un prototipo, sobre todo si es de papel, no.
Las herramientas más rápidas no cambian esto. En un artículo de marzo de 2026 para la misma firma, Sara Paul observa que las plataformas low-code y los asistentes de IA han acelerado la construcción, pero que lo que hace arriesgado un producto es lo que cuesta equivocarse, no lo que cuesta construirlo. Un producto equivocado hecho en una semana sigue siendo el producto equivocado.
Enumere lo que debe ser cierto y ordénelo por el daño
Empiece por escribir las hipótesis, una por línea. Un buen arranque es «para que esto funcione, tiene que ser cierto que…». Clasifíquelas a grandes rasgos en cuatro tipos: la gente lo quiere, la gente puede usarlo, podemos construirlo y mantenerlo, y se paga solo dentro de las reglas aplicables.
Después ponga dos notas a cada línea: lo grave que sería que la hipótesis fuera falsa y cuántas pruebas tiene ya. El GOV.UK Service Manual considera que identificar y comprobar las hipótesis más arriesgadas es una parte crucial de su fase alfa, y añade que cuáles son depende de cada servicio. Paul ofrece una regla práctica: el riesgo suele ser inversamente proporcional a las pruebas existentes.
El manual da dos ejemplos. Un equipo que quiere reducir la soledad con un servicio de información en línea debería averiguar primero cómo reciben hoy la información las personas a las que se dirige, porque si no usan internet es poco probable que usen el servicio. Y el equipo de Register to vote vio que todo dependía de una interfaz con los sistemas de registro de más de 400 administraciones locales, de modo que su fase alfa se concentró en eso.
Convierta la hipótesis peligrosa en una frase que pueda fallar
Una hipótesis se puede comprobar cuando dice quién, qué y cómo lo sabrá usted. Nielsen Norman Group propone una plantilla para la primera pregunta, la de si alguien valora la oferta: creemos que cierta propuesta es valiosa para cierto público, y sabremos que es verdad cuando observemos una conducta concreta durante la prueba.
Sirva un ejemplo con detalles inventados. Una cadena de panaderías estudia una plataforma de pedidos anticipados. La hipótesis peligrosa es que los clientes habituales encargarán la víspera en lugar de pasar por la tienda. Como frase comprobable: creemos que el pedido anticipado es valioso para los habituales de entre semana, y lo sabremos cuando al menos un tercio de los invitados haga un segundo pedido en dos semanas sin recordatorio. La proporción ilustra un criterio; no es una referencia.
Escriba, antes de cualquier prueba, qué aspecto tendrá cada resultado. El artículo de NN/g distingue tres: respaldada, parcialmente respaldada y no respaldada. Fijarlos de antemano importa más que las cifras exactas, porque después quien ya se ha enamorado de la idea puede presentar casi cualquier resultado como un éxito.
Elija la prueba más pequeña capaz de quitarle la razón
La forma del prototipo depende del tipo de duda. Si la pregunta es si la gente entiende y quiere la oferta, NN/g enumera tres formatos habituales: bocetos en papel, una maqueta navegable y el método del Mago de Oz, en el que el producto parece automático mientras una persona hace el trabajo entre bastidores. La panadería podría aceptar pedidos anticipados con un formulario sencillo y atenderlos a mano durante dos semanas.
Si la duda es técnica, la prueba más pequeña es una pieza acotada de ingeniería real: una conexión con el sistema externo del que depende todo, como en Register to vote, o un ensayo para saber si los datos son lo bastante buenos. Si la duda es legal o contractual, la prueba puede ser una conversación: el Service Manual sugiere dedicar parte de la fase alfa a ver hasta qué punto es viable resolver una limitación legislativa.
En todos los casos el consejo del manual es el mismo: no hace falta prototipar todo el recorrido; céntrese en las partes que prevé más difíciles y haga lo mínimo necesario para comprobar las hipótesis más arriesgadas. El marco de prototipado de Nesta lo explica con una silla: en la primera fase se prueban los materiales, la longitud de las patas y el ángulo del asiento, no la silla terminada.
Tosco a propósito: cuánto acabado necesita un prototipo
Un prototipo debe ser tan tosco como permita la pregunta. Pernice enumera lo que se gana con la baja fidelidad: menos tiempo de preparación y más para el diseño, cambios que pueden hacerse entre sesiones, participantes que se sienten más libres de criticar algo visiblemente inacabado, diseñadores menos apegados a su trabajo y responsables que ven que aquello no está listo para salir.
La tosquedad tiene, eso sí, un suelo. Si la gente no consigue averiguar cómo se usa, advierte Paul, la prueba se convierte en una prueba de la interfaz y no de la idea. La oferta debe ser lo bastante clara para que una negativa signifique «no lo quiero» y no «no lo he entendido». El contenido real, los precios reales y una redacción verosímil importan más que los colores.
Sea cual sea su forma, trate el prototipo como algo desechable. El Service Manual pide a los equipos que construyan cosas con la complejidad justa para probar ideas, no código con calidad de producción, y que cuenten con tirar el código, y muchas de las ideas, al final de la fase alfa. Cuesta tirar un prototipo pulido durante un mes, y esa es una razón más para mantenerlo tosco.
La evidencia es lo que la gente hace, no lo que dice que le gusta
Una prueba con prototipo produce tres tipos de señal, y no valen lo mismo. El elogio es la más débil: la gente es amable con quien le enseña una idea. Una intención declarada, «yo lo usaría», es algo mejor. La conducta es la más fuerte: la persona completa la tarea sin ayuda, vuelve una segunda vez, paga una señal o entrega los datos que el servicio necesita.
Esta jerarquía no es una excentricidad. La plantilla de NN/g pide una señal de conducta en su segunda mitad, y el marco de Nesta recomienda observar a las personas mientras usan los prototipos además de preguntarles, porque lo que dicen, piensan o harán suele ser distinto de cómo actúan en realidad. Organice la prueba de modo que haya algo que hacer y no solo algo que mirar.
Sea igual de estricto con quién participa. Los compañeros, los amigos y los seguidores que ya tiene no son el público nombrado en la hipótesis. Unas pocas sesiones con las personas adecuadas pueden mostrar si la idea se entiende y se desea; no le dirán el tamaño del mercado, y no deben presentarse como si lo hicieran.
Parar, repetir o construir: escriba la regla antes de que lleguen los resultados
El propósito del ejercicio es una decisión. Para el Service Manual, la fase alfa termina cuando el prototipo es lo bastante sólido para ayudarle a decidir si sigue adelante. Para continuar, el equipo debe estar seguro de que puede crear algo que responda a las necesidades de los usuarios y resulte eficiente en costes, y de que existen el presupuesto y las personas. Si no lo está, dice el manual, puede detenerse del todo o repetir una fase anterior.
Nesta describe la misma bifurcación con tres desenlaces: hay conocimiento suficiente para redactar el plan final; quedan lagunas que piden otra ronda con una especificación revisada; o hay tanto que replantear que el equipo vuelve a la prueba de concepto. Un resultado no respaldado no es automáticamente el final. NN/g aconseja preguntarse primero si ha fallado la oportunidad o solo esta manera de abordarla: el público equivocado, el canal equivocado, un diseño confuso.
Ponga un límite al tiempo además de a los criterios. Las fases alfa de la administración, según el manual, suelen durar entre seis y ocho semanas; una empresa pequeña que quiere validar una idea con un prototipo debería necesitar mucho menos, y el límite debe quedar por escrito antes de empezar. Un prototipo sin fecha se convierte en el producto sin que nadie haya tomado ninguna decisión.
Lo que una prueba superada todavía no demuestra
Un prototipo responde a la pregunta para la que se construyó y a ninguna otra. Puede mostrar que la gente entiende una oferta y la quiere. No puede mostrar que seguirá usándola, que el servicio aguanta la carga o que las cuentas salen a escala. Nesta es explícita: prototipar no es una alternativa a pilotar; va antes y produce una especificación mejor para el piloto.
El paso siguiente, en la secuencia de NN/g, es una versión real y pequeña, publicada para usuarios reales, que permite medir la participación, la retención y la conversión. El artículo enumera salvaguardas para esa etapa: limitar la exposición a un segmento o a usuarios invitados, mostrar a la gente lo que hará el producto antes de pedirle que actúe, etiquetarlo como beta o piloto y vigilarlo en tiempo real.
Caben aquí dos cautelas. Una prueba en la que una persona hace discretamente el trabajo de la máquina debe seguir siendo honesta sobre lo que ocurre con los datos y el dinero de la gente. Y un prototipo que ha superado la prueba debe reconstruirse, no ascenderse: los atajos que lo hicieron barato son el motivo por el que no es seguro montar un negocio sobre él.
Lista práctica
- Escriba cada hipótesis de la que depende el producto en una frase sencilla que empiece por «tiene que ser cierto que».
- Puntúe cada una por el daño si es falsa y por las pruebas que ya tiene, y elija la línea que salga peor en ambas.
- Reescríbala como una hipótesis que nombre el público, la conducta esperada y el resultado que contaría como fracaso.
- Construya el prototipo más tosco capaz de provocar esa conducta y pruébelo con personas del público previsto.
- Acuerde por escrito el límite de tiempo y la regla de parar, repetir o construir antes de la primera sesión.
Preguntas frecuentes
¿Qué es la hipótesis más arriesgada de una idea de producto?
Es la creencia de la que depende todo el plan, la que menos pruebas tiene a su favor y la que más daño causaría si resultara falsa. Puede referirse a la demanda, la facilidad de uso, la tecnología, el coste o la ley. El GOV.UK Service Manual señala que cambia de un servicio a otro, y por eso hay que identificarla deliberadamente en lugar de copiarla del proyecto de otro.
¿En qué se diferencia un prototipo de un producto mínimo viable?
El uso de los términos varía, así que conviene aclarar a qué se refiere. Nielsen Norman Group trata el MVP como un experimento que puede adoptar la forma de un prototipo, sea en papel, una maqueta navegable o un servicio operado a mano, o la de código real publicado para usuarios reales. Los prototipos sirven para la pregunta de si la gente valora la oferta. El código real sirve para la pregunta posterior de si una solución concreta atrae y retiene a sus usuarios.
¿Cuánto debe durar la comprobación de una hipótesis con un prototipo?
No hay una duración fija, pero sí debe haber un límite fijo. El Service Manual dice que las fases alfa de la administración suelen durar entre seis y ocho semanas, y Nesta describe el prototipado como un proceso de bajo coste y plazos cortos o medios en comparación con un piloto. Una empresa pequeña que comprueba una sola hipótesis normalmente puede fijar un periodo mucho más corto. Lo importante es acordar el límite antes de empezar.
¿Qué hacemos cuando la prueba del prototipo fracasa?
Primero averigüe qué ha fallado. NN/g desaconseja abandonar una idea por un solo resultado no respaldado y propone examinar el diseño, el enfoque técnico y factores externos como haber llegado al público equivocado. Si las personas adecuadas entendieron la oferta y aun así no la quisieron, parar es un desenlace legítimo y barato. El Service Manual incluye detenerse del todo entre las formas aceptables de terminar una fase alfa.
¿Se puede reutilizar el código del prototipo en el producto final?
Planifique que no. El Service Manual pide construir prototipos con la complejidad justa para probar ideas, no código con calidad de producción, y contar con tirar el código cuando acabe la fase alfa. Un prototipo omite a propósito la seguridad, la gestión de errores y el trabajo de rendimiento, y llevarlo a producción arrastra esas carencias. Conserve lo aprendido, el contenido y las decisiones de diseño, y vuelva a construir como es debido.