Fase 4: PROTOTIPADO

Construir la solución

EDITAR

«Construir prototipos» significa plasmar la Propuesta de Solución (PS) en algo concreto y visible, en algún dispositivo que se pueda mostrar a las personas usuarias y al resto de partes implicadas en el reto para que te den feedback y aprender de él.

«Prototipar nos permite convertir ideas abstractas en soluciones tangibles»

(Tim Brown)

Esos dispositivos en los que plasmas los prototipos pueden ser dibujos, maquetas, presentaciones de diapositivas, vídeos, bocetos de páginas web, storyboards o cualquier artefacto que visualice la solución que pretendes desarrollar y, sobre todo, que permita a otras personas interactuar con ella. La idea es que, a partir de ellos, consigas generar conversación y capturar más detalles sobre cuánto de cerca o de lejos está esa posible solución de lo que esperan las personas usuarias. 

Esa representación de la solución puede ser completa o parcial. También puede proyectar la solución en distintos grados de desarrollo: desde una propuesta muy verde, cercana a lo conceptual, que esté en una etapa temprana de diseño; hasta una madura, mucho más cercana a la solución definitiva, que se pueda validar como un prototipo funcional con todas sus prestaciones.

El proceso de prototipado es un viaje que va desde versiones de baja resolución, de tipo «conceptual», hasta los de alta resolución, de tipo «funcional». A medida que se avanza en las iteraciones, se va refinando, pasando de una representación borrosa en los detalles a una cada vez más nítida y cercana a la solución real.  

Por eso, lo más habitual es empezar con prototipos toscos y baratos. Son incompletos pero dan las pistas esenciales de lo que quieres probar. En los primeros pasos el equipo tiene que hacerse la siguiente pregunta: ¿Cuál es la forma más barata y ágil que tenemos de empezar a poner a prueba nuestra idea? No debes olvidar que al principio tus prototipos tienen un objetivo exploratorio, de naturaleza divergente, pero a medida que maduran, cambian a una función de refinamiento y validación, que es más convergente. 

Ejemplo del itinerario de prototipos

En el diseño de una app digital, quizás empezamos con uno muy conceptual, que consiste en dibujar un boceto, muy en bruto, sobre hojas de papel, reflejando las ideas más generales sobre objetivos, contenidos, etc. Después que se testea con potenciales usuarios, se crea el «esqueleto» o «wireframe», que una ilustración de las distintas pantallas de la aplicación, centrándose en lo que hace cada una. Se priorizan los contenidos y las conexiones entre las funcionalidades. Después, ya se va a una maqueta («Mockup»), que es una representación visual más avanzada, que incluye los detalles estéticos y de comunicación.

En esta etapa el equipo va a abordar dos tareas: 

  1. Decidir los prototipos a desarrollar 
  2. Crear los prototipos propiamente dichos

Conviene matizar que suele ser frecuente  que la primera tarea se realice junto a la segunda, que se entremezclen, al concebirse el prototipo mientras se construye. Esto es también perfectamente factible. De hecho, se dice que lo recomendable es «pensar con las manos», esto es, no deberías perder un tiempo excesivo en la planificación de lo que vas a construir, posponiendo demasiado tiempo la construcción misma. Al construir aparecen nuevas preguntas y nuevas decisiones que afectan el diseño del prototipo, así que es mejor empezar a hacerlo rápido. De todos modos, separamos las dos tareas con el fin de hacer hincapié en la importancia de reflexionar sobre qué queremos construir antes de ponernos a hacerlo. Ese análisis previo ayuda a enfocar bien. 

Decidir los prototipos que se van a desarrollar  

El equipo empieza esta tarea revisando, de nuevo, la ficha de Propuesta de Solución (PS),  para asegurarse de que todos los miembros entienden por igual el «encargo» que generó la Ideación. Esta primera puesta en común es importante, porque  aunque sea el mismo equipo el que haya trabajado la fase anterior, a veces falta una comprensión común del objetivo que se busca al prototipar. Hablar de esto, reflexionar otra vez sobre la PS y asegurarse de que se entiende bien, es una buena manera de empezar enfocados. 

Hay que organizarse bien para poder salir del modo conceptual (Ideación) y ponerse en modo de implementación (prototipado). Una primera decisión que hay que tomar es cuál va a ser el primer prototipo que construirá el equipo, esto es, ¿por dónde empezar?  

Hay muchas maneras de empezar . Una de ellas es diseñando un prototipo de baja resolución o fidelidad que sirva de representación visual de toda la solución. Otra, ser más concretos, y desarrollar un prototipo algo más avanzado para solo de una parte de ella. En el primer caso sacrificamos nitidez en favor de abarcar más, de aportar un modelo más sistémico. En el segundo, centramos el tiro en partes específicas de la solución buscando concretar más. Es bastante común que una PS conlleve varios prototipos, cada uno de ellos dedicado a un componente específico de esa solución.  

