Un producto mínimo viable o MVP (de sus siglas en inglés Minimum Viable Product) es un test en sí. ¿Un test de qué? Del negocio, de una idea, de un concepto. Cuando nos proponemos construir un MVP partimos desde un cero muy incierto hacia una meta que no sabemos cuál es ni cómo alcanzarla. Debatiendo en Twitter con Verónica Traynor (@verotraynor) y José Allona (@joseallona) sobre el impacto que los tests de usabilidad pueden producir sobre un producto mínimo viable, me surgieron algunas dudas que intento despejar en este post.

Definamos los términos antes de empezar.

¿Qué es un producto mínimo viable?

“Un producto mínimo viable es una estrategia para probar un producto o funcionalidad rápidamente en el mercado. Un MVP es una prueba en sí. Es un producto que sólo tiene las funcionalidades básicas necesarias para probar una o varias hipótesis.”

Eric Ries, escritor de The Lean Startup, Startup Lessons Learned.

“Lean”, que en español significa “ajustada”, hace aquí referencia a la metodología de manufactura ajustada empleada por Toyota para construir autos y propuesta por el japonés Taiicho Onho, que apunta a reducir el inventario y el desperdicio.

¿Cuándo se debe construir un MVP?

Cuando se trate de un proyecto que traiga de la mano innovación disruptiva (en contraste con proyectos que sostienen la innovación), donde no se conozca a ciencia cierta que el objetivo que suponemos que un usuario debe alcanzar, tiene que, de hecho, ser alcanzado.

¿Qué es un test de usabilidad?

“Los tests de usabilidad son técnicas utilizadas en el diseño de interacción centrado en el usuario para evaluar un producto con usuarios reales. Esto puede verse como una práctica irreemplazable, ya que nos ofrece resultados directos de usuarios reales.”

Nielsen, J. (1994). Usability Engineering, Academic Press Inc, página 165

¿Cuándo se deben realizar tests de usabilidad?

Cuando las tareas que debe hacer determinado usuario para llegar a un determinado objetivo son conocidas por el negocio y lo que queremos mejorar es el camino que el usuario debe recorrer tarea por tarea para alcanzar ese objetivo y, por ejemplo, aumentar la taza de conversión.

Entonces: Un producto mínimo viable es una prueba para saber si un producto quiere ser usado o si hay mercado para él, mientras que un test de usabilidad es una prueba para saber si un producto es fácil de usar.

Actualización: Mientras escribía este post, José Allona me ha compartido un tweet con la url de un video de la charla Crushing the Boulder de Janice Fraser en Adaptive Path, sobre Experiencia de Usuario y The Lean Startup, lo que hace que tenga que definir otro término más: Experiencia de Usuario.

¿Qué es la experiencia de usuario?

La experiencia de usuario es cómo una persona se siente al interactuar con un sistema, e incluye conceptos tan variados como usabilidad, accesibilidad, utilidad, rendimiento, latencia, etc, como ilustra el siguiente gráfico.

Fuente: Smashing Magazine – http://uxdesign.smashingmagazine.com/2010/10/05/what-is-user-experience-design-overview-tools-and-resources/

En esta charla, Janice Fraser expone que finalmente, y luego de años de desentendimientos, existe una fuerte alineación entre la comunidad empresarial (Business community) y la comunidad de diseñadores UX (UX design community).

Janice Fraser:

“Finalmente existe una alineación muy fuerte entre la comunidad empresarial y la comunidad UX”

y también que lo que Lean Startup llama Producto Mínimo Viable, los diseñadores lo vienen llamando Prototipo desde hace años.

Janice Fraser:

“Nosotros los diseñadores lo llamamos prototipo. Lean Startup lo llama MVP (Minimun Viable Product)”

Y propone el siguiente gráfico para explicar el ciclo de iteración de desarrollo desde el punto de vista de un diseñador de experiencia de usuario:

para compararlo con el gráfico propuesto por Eric Ries en The Lean Startup:

Think -> Make -> Check = Build -> Measure -> Learn

El primer modelo expresa una preferencia por pensar, mientras que el segundo expresa una preferencia por construir, pero ambos modelos apuntan a lo mismo y el factor común que los une es la velocidad de los ciclos de iteración necesarios para mejorar el producto.

Explicando cada etapa:

