De la idea al prototipo: concepto, prueba de concepto y MVP explicados

Para pasar de la idea al prototipo, compruebe primero que el problema es real y después construya lo más barato que responda a su pregunta abierta más arriesgada. Un concepto responde a «¿qué construimos y para quién?», un prototipo navegable a «¿sabe la gente usarlo?», una prueba de concepto a «¿se puede construir?» y un MVP a «¿lo usará la gente y pagará por ello?». Con entrevistas a clientes en la primera semana, un prototipo navegable probado con cinco usuarios y, cuando haga falta, un spike técnico, una idea bien acotada puede probarse en dos a cuatro semanas, no en meses.

#Concepto, prototipo, prueba de concepto, MVP: qué responde cada uno

Estos términos se usan indistintamente en pitch decks y presupuestos, y así es como los fundadores acaban pagando por lo que no necesitan. Cada uno responde a una pregunta, para un público distinto y con una vida útil distinta.

Eric Ries definió el producto mínimo viable como la versión de un producto nuevo que permite a un equipo obtener el máximo aprendizaje validado sobre sus clientes con el mínimo esfuerzo. El prototipo y la prueba de concepto van antes y son aún más baratos. Para lo que viene después, nuestra guía sobre cómo construir un MVP que siga funcionando en el mes nueve explica los cimientos.

#Valide el problema antes de diseñar nada

El prototipo más caro es uno precioso para un problema que nadie sufre lo bastante como para cambiar lo que hace.

Entrevistas con clientes que no le engañen

The Mom Test, de Rob Fitzpatrick, es la guía de referencia, construida sobre una observación: la gente es educada con su idea. Sus tres reglas son hablar de la vida del otro en lugar de su idea, preguntar por situaciones concretas del pasado en lugar de generalidades u opiniones sobre el futuro, y hablar menos y escuchar más.

• «¿Cuándo le pasó esto por última vez? Cuénteme cómo fue.»
• «¿Qué hizo al respecto y cuánto le costó en tiempo o dinero?»
• «¿Qué ha probado ya y por qué lo dejó?»
• «¿Quién más interviene cuando esto sale mal?»

Evite «¿Usaría…?» y «¿Cuánto pagaría por…?». Las respuestas hipotéticas son opiniones sobre el futuro. La señal honesta está en lo que la gente ya hace: atajos, hojas de cálculo, dinero ya gastado, y si acepta un siguiente paso concreto, como una segunda reunión, una presentación a un compañero o un piloto.

Smoke tests: medir intención, no cumplidos

Un smoke test muestra la promesa antes de que exista el producto y mide lo que hace la gente. Las formas habituales son una landing page con una única llamada a la acción (lista de espera, reservar una demo, reservar el producto), un botón «fake door» en un producto existente y una prueba concierge, en la que usted entrega el resultado a mano a unos pocos clientes. Decida de antemano qué resultado cuenta como un sí, para no convencerse de uno después. Sea honesto con los visitantes sobre lo que ya existe y añada un aviso de privacidad si recoge direcciones de correo.

#Acote el prototipo en días, no en meses

Un prototipo se acota por su pregunta, no por una lista de funcionalidades. Tome la suposición abierta más arriesgada y construya solo lo que la pone a prueba. Todo lo demás es decoración.

1. Escriba la suposición más arriesgada como una frase que pueda resultar falsa, por ejemplo: «Las gerentes de clínica dejarán que los pacientes cambien sus citas sin llamar por teléfono».
2. Clasifíquela. El deseo y la usabilidad necesitan entrevistas y un prototipo navegable; la viabilidad técnica necesita un spike; la viabilidad económica necesita conversaciones sobre precio y, más adelante, un piloto.
3. Elija un usuario y un recorrido, del desencadenante al resultado. Un único recorrido de unas pocas pantallas suele bastar.
4. Fije un plazo y una fecha de prueba antes de empezar, y reserve ya a los participantes, para que la fecha no se mueva.
5. Acuerde qué decidirá después: seguir, cambiar de rumbo o parar.

El design sprint de GV muestra hasta dónde llega un plazo fijo: cinco días desde mapear el problema hasta ver cómo reaccionan los clientes ante un prototipo realista, con la idea de que una fachada realista basta para probar con clientes. No necesita un sprint formal, pero un día de prueba fijo mantiene el prototipo pequeño.

