¿Por qué el MVP es la antítesis de una buena UX?

Nielsen Norman ha publicado un vídeo sobre el MVP (Mínimo Producto Viable en inglés) y la UX. 

Nielsen Norman nos dice que sus clientes expresan frustración con el Mínimo Producto Viable (o MVP), un concepto de Lean Startup que describe una versión de un nuevo 

producto que un equipo puede usar para aprender lo máximo con un esfuerzo mínimo. 

Para algunos equipos MVP significa mediocres diseños lanzados cada pocas semanas. Esto no era lo que pensaban los creadores de Lean Startup cuando definieron MVP. Y es ignorar lo que hemos aprendido de ingeniería del software. Pronto el entusiasmo de Lean Startup, Scrum y Agile enfocó las compañías hacia el MVP. 

Millones de startups ahí fuera necesitan guía, y para una startup el MVP tiene mucho sentido. Un pequeño equipo con poco dinero, sin clientes y inversores que escrutinan cada movimiento significando que cada movimiento necesita demostrar la viabilidad de la idea y la habilidad del equipo para ejecutarla. En otras palabras cada iteración tiene que hacer algo. 

Pero muchas organizaciones que usan el MVP no necesitan hacer esto y de hecho enfocarse en el MVP es contraproductivo. Su objetivo es tener un buen software al final, no probar algo en dos semanas. 

Además los más extremos partidarios de Lean consideran cualquier forma de prototipo es basura y prefieren ir directamente a código. 

A principios de los noventa en diseño de software un proceso común era este: los diseñadores escribían una larga especificación, los desarrolladores codificaban para cumplir la especificación, QA encontraba bugs en la construcción del producto, los desarrolladores corregían los errores y lanzábamos. Entonces aprendíamos de los problemas de los usuarios del feedback de los clientes y las ventas ganadas o perdidas. 

Pero después de repetir experiencias rehaciendo diseño y código, dar a los usuarios una mala primera impresión, invirtiendo mucho esfuerzo y convenciendo a la gente para cambiar software funcionando, perdiendo dinero y tiempo, aprendiendo sobre usabilidad demasiado tarde para hacer algo al respecto y golpear la moral de los empleados, aprendimos que podemos crear diferentes tipos de prototipos y usarlos para comunicar y debatir con los compañeros y también como el sujeto de los tests de usabilidad con posibles clientes. 

Aprendimos que podemos testear antes y que es más fácil y barato desechar un prototipo en papel que cientos de líneas de código. Aprendimos que tratar cada diseño como una hipótesis que podía incrementar la calidad de ese diseño y probar su proposición de valor. 

El verdadero diseño iterativo había nacido y pronto se hizo no solo en ricas y buenas compañías tecnologicas sino en entidades financieras y agencias del gobierno nombrando a la industria diseño iterativo. 

Hay muchos problemas con MVP y algunos de los problemas más comunes son éstos: no hay tests de usabilidad, o se hacen en el producto vivo. Esto significa que los cliente de pago están usando pobres diseños. 

El MVP no representa lo que el diseño planea ser. Obtener feedback de una tienda de campaña cuando el diseño final es una mansión normalmente no será muy útil. 

Cada MVP está altamente enfocado en un pequeño set de funcionalidades en lugar de un producto completo. Así que cuando las ponemos todas juntas, hay una gran variación y no hay cohesión en el diseño. 

Los equipos nunca cambian el MVP, aunque hayan graves problemas de los usuarios. Parece que hayamos caído atrás en el tiempo y hayamos olvidado lo aprendido sobre integrar UX en desarrollo de software. 

Hoy si trabajas en un mundo dirigido por los MVP que es improductivo para tu equipo, intenta redefinir lo que lo que mínimamente viable significa para ti. Considera sugerir que puede ser investigado y hecho para ser más realista, más útil, más usable antes de que vaya a producción y alcance un cliente de pago. 

Los diseñadores de UX y los product managers deben adaptar las técnicas y las metodologías a la empresa y al equipo de trabajo donde actúen. Algunas técnicas como MVP pueden no ser válidas fuera del entorno donde fueron creadas (las startups).

Vídeo