Think – (Pensar): Apunta a construir modelos mentales, ideas, y a realizar investigaciones.
Make – (Hacer): Apunta a diseñar wireframes, mockups, prototipos, etc.
Check – (Corroborar): Tests de usabilidad, métricas, A/B Testing. Donde vemos que la usabilidad es sólo una parte de la tercera etapa de este modelo.

Build – (Construir): Apunta a construir un producto directamente desde una idea.
Measure – (Medir): Ver cómo responden los clientes/usuarios.
Learn – (Aprender): Perseverar en ese camino o cambiar el rumbo.

¿Pero y entonces? ¿En qué quedamos?

Mis conclusiones:

Los diseñadores de experiencias de usuario prefieren primero investigar, luego diseñar y finalmente chequear con tests de usabilidad y usuarios “reales”, mientras que los devotos al movimiento de Lean Startup prefieren hacer, medir y aprender. O sea, prefieren cometer errores y aprender de ellos directamente con el producto online y usuarios reales.

Ambos modelos apuntan a construir experiencias agradables y útiles, que agreguen valor a la vida del usuario.

Lo importante, entonces, no es determinar qué hacer primero, sino hacerlo en iteraciones rápidas y continuas que nos permitan minimizar el desperdicio y acelerar los ciclos de desarrollo del producto.

Desde mi punto de vista, entonces, la conveniencia o no de realizar un test de usabilidad sobre un prototipo o MVP, va a depender en gran medida del modelo que se use para diseñar ese producto. El test de usabilidad se encuentra explícitamente presente en la tercera etapa del modelo propuesto por Fraser, mientras que en el modelo propuesto por Eric Ries, la usabilidad no es una etapa definida en la iteración sino que actúa intrínsecamente en cada punto de ella, supeditándose y perteneciendo a un test mayor que es el MVP.

¿Dudas? ¿Preguntas? ¿Lo que acabo de escribir no tiene sentido? ¡Dejame tu comentario!

Este post fue publicado originalmente en el blog de diseño de Javier La Banca y puedes encontrarlo aquí: http://javierlabanca.com.ar/sobre-experiencia-de-usuario-usabilidad-y-los-productos-minimos-viables

A medida que trabajo con emprendedores, socios y clientes, veo que muchas personas usan las palabras wireframes, prototipos o mockups como si fueran sinónimos. No lo son. No sólo evidencian diferencias conceptuales, sino que también presupuestales, ya que construir uno o el otro influye en la billetera del cliente.

Entonces, ¿Cuál es la diferencia entre un wireframe, un prototipo y un mock-up?

• Wireframe: Representación estática en baja calidad de un diseño.

Es necesario delimitar las áreas donde vamos a mostrar la información y dejar claro cada tipo de componente que vamos a utilizar. El entregable es una imagen.

• Prototipo: Representación navegable del producto final. La calidad pueda variar entre media y alta.

Debe ser navegable y ofrecerle al usuario la posibilidad de recorrer las diferentes secciones. El entregable es un HTML o similar.

• Mock-up: Representación estática de un diseño en calidad media o alta.

Debe ser una representación estática de un diseño, en calidad media o alta. El entregable es una imagen.

¿Cuándo y por qué elegir unos u otros?

En el framework de desarrollo de productos que empleamos en itBAF, empresa que he co-fundado y en la que ocupo el puesto de CPO y diseñador interactivo, lo primero que hacemos es diseñar los wireframes junto al cliente para determinar el layout de la aplicación, los contenidos, las diferentes jerarquías, etc, y testear la navegación entre pantallas y la interacción del usuario con los diferentes componentes: menúes, carruseles, etc. Es durante esta etapa que los primeros tests de usabilidad pueden realizarse directamente sobre los wireframes y de una manera muy sencilla. No voy a ahondar en cuestiones de usabilidad pero les recomiendo el blog de usabilidad y accesibilidad de mi amiga Verónica Traynor, una especialista en el tema.

Seguido a los wireframes, vienen los mock-ups. Es decir, le agregamos detalle y diseño puramente gráfico a los wireframes, para comenzar con la búsqueda del look & feel de la aplicación. Es importante recordar que no debemos buscar el detalle absoluto en estos mock-ups ya que lo que estamos haciendo es diseñando experiencias de una manera ágil y entrar en detalle cuando todavía no se ha construido un prototipo sobre el cual no se han validado ningunas de las hipótesis del negocio, puede llegar a ser una gran pérdida de tiempo y dinero.