#UX y UI: del flujo de usuario al prototipo probado

Flujos de usuario

Empiece por el flujo, no por las pantallas: los pasos desde el desencadenante («se cancela la cita de un paciente») hasta el resultado («hay un nuevo hueco reservado»), con los puntos de decisión y lo que ocurre cuando algo falla. Un flujo en una página revela pasos que faltan y pasos que sobran antes de que nadie dibuje un píxel.

Wireframes

Los wireframes son pantallas de baja fidelidad: disposición, contenido y acciones en cajas grises. Se cambian rápido, incluso entre dos sesiones de prueba, y Nielsen Norman Group señala que los prototipos de baja fidelidad dejan claro que el diseño no está terminado, así que la gente se anima más a criticarlo.

Prototipos navegables en Figma

Para probar con usuarios y enseñar a inversores, enlace pantallas realistas en un prototipo navegable. En Figma se conectan los frames mediante interacciones en flujos, y después se puede compartir un enlace o presentar el prototipo en un dispositivo. Cada zona clicable del recorrido probado tiene que funcionar, o la sesión se viene abajo. Use contenido realista, con el vocabulario de sus clientes; el texto de relleno oculta justo las preguntas que importan.

Tests de usabilidad con cinco usuarios

Jakob Nielsen, de Nielsen Norman Group, sostiene que un test cualitativo con cinco usuarios encuentra alrededor del 85 % de los problemas de usabilidad y que es mejor repartir el presupuesto en tres rondas de cinco, corrigiendo entre ellas, que gastarlo en un único estudio grande. Dos matices: con grupos de usuarios claramente distintos, como el personal de la clínica y los pacientes, pruebe con tres o cuatro personas de cada grupo; y las métricas cuantitativas necesitan más de cinco.

Un test de usabilidad necesita un moderador, tareas realistas y participantes que se parezcan a su primer usuario y que piensen en voz alta mientras trabajan. Redacte las tareas como objetivos, no como instrucciones: «Tiene que pasar la cita del martes a la semana que viene», no «Haga clic en Reprogramar». NN/g advierte que las descripciones paso a paso contienen pistas ocultas sobre cómo usar la interfaz.

#Spikes técnicos y comprobaciones de viabilidad de IA

Una prueba de concepto responde a la pregunta de viabilidad, y su forma más rápida es un spike. Ward Cunningham recuerda que preguntaba a Kent Beck cuál era lo más sencillo que podían programar para convencerse de que iban por buen camino, y Beck llamó a la respuesta un spike: de punta a punta, pero muy fino. Un spike tiene un plazo fijo, es estrecho y normalmente se tira. El entregable es la conclusión, no el código.

• Integraciones con sistemas que usted no controla, como un ERP, un software de gestión de clínicas o una API bancaria: ¿puede autenticarse, leer y escribir lo que necesita, dentro de sus límites de uso y sus condiciones?
• Velocidad y carga: ¿la búsqueda, el emparejamiento o el cálculo responden en el tiempo que un usuario está dispuesto a esperar?
• Datos que da por hecho que existen: ¿están disponibles, son lo bastante limpios y es lícito usarlos para este fin?
• Funciones del dispositivo: sincronización sin conexión, Bluetooth o la cámara, en teléfonos reales.

Viabilidad de IA: pruebe el modelo con sus casos reales

En los productos de IA, la demo es la parte fácil: un prompt que funciona con tres ejemplos escogidos dice poco de los casos reales. Una comprobación útil:

1. Reúna entradas reales, también las desordenadas: formularios incompletos, el idioma equivocado, peticiones ambiguas.
2. Escriba cómo es una salida correcta y qué tasa de error es aceptable antes de ejecutar nada.
3. Evalúe automáticamente siempre que pueda. La guía de Anthropic sobre cómo construir evaluaciones recomienda reflejar la distribución real de tareas, casos límite incluidos, y prefiere muchos casos evaluados automáticamente a unos pocos evaluados a mano.
4. Mida el coste y el tiempo de respuesta por petición con el volumen que espera, no solo la precisión.
5. Compruebe adónde van los datos: qué proveedor, qué región, con qué contrato. Nuestra guía sobre IA conforme al RGPD repasa las opciones.