Lo más importante es fijarse  en los ATRIBUTOS o requisitos que se describieron en la ficha de la PS. Estos dan la clave para concebir el primer prototipo. Volviendo al ejemplo que se puso al final de fase de Ideación, sobre la PS de un «reto de rediseño de una convocatoria de ayudas». Uno de los atributos definía claramente los cuatro tipos de colectivos beneficiarios que debería tener, y, otro, que el tiempo máximo de resolución sería de dos meses. Pues bien, tomando esto como pistas, el equipo tendrá que decidir si prefiere desarrollar varios prototipos, por ejemplo, uno por colectivo beneficiario, o cómo puede crear un borrador del procedimiento que quepa en los dos meses establecidos como plazo límite. Además, qué «dispositivos» va a utilizar para plasmar el primer prototipo: ¿un boceto con el diagrama de flujo del procedimiento? ¿una presentación de diapositivas? ¿un vídeo que relate de una manera visual la nueva propuesta de diseño?    

Prototipa atributos concretos: no intentes probar todo a la vez

Uno de los errores más comunes que se cometen es, por las prisas, querer meter en el primer prototipo la PS completa, querer probar de golpe, en un solo test, todos los atributos. Si te empeñas en representarlos todos, puede ser que te retrases mucho, que peques de perfeccionista y, lo que es peor, al mezclarlo todo, no sepas aislar el efecto que tiene cada uno en la experiencia de la persona usuaria. Un testeo que pretenda conversar con los usuarios sobre todas las características de la solución a la vez puede conducir a resultados dispersos, en el que se pierdan detalles relevantes. 

En cada prototipo hay que integrar y probar solo lo necesario, atributos concretos, que generen una conversación con foco.  Y los primeros deberían centrarse solo en los rasgos esenciales que determinan la propuesta de valor de tu solución. El artefacto creado debe tener claro sobre qué pretende dialogar con las personas usuarias. Por eso es tan importante definir primero qué se quiere probar con cada prototipo. 

Se prototipa para aprender, y no para vender. No seas perfeccionista. 

Los atributos o requisitos definidos en la PS se convierten en «hipótesis » durante el proceso de diseño del prototipo. Entenderlo así ayuda mucho, porque entonces el prototipo se concibe como un dispositivo de prueba, esto es, algo que ayude a comprobar si esos atributos, como concepto, funcionan. Por ejemplo, si un atributo de la propuesta de solución es «suprimir el procedimiento secuencial y sustituirlo por reuniones en equipo, en las que se traten a la vez todos los elementos del expediente», entonces el prototipo debe diseñarse de una manera que permita testar, evaluar, si esa hipótesis es cierta, si el enfoque simultáneo es más eficaz que el secuencial.   

¿Prototipos alternativos?

Así es, suele ocurrir a menudo. Una revelación nos puede llevar a definir un atributo en la PS que tiene dos maneras distintas de solucionarse. Son dos caminos diferentes, pero no sabemos cuál es el mejor. El equipo debate sobre cuál es la opción ganadora, para elegirla, pero puede cometer el error de precipitar su elección cuando todavía le faltan datos y evidencias para tomar una decisión acertada. En estos casos, y para no perder el tiempo en un abordaje secuencial (primero probar una versión, después la otra, etc.), lo que hace es un «Test A/B », que es un término traído de la investigación científica y popularizado por el Marketing Digital. 

Las pruebas A/B consisten en la creación de dos versiones de una posible solución para ver cuál satisface más a las personas usuarias. Lógicamente, podría ser A/B/n, si hay n versiones que comparar, pero a menos sean, más fiable es la comparación. En estos tests la mitad de tu público objetivo prueba la versión A y la otra mitad la B, y entonces observas y analizas cuál resuelve mejor el reto planteado. Esto se puede hacer, por ejemplo, para comparar dos versiones de diseño de una página web o una app, y también, dos formularios para la prestación de un servicio o el diseño del espacio en una sala de espera de un hospital. En este último caso, habilitamos dos salas con una distribución diferente de los muebles y de los espacios, y observamos cuál diseño genera la mejor experiencia de usuario.    

Propuesta de Solución (PS) vs. «prototipos conceptuales»

Ambos se mueven a nivel estratégico, definiendo atributos clave. Definen el marco de la solución, pero tienen una diferencia significativa. La PS, que traíamos de la Ideación, es una declaración formal que describe la idea con la que esperamos resolver el reto. Es más «teórica» y abarca desde los objetivos hasta los requisitos necesarios para implementar la solución. Su objetivo principal es COMUNICAR la idea de la solución. Se centra en la explicación del problema y la manera en que la solución propuesta lo resolverá. Un «prototipo conceptual», en cambio, es una representación preliminar de la solución, en forma de maquetas, diagramas o modelos que visualizan la idea de manera tangible . 