Es ahora momento de comenzar con el prototipado. En mi caso, realizo un prototipado rápido en HTML + CSS que servirá, entre otras cosas, para que el cliente realice las pruebas necesarias con sus clientes/partners. Es aquí donde se comienza a recibir la mayoría del feedback y es por eso que tenemos que ser flexibles y rápidos a la hora de realizar modificaciones en los prototipos, que se verán luego reflejadas en los wireframes y mock-ups. Es por esto que es una muy buena idea no construir demasiado detalle en los mock-ups hasta no haber hecho pruebas sobre los prototipos.

Con respecto al tipo de prototipo a construir, se pueden tener en cuenta dos opciones:

1. Protipo desechable.
2. Protipo utilizable para desarrollo.

Los prototipos desechables se realizan de una manera muy rápida y sin tener en cuenta las mejores prácticas de construcción de HTML y CSS. Su único objetivo es la de proveer interacción para que el usuario pueda testear las interacciones.

Los prototipos utilizables para desarrollo se construyen con el doble objetivo de testear las interacciones con el usuario y el de ser utilizados en el desarrollo final del producto. Es por esto que se deben tener en cuenta las mejores prácticas de construcción de HTML y CSS. Esto significa que el HTML desarrollado podrá luego ser tomado por los desarrolladores para incorporarlo al framework (de existir uno) e incluirle la programación necesaria.

Este post fue publicado originalmente en el blog de diseño de Javier La Banca y puedes encontrarlo aquí: http://javierlabanca.com.ar/wireframes-prototipos-mock-ups-cual-es-la-diferencia/

En itBAF, trabajo día a día con emprendedores que buscan generar un producto desde una idea innovadora que casi siempre les cuesta compartir por miedo a ser copiados. Muchas veces las ideas que escucho son innovadoras, otras no, pero en cualquier caso me gusta pensar que en estos momentos existen otros 99 equipos de emprendedores trabajando celosamente en la misma idea al mismo tiempo sin conocerse entre ellos y convencidos de tener un producto único.

Cada vez que empiezo a trabajar en las definiciones y el prototipado de un nuevo proyecto, tomo esta hipótesis como punto de partida, pensando en que existe una inteligencia colectiva que se nutre de los mismos contenidos provistos alrededor del mundo y se enfrenta diariamente a los mismos desafíos.

Esto me ayuda de dos formas:

1. Me obliga a poner todo mi empeño en intentar que mi producto sea el mejor y más innovador de esos 100
2. Hace menos fuerte el golpe cuando algún producto similar es lanzado primero y/o tiene éxito por sobre el mío.

De cualquier manera, me impulsa a trabajar con una premisa clara en la cabeza: esforzarme al máximo. Y esto es lo que en definitiva más importa: Dar lo mejor de uno mismo por un objetivo innovador que le agregue valor a la sociedad y que haga más agradable la vida del ser humano en el planeta. Porque siempre vamos a tener competencia y siempre vamos a fallar en la toma de algunas decisiones. El secreto está en reinventarse constantemente, en incorporar el cambio intrínsecamente al desarrollo de los productos y en ser sinceros con nosotros mismos de por qué hacemos lo que hacemos.

¿Y por qué hacemos lo que hacemos? ¿Por qué emprendemos?

Porque hay muchas cosas que pueden hacerse mejor. Porque tenemos un espíritu curioso que quiere superarse, que quiere descubrir, expandirse. CREAR.

Estamos en tiempos de iteraciones, de cambios de direcciones, de vértigo digital, de pruebas y errores, y con herramientas que nos permiten trabajar colaborativamente en un mundo totalmente conectado, con más de 2.200 millones de usuarios de Internet constantemente descubriendo, compartiendo, inspirando, creando, cometiendo errores y buscando aciertos. Pero en todos los casos, lo importante es creer en uno mismo y apoyarse en los demás, no guardar celosamente nuestras ideas sino que compartirlas, contarlas, probarlas y hacer sinergias con personas que posean nuestro mismo espíritu emprendedor.

