Diseñar un MVP: qué recortar y qué no
Diseñar un MVP es recortar hasta el núcleo que prueba tu supuesto más riesgoso, sin sacrificar la usabilidad. Aprende qué entra y qué se queda fuera.
¿Qué es un MVP?
El término lo acuñó Frank Robinson en 2001, y lo popularizaron Steve Blank y Eric Ries. La idea central es la del MVP como versión con las funciones justas para que early adopters la usen y den retroalimentación. Ries lo describe como la forma de reunir el máximo de aprendizaje validado con el mínimo esfuerzo.
Esa última frase es importante. Un MVP no es “una versión incompleta que sale rápido”. Es un experimento: una forma de comprobar una hipótesis antes de invertir en construir lo demás. Por eso su éxito se mide por lo que aprendes, no por cuántas funciones tiene.
¿Por qué le importa a un diseñador?
Porque en la mayoría de los equipos la lista de funciones crece más rápido que la capacidad de construirlas, y el diseñador es quien dibuja cada pantalla de esa lista. Saber qué no diseñar es tan útil como saber diseñar bien. Además, un MVP mal recortado genera una falsa conclusión: si la gente no lo usa, no sabrás si la idea era mala o si la interfaz estorbaba.
Un diseñador puede aportar un criterio concreto: qué flujo prueba la idea y cuál es el mínimo de interfaz que lo hace comprensible.
¿Cómo encontrar el supuesto más riesgoso?
Antes de tocar el alcance, escribe en una frase el supuesto más arriesgado de la idea. Full Scale propone precisamente eso: identificar “the single riskiest assumption” del negocio, y tratar como recortable todo lo que no lo pruebe. Ese supuesto puede ser técnico (¿se puede construir?), de demanda (¿alguien lo quiere?) o económico (¿alguien pagará?).
Por ejemplo, si tu idea es un servicio de reservas de clases de yoga, el supuesto riesgoso probablemente no sea la interfaz de reservas. Es si la gente llenará las clases. Eso decide qué pantallas hacen falta.
¿Qué recortar y qué conservar?
Mockplus propone tres preguntas para cada función:
- ¿Resuelve el problema principal?
- ¿El producto funciona sin ella?
- ¿Prueba el supuesto principal?
Si la respuesta es “no” a las tres, probablemente la función no pertenece al MVP. Full Scale añade una regla práctica: si recortar una función te da miedo, es probable que pertenezca a la versión 2.
Para priorizar, Mockplus menciona herramientas conocidas como MoSCoW, el modelo Kano o una matriz de impacto frente a esfuerzo. Puedes usar cualquiera, siempre que el resultado sea una lista corta.
| Conservar | Recortar |
|---|---|
| El flujo que demuestra el valor de la idea | Ajustes, personalización y preferencias avanzadas |
| Lo mínimo para completar esa tarea | Integraciones que no prueban el supuesto |
| Medición para saber si el flujo funciona | Pantallas de onboarding largas |
| Estados de error y de carga del flujo principal | Diseño visual pulido de pantallas secundarias |
¿Cómo se diseña el núcleo?
Diseña alrededor del flujo crítico, y hazlo con la misma calidad que tendría el producto completo. Mockplus recomienda, además, que el MVP tenga analítica desde el primer día, con embudos medibles y elementos que puedas probar con A/B. Sin eso, el MVP no te dice nada.
Recortar funciones no es recortar la usabilidad. Un flujo confuso en la parte central distorsiona la prueba: no sabrás si el usuario rechazó la idea o se perdió en la interfaz. Si el flujo central no se entiende, tu MVP no puede aprender nada.
¿Cuándo NO conviene un MVP?
Un MVP no sirve para todo. No conviene cuando:
- El riesgo principal es técnico y el experimento de demanda no cambiaría tus decisiones. Ahí hace falta una prueba de concepto.
- El producto tiene que cumplir un estándar de seguridad o regulación desde el primer día, por ejemplo en pagos o salud. Un recorte ahí puede ser peligroso.
- Ya tienes datos suficientes del mercado y lo que necesitas es escalar.
Full Scale distingue el prototipo, que prueba la idea con tu equipo; la prueba de concepto, que responde si algo se puede construir; y el MVP, que prueba la idea con el mercado. Saber cuál necesitas evita construir la pieza equivocada.
Ejemplo
Ejemplo ilustrativo: un equipo quiere lanzar una app para encontrar cuidadores de mascotas. La lista inicial tiene 40 funciones. Al aplicar las tres preguntas, el equipo deja solo cuatro: buscar cuidadores por zona, ver perfiles con reseñas, enviar una solicitud y confirmar el servicio por mensaje. Quitan el chat en tiempo real, los filtros avanzados, el pago dentro de la app y el panel de administración, que harán en una segunda fase. El supuesto que prueban es si los dueños contactarán a un cuidador desconocido. El flujo de solicitud se diseña con cuidado: estados de carga, errores de disponibilidad y una confirmación clara. A las seis semanas, saben si el supuesto se sostiene.
Errores comunes
- Confundir MVP con una versión sin diseño. Recortar funciones no autoriza a descuidar la experiencia del núcleo.
- Recortar sin una hipótesis escrita, de modo que nadie sabe qué debía probar el MVP.
- Incluir por miedo funciones que no prueban nada, porque “los competidores las tienen”.
- No medir nada, de modo que el resultado es una opinión y no un dato.
- Tratar el MVP como versión final y no como experimento que se puede descartar.
Para decidir el alcance, las preguntas ¿Cómo podríamos…? ayudan a enmarcar el problema antes de elegir funciones, y el modelo Kano ayuda a distinguir lo que el usuario espera de lo que lo deleita. Si el MVP es parte de un proceso más amplio, el proceso de diseño UX muestra dónde encaja. Y si decides probar el concepto antes de construir, el prototipado en papel es la forma más barata de empezar.