El objetivo de la Propuesta de Solución es COMUNICAR cómo será esta para poder prototiparla. El de los prototipos conceptuales, es VISUALIZAR y crear las condiciones para PROBAR la solución, para evaluar y validar el concepto. 

Un prototipo conceptual prevé, por tanto, una primera representación física o digital, que puede variar desde bocetos hasta modelos 3D o dispositivos interactivos. 

El Producto Mínimo Viable (PMV)

En el recorrido que se hace por los distintas versiones de prototipos, desde los conceptuales a los funcionales, hay un tipo singular, que por su importancia vale la pena explicar aquí y que se conoce como «Producto Mínimo Viable» (PMV). 

Producto Mínimo Viable (PMV)

Una versión básica y funcional de una solución, que contiene únicamente las características esenciales de su propuesta de valor, y que está lista para ser usada y testada por los primeros usuarios reales. 

Las características que hacen singular a esta versión de los prototipos son estas:

  1. Incluye únicamente las funciones esenciales (aspectos críticos) de la solución para verificar que satisface la propuesta de valor prometida.  
  2. Es la primera versión que deja de ser «conceptual» para convertirse en «funcional», esto es, que permite a las personas usuarias realizar las tareas principales para las que fue diseñado y así probar de verdad sus funcionalidades.
  3. Se prueba con usuarios reales. 
  4. Cuida la eficiencia, así que se diseña de una manera que permita probarse rápidamente y con el menos esfuerzo posible  

Cabe indicar que cada organización puede tener criterios distintos para definir cuándo se ha alcanzado el PMV. Pero en general, se trata de una versión de la solución suficientemente robusta para permitir al equipo recabar la mayor cantidad de aprendizaje validado por los usuarios. Es más rudimentaria y bastante menos pulida que la solución final, y por tanto no incluye prestaciones más específicas. A partir del PMV, una vez que está validado, entonces el equipo irá añadiendo capas de funcionalidades, irá entrando en más detalles, hasta llegar a la SOLUCIÓN completa,  que es la que prueba un grupo mucho más amplio de usuarios, fuera de las condiciones controladas de «laboratorio». 

Del PMV a la solución final

Un ayuntamiento, que está desarrollando un nuevo «Sistema de Notificación de Riesgos de Movilidad» para la ciudad, que incluye la detección ciudadana de baches, señales de tráfico caídas, etc., pone a prueba un prototipo  básico de la solución, que solo incluye las funcionalidades críticas de la app, con un grupo limitado  de ciudadanos y empleados municipales para recibir retroalimentación. Después de revisar los resultados, y mejorar la versión mínima, fue añadiendo nuevas funcionalidades menos críticas hasta completar el producto y así dejarlo listo para que fuera testeado en un entorno real. Entonces, probó la solución completa en un «Piloto», durante tres meses, en un barrio de la ciudad. 

Ficha de diseño de prototipo

Convendría que cada prototipo que el equipo decida construir se plasme en una plantilla o ficha, en la que se describan los detalles. Para esta tarea, te proponemos usar la herramienta H15: FICHA DE DISEÑO DE PROTOTIPO. Puedes simplificar más o menos ese formulario, pero con su uso te aseguras de no olvidar nada importante, para que puedas tomar decisiones bien informadas. 

Construir los prototipos propiamente dichos

Es el momento de «pasar a la ejecución», creando los entregables  propiamente dichos. Dejamos de estar enredados/as en los bucles de reflexión. La planificación acabó, y ya deberíamos tener claro cuál es el primer prototipo a crear. Y si todavía dudamos, entonces empezamos a amasar la arcilla hasta dar con él.  

Cuando se habla de construir prototipos, ya hemos visto que se tiende a pensar en algo físico, hecho con cartones, papel, cinta adhesiva, cables, o, tal vez, bocetar apps o webs. Pero la cosa se complica si nos piden prototipar algo tan intangible como puede ser un servicio público. En este caso, nos cuesta más imaginar cómo hacerlo.

Por suerte, tenemos técnicas y recursos para prototipar intangibles. Desde dibujos hechos a mano, con historias o diagramas, hasta vídeos recogiendo relatos o maquetas que simulen (metafórica o realmente) la posible solución. Se puede pensar y explicar con la mano, con imágenes, con narrativas inspiradoras. 

La construcción de los prototipos habitualmente necesita recursos y apoyos. Hay que pedir ayuda para poder hacerlo. Y esto vale también para realizar las pruebas de validación. 