Se están abriendo nuevos mercados, nuevas profesiones, nuevas disciplinas, con una velocidad y una aceleración nunca antes vistas. Necesitamos ideas, necesitamos emprendedores, necesitamos innovación y buenas intenciones. Necesitamos cambio y aceleración. Estamos muy cerca de dar un gran salto como sociedad y queremos estar ahí para ayudarte a tomar carrera.

Puedes inscribirte a Techangels 2013 aquí: http://www.itbaf.com/techangels.php

Javier Chavi La Banca es diseñador interactivo, co-fundador y CPO de itBAF. Ha trabajado en la definición de los productos de más de 10 startups.

En mi experiencia como CPO y diseñador interactivo de itBAF, compañía que he co-fundado y en la que diseño productos para startups como Fulbia, Driftee y Bananacash, para nombrar algunas, cada día pongo a prueba las metodologías que uso para diseñar y así aprendo iteración tras iteración. Luego de 5 años de diseñar en un ambiente de desarrollo ágil, donde lo importante es lanzar lo antes posible para validar y aprender, he desarrollado ciertas técnicas y adoptado un número de mejores prácticas que me permiten alinear la innovación del producto con el modelo de negocio sin comprometer la calidad de los productos desarrollados.

El objetivo primero de una startup, entonces, es el de desarrollar un producto, conseguir clientes, salir al mercado y aprender de la interacción con sus usuarios para validar o corregir las hipótesis de su negocio. Para esto, es necesario que el diseño vaya de la mano con las demás áreas de producción. No sólo es indispensable usar metodologías de desarrollo ágiles, sino también metodologías ágiles de diseño donde el detalle vaya emergiendo paulatinamente durante todo el proceso de construcción del producto. Esto significa que el modelo de cascada o waterfall, tan usado en el desarrollo de software en las últimas décadas, no es recomendable en una startup.

Para comenzar, como diseñadores, lo primero que debemos hacer es encontrar una visión de diseño cuyo objetivo sea guiar el emprendimiento durante toda su etapa de desarrollo. Una visión contiene sólo el detalle suficiente (generalmente en forma de wireframes) para que el equipo de desarrollo pueda comenzar a programar. Es decir, una guía de layouts e interacción rudimientaria para que los desarrolladores puedan comenzar con el diseño de la base de datos, la configuración del framework, etc.

Esto se debe a que como una startup está llena de incertidumbres, no podemos saber a ciencia cierta qué es lo que el mercado necesita hasta que no hayamos lanzado nuestra primera versión del producto o MVP (Minimum Viable Product o Producto Mínimo Viable propuesto por el emprendedor americano Eric Ries en su libro The Lean Startup) y hayamos comenzado a medir las interacciones con los usuarios.

Diseñar en una startup requiere que tanto los diseñadores como los desarrolladores, trabajen en un espacio compartido en el que puedan conversar sobre lo que están haciendo y despejar dudas mutuas. Esto significa que como diseñadores, debemos estar al tanto de las maneras en que nuestros diseños serán implementados para ser realistas a la hora de proponer soluciones. En el caso ideal, un diseñador en una startup debe poseer conocimientos de HTML, CSS y JavaScript, ya que hoy no es suficiente sólo ser un as de Photoshop, Illustrator y/o Fireworks.

Pero… ¿cómo influye el diseño de experiencia ágil en la calidad del producto final? La respuesta es que en el mundo de los emprendimientos en internet, NUNCA HAY un producto final, sino que el producto se va  construyendo día a día y en equipo. El diseñador que no piense de esta manera y que priorice su creatividad y sus tiempos por sobre el objetivo general de la startup, tiene los días contados. El detalle y la calidad del diseño van apareciendo y refinándose durante todo el proceso de desarrollo y no sólo en las primeras etapas, antes del comienzo de la programación, como era el caso en el modelo de waterfall o cascada, donde los procesos de desarrollo y diseño estaban bien separados en etapas.

En definitiva y para resumir:

1. Comenzar con una visión de diseño que guíe la etapa completa de desarrollo hasta el lanzamiento.
2. Trabajar en conjunto con el equipo de desarrollo.
3. Incrementar el detalle y la calidad del producto a medida que el proyecto avance.

Bibliografía consultada:

Agile Experience Design, de Lindsay Ratcliffe y Marc McNeill

The Lean Startup, de Eric Ries