Antes de conectar ningún modelo, un prototipo «Mago de Oz», en el que una persona genera las respuestas detrás de la interfaz, prueba la experiencia en sí; Nielsen Norman Group lo propone para funciones de IA antes de construir la IA. Así separa dos preguntas: ¿quieren los usuarios esta respuesta, y puede un modelo darla de forma fiable?

#Qué enseñar a inversores y clientes piloto

Cada público hace una pregunta distinta, así que enseñe a cada uno pruebas distintas.

Deje claro qué es real. Un prototipo navegable presentado como software terminado es la forma más rápida de perder a un inversor con experiencia o al departamento de TI de un cliente piloto.

Ponga cada piloto por escrito en una página: objetivo, criterios de éxito, duración, quién hace qué y qué pasa si funciona. Un piloto sin criterios de éxito suele acabar en un educado «interesante» en lugar de en un contrato.

#¿Tirar el prototipo o hacerlo evolucionar?

Decídalo antes de construir, porque cambia cómo se construye el prototipo. La regla general: los prototipos de diseño y los spikes se tiran, y el MVP se conserva. El peligro está en medio, en un prototipo programado que se convierte en producto sin que nadie lo decida.

Martin Fowler llama arquitectura de sacrificio al código desechable a propósito y recuerda que eBay empezó en 1995 como un conjunto de scripts en Perl hechos en un fin de semana. Tirar código está bien cuando ese era el plan; el problema es el código que nunca se construyó para durar y que aun así se queda.

Si lo hace evolucionar, revise el código y arregle primero los cimientos caros: modelo de datos, cuentas y roles, pagos y región de alojamiento, como explica la guía del mes nueve.

#Un plan de dos a cuatro semanas, de la idea al prototipo probado

El plan supone una idea, un primer usuario y un equipo pequeño y experimentado. Para el deseo y la usabilidad suelen bastar dos semanas; prevea cuatro si además hay que demostrar una integración o un modelo de IA.

El resultado de este plan es una decisión respaldada por pruebas, no software. Si la respuesta es seguir, el siguiente paso es la primera versión, construida sobre cimientos que se conservan.

#Costes y los errores que los encarecen

Un prototipo cuesta sobre todo tiempo de personas, así que el coste sigue al alcance: número de grupos de usuarios y de flujos, wireframes o diseño visual a nivel de marca, y si hace falta una comprobación de viabilidad técnica o de IA. Para obtener una horquilla orientativa para su propia idea, use nuestra estimación gratuita; es una estimación, no un presupuesto.

• Prototipar antes de validar. Un prototipo pulido para un problema sin confirmar es una encuesta carísima.
• Recoger opiniones en lugar de observar comportamientos. «Lo usaría sin duda» no es una prueba; un piloto reservado sí lo es.
• Demasiada fidelidad demasiado pronto. Un diseño a nivel de marca antes de cerrar el flujo hace cada cambio más lento y cada crítica más educada.
• Una demo que esconde la parte difícil. Si la IA o la integración están simuladas, dígalo y pruébelas por separado.
• Un prototipo que se convierte en producto por accidente. Decida de antemano si se tirará o evolucionará.
• Activos a nombre de otros. Los archivos de diseño, las grabaciones de pruebas, los dominios y los repositorios deben pertenecer a su empresa desde el primer día.

#Cómo podemos ayudarle

Bespoke IT acompaña a los fundadores desde el concepto hasta la primera versión: trabajo de producto para encontrar y probar la suposición más arriesgada, diseño UX y UI desde los flujos de usuario hasta prototipos navegables probados con usuarios reales, arquitectura y spikes técnicos para la parte difícil, y el desarrollo de la versión que se conserva. Nuestro trabajo con startups empieza con un discovery sprint, y nuestra página de aplicaciones web y móviles muestra conceptos de nuestro equipo de diseño junto a productos que hemos lanzado.

A través de nuestro socio Salford Ventures GmbH, en Düsseldorf, los fundadores reciben además ayuda con la financiación: con la estrategia, con el plan financiero, con la preparación de los documentos que piden los inversores y con una lista de inversores a los que dirigirse. Vea cómo trabajamos con startups, obtenga una horquilla orientativa para su prototipo o contacte con nosotros para hablarlo.