Una cosa es la técnica y otra cómo se plasma el resultado. Están los dos muy unidos, y a menudo es difícil separarlos, pero intentemos hacerlo con fines pedagógicos. Primero veamos cómo se crea un prototipo. Los distintas técnicas utilizadas para construir prototipos. Después, qué tipos específicos se pueden obtener al final de ese proceso, que llamaremos dispositivos.  

Ejemplo: Prototipando una APP

Se empieza con un prototipo de baja fidelidad, un boceto rápido hecho a mano en papel. Se dibuja las pantallas principales en una hoja de papel grande. Cada pantalla representa funciones distintas de la aplicación, con los elementos básicos. Se emplean para eso recursos simples como cuadros de texto para los campos de entrada, círculos para los botones o líneas para indicar la navegación entre las pantallas. Después, conectamos las pantallas con flechas para mostrar cómo se puede navegar entre ellas. En los dibujos se añaden anotaciones, se agregan notas que expliquen cómo deberían funcionar los elementos más importantes y el tipo de información que devuelve. Una vez terminado, lo prueba el equipo que diseña y se les pide a otras personas que simulen su funcionamiento. Mientras lo hacen, observamos con mucha atención y tomamos apuntes de situaciones de interés o recomendaciones de mejora.

TÉCNICAS para construir prototipos 

Las técnicas o métodos para crear prototipos se refieren a los enfoques y procedimientos utilizados para construirlos. Estas técnicas pueden variar según la etapa de desarrollo. Seleccionar una u otra dependerá del nivel de detalle que se busque, los recursos que se dispongan (incluida la prisa que tengamos), qué se quiere aprender en el proceso y las personas usuarias con las que se quiera validar el prototipo. 

Ir a las técnicas para construir la solución. 

Conviene matizar que hay algunas técnicas de las indicadas (p.ej. Mapas de la Experiencia de Usuario o Juego de Roles), que también pueden usarse en la fase-2 de Empatía, porque sirven para entender las necesidades de los usuarios, identificar problemas y obtener revelaciones. Se usan en esa fase para recopilar datos y empatizar con los usuarios. Pero, cuando las utilizamos como técnicas de prototipado, cambia el objetivo de empatizar a probar, a evaluar la aceptación de las versiones preliminares de soluciones.

Ejemplo: ¿Cómo McDonald prototipó un proceso de servicio de baja fidelidad?

En una escena de la película “El fundador”, los hermanos McDonald cuentan su proceso para diseñar la cocina más eficiente. Esta escena es un gran ejemplo de prototipado, pues logran probar y reconfigurar la cocina de una manera muy sencilla. En una cancha de tenis, dibujaron en el suelo unas líneas del mismo tamaño que la cocina y los componentes que la formaban: lavaplatos, freidora, empaquetado, batidoras, etc. Llevaron a todo el equipo del restaurante a la cancha de tenis y los hicieron trabajar en la superficie dibujada como si estuvieran preparando pedidos para clientes. Al visualizar cómo operaba el equipo, se dieron cuenta que la distribución de los sectores y espacios libres dentro de la cocina impactaban la fluidez de la operación.  Así que comenzaron a borrar las líneas en la cancha y dibujaron otras con nuevas ubicaciones para las distintas estaciones de preparación de los pedidos. Realizaron varias versiones de distribución de la cocina y, finalmente, luego de 6 horas de simulación, lograron alcanzar la “sinfonía de eficiencia”, donde todos los movimientos eran productivos. Sólo después de haber alcanzado ese resultado, llevaron los planos de esa cocina simulada a un constructor para que les adecuara la cocina del restaurante tal como ellos querían. Los hermanos McDonald seguían de cerca la simulación de la operación y le decían a cada uno del equipo dónde deberían pararse y por dónde moverse dentro de la cocina.

Ver vídeo de la escena: enlace

DISPOSITIVOS en los que se plasman los prototipos

Por decirlo de alguna manera, estos dispositivos son los «entregables» que salen al final de un ciclo cualquiera de iteración de prototipos, de aplicar las técnicas que describimos antes. Son artefactos que sirven para tangibilizar y transmitir la solución. Veamos varios de ellos en la siguiente tabla:

Ir a las técnicas para construir la solución. 

Ejemplo: Co-creación con maquetas

Un hospital desea rediseñar las habitaciones para ingresos, porque recibe muchas quejas de esto. Crea una maqueta (como las casas de muñecas) a escala reducida de una habitación con los distintos tipos de muebles en miniatura que se podrían usar. Entonces, le pide a pacientes y familiares que coloquen las piezas en esa maqueta de la manera que más le satisfaga. Lo mismo puede hacerse para co-crear un parque infantil de una comunidad de vecinos pidiéndoles que elijan los distintos elementos que les gustaría colocar en el futuro espacio de juegos. Tendrían columpios, toboganes, balancines, camas elásticas, etc., todos en miniatura, que colocarían en una maqueta según el diseño que más les guste.