Javier Chavi La Banca es diseñador interactivo, co-fundador y CPO de itBAF. Ha trabajado en la definición de los productos de más de 10 startups.

Con todos los concursos, aceleradoras, programas de apoyo a startups y demás, los emprendedores nos subimos a la cresta de la ola y la surfeamos como pop stars obsesionados por la imagen y las apariencias.

Ahora bien, debemos ser conscientes de que emprender va mucho más allá del elevator pitch, los eventos y las reuniones con inversores. Hay muchas tareas (podría decir el 85%) que están lejos de ser las tareas que nos apasionan. Lo que sí nos apasiona, y por ello seguimos a pesar de todo, es el objetivo final.

Un emprendedor es un empresario que se propone agregar valor y crecer. Ello implica asumir responsabilidades con nuestra familia, nuestros socios, nuestros empleados, nuestros clientes, nuestros proveedores y la sociedad en general. Sin dejar de lado el objetivo económico que un negocio conlleva, nuestra meta se basa en construir una solución para una determinada cantidad de personas. Y, para alcanzar dicha meta, vamos a interactuar con otros en un entorno específico. Todas las decisiones que tomemos marcarán una consecuencia.

El impacto de nuestro emprendimiento definitivamente va a sobrepasar nuestro círculo privado. Queda en nuestras manos definir las ambiciones del proyecto y lo que queremos lograr.

Cuando una startup comienza a tomar vuelo, y ya dispone de una cierta cantidad de dinero en la cuenta, se piensa en acciones que puedan  atraer clientes. Imaginamos que, por el sólo hecho de publicar nuestro logo en diversos eventos, o por invitar a personas a desayunar o a tomar una cerveza, vamos a recibir tantas solicitudes para contratar nuestro servicio que nos empezamos a asustar.

Todos los emprendedores debemos tener en claro (algunos lo aprendimos con el amargo sabor de la experiencia) que las acciones de marketing no son acciones de venta. Ambas son importantes, pero no son iguales. Las primeras, sirven para posicionar a la marca. Con el marketing, el mercado (clientes, competidores, etc.) nos conocerá, sabrá que existimos. Ahora bien, las acciones de marketing no nos traerán clientes por sí mismas.

Uno de los mayores desafíos con los que se encuentra un emprendedor (un desafío más), es direccionar la red de contactos que logra a través de las acciones al canal de ventas. Y, desde ya, cerrar las ventas.

Es por ello que resulta un buen ejercicio pensar las acciones subsiguientes al desayuno, evento, seminario o lo que fuere. Las acciones que nos permitirá sentarnos con potenciales clientes a hablar de nuestros productos o servicios, de sus beneficios y sus precios.

Hay acciones de marketing que predisponen mejor a las personas para luego escuchar del producto con cierto interés en adquirirlo. Trabajo del emprendedor es encontrar estas acciones.

1. Conseguir un socio que se complemente con mi personalidad.
2. Buscar un modelo que permita monetizar en el corto plazo para así subsidiar la visión a largo plazo.
3. Aprovechar lo que tengo para hacer lo que puedo y no desear lo que no tengo para hacer lo que deseo, sin perder de foco la visión a largo plazo.
4. Reconocer las cosas que no me gustan hacer y obligarme a hacerlas de forma sistemática.
5. Probar, cambiar y volver a probar permanentemente.
6. NO trabajar sólo en casa. Ir a bares, oficinas temporales, etc.
7. En algún momento, tener horarios de oficina.

¿Qué cosas les funcionaron a USTEDES en sus Startups?

Siempre, siempre, amparados en nuestra experiencia, vamos a recomendar disponer e alguna de estas dos opciones a la hora de desarrollar el producto: 1) tener en el equipo un socio tecnológico que pueda hacerse cargo del desarrollo; 2) encontrar una empresa que desarrolle el producto pero que también esté alineada a la visión de negocio del emprendimiento (alguna como, por ejemplo, www.itbaf.com).

Generalmente, cuando se inicia la etapa de desarrollo, los emprendedores se presentan ante proveedores especialistas en desarrollo de Aplicaciones de Internet y les describen todas las funcionalidades imaginadas tanto para la primera versión como para la segunda y la tercera. Los proveedores realizan una estimación de horas necesarias para cumplir con todas las especificaciones (a esa estimación le suman al menos un 30% para casos no previstos), acuerdan el pago con los emprendedores y comienzan a trabajar. A medida que los emprendedores van viendo volcados sus pensamientos en la pantalla de la computadora, nuevas ideas surgen y las prioridades cambian. En el transcurso de ese proceso de feedback, los emprendedores se transforman en expertos en diseño, programación y experiencia de usuario. Emprendedores y proveedores adaptan los proyectos para incorporar las nuevas funcionalidades y ajustes. Se extienden los plazos. El presupuesto va disminuyendo. Los emprendedores intentan renegociar las formas de pago pero los proveedores ya no están conformes con el proyecto. El costo de oportunidad cada vez es más alto y la tensión entre ambos también. Al final del día, el desarrollo queda en stand by hasta encontrar nuevos fondos que financien el cierre de la etapa.

Si el desarrollo del producto está a cargo de personas alineadas con el negocio (en definitiva, personas que saben que el producto se crea para vender y no para exponer en un museo), las prioridades siempre las va a definir el negocio.

El emprendedor debe formar parte del equipo de desarrollo. Debe estar al día de lo que se hace y de cómo se hace. Pero también debe confiar en el equipo y reconocer sus capacidades.

El equipo de desarrollo debe saber que el emprendedor es el dueño del proyecto y que es éste quien sabe mejor que nadie las funcionalidades que se deben contemplar par que el producto sea un éxito.

Recordemos que nuestra mayor fortaleza es saber desenvolvernos en el caos. Una startup debe poder definir su proyecto en no más de 2 meses y lanzar su producto en no más de 4. Y estos objetivos poco tienen que ver con la capacidad de recursos económicos. Está relacionado con la forma en que encaramos estas etapas y cuáles son los objetivos que buscamos en cada una de ellas.

Si un emprendedor vive las 24hs. pensando en su proyecto, no vemos por qué resultaría complejo definir aspectos del negocio, descubrir a su cliente, conocer a sus competidores, estipular el alcance de su propuesta y demás en sólo 2 meses. La dinámica y la facilidad de adaptación al cambio harán que la definición inicial sea sólo un recuerdo emotivo cuando la startup haya transitado los primeros tramos.

Nuestra metodología propone lanzar el Producto Mínimo Viable en 4 meses, más allá de las funcionalidades involucradas. La idea es que el emprendedor acuerde con el equipo de desarrollo cuáles son las funcionalidades mínimas necesarias que debe contemplar el producto para validar la hipótesis de negocio. Estas funcionalidades deben ser desarrolladas e implementadas en no más de 4 meses. El deadline estipulado fuerza la alineación del negocio con el desarrollo del producto y evita el despilfarro de los recursos. Lanzamos el producto para validar y ajustar a partir de allí.

Las startups valen por los clientes que tienen y por los que pueden llegar a tener. No por las funcionalidades de sus aplicaciones. Trabajar en la definición del producto es lo más motivante para todo el equipo. Desarrollar, desarrollar y desarrollar sin lanzar nos asegura una cosa: nunca nos vamos a enfrentar al fracaso de reconocer que nuestras presunciones estaban equivocadas y que los usuarios no quieren lo que nosotros pensábamos que querían. Esto, consciente o inconscientemente, nos juega en contra. Las aplicaciones se desarrollan para brindar soluciones y, en definitiva, captar la mayor cantidad de clientes posibles. Lancemos una primera versión y planteemos una metodología de trabajo que proponga iteraciones (mejoras, cambios y actualizaciones) de forma permanente.

Trabajemos en el cliente. Apliquemos ingeniería en el desarrollo del cliente. Preguntémonos ¿dónde está mi cliente? ¿Qué hace? ¿Qué no hace? ¿Qué quiere? ¿Qué compra? Parece ilógico, pero la definición de las aplicaciones se basa en presunciones de los emprendedores sin conocer al detalle las características del cliente potencial. Estas características, llamativamente, se presumen. No se validan. Nuestro producto debe transformarse en el medio que nos facilita la confirmación, o refutación, de las características que imaginamos en nuestros usuarios. Para cumplir esta función,  no es necesario caer en complejas funcionalidades. Unas pocas, sencillas, sirven de base para, a partir de allí, construir y destruir.