Fase 4: PROTOTIPADO

Construir la solución

La fase de IDEACIÓN finaliza con una propuesta de solución que describe lo mejor posible las características del producto que se desea construir y cómo se utilizará para resolver el problema. Por tanto, el equipo empieza revisando la propuesta de solución, para asegurarse de que todos los miembros entienden por igual lo que se pretende construir. Hablar de esto es una buena manera de empezar con un foco claro. 

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?  

No obstante, la descripción de la solución se hizo sin experimentar si funcionaba o no y, probablemente, como la propuesta aún no había sido aprobada, con menos recursos de los que puedes dedicarle ahora. Por tanto, su nivel de detalle es limitado y puede contener incongruencias, omisiones, errores y aspectos que no tienes claro aún cómo resolver.

«Prototipar nos permite convertir ideas abstractas en soluciones tangibles» (Tim Brown)

La buena noticia es que no es necesario resolver todas estas cuestiones antes de comenzar a construir. De hecho, no es conveniente, porque aún no has aprendido lo suficiente sobre qué funciona y qué no para resolver el problema.

La fase de PROTOTIPADO es especialmente iterativa: construimos un producto, lo probamos y volvemos a comenzar aplicando lo que hemos aprendido.

Aunque en la InnoGuía estamos presentando las fases secuencialmente para explicar los conceptos y técnicas ordenadamente, en la práctica existe mucho solapamiento.

En concreto, en la etapa de CONSTRUIR LA SOLUCIÓN es frecuente planificar a la vez que se construye.  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 que afectan el diseño de la solución, así que es mejor empezar a construir lo antes posible.

Planificar la iteración

Para iterar, lo primero que necesitas es definir el alcance de la próxima iteración. Lo ideal es que las iteraciones sean cortas (semanas o pocos meses). En algunas metodologías, las iteraciones tienen una duración fija, o se decide primero la duración y después el alcance.

En metodologías como SCRUM, se predefine la duración de las iteraciones, llamadas sprints, para forzar a los equipos a enfocarse en producir entregables lo antes posible y evitar que entren en un ciclo de perfeccionismo.

Producto o prototipo

En primer lugar, debes tener claro qué pretendes conseguir en esta iteración, porque eso determinará qué tipo de producto vas a construir: un prototipo o un PMV.

  • Si tu objetivo es averiguar algún aspecto relativo a cómo debería ser el producto para resolver el problema, construirás uno o varios prototipos que te permitan comenzar a probar lo antes posible y con el menor coste. En este caso, no pretendes que el resultado de la iteración pase a la fase de ESCALADO, sino que sabes que volverás a esta tarea a planificar una nueva iteración para incorporar los aprendizajes.
  • Si tu objetivo es tener lo antes posible algo que puedas utilizar en un entorno real para resolver el problema de las personas usuarias, intentarás construir un producto mínimo viable que, si supera las pruebas, pueda pasar a la fase de ESCALADO. No obstante, si las pruebas no son satisfactorias, también tendrás que volver a comenzar la fase de PROTOTIPADO.

El objetivo de la iteración puede ser probar un prototipo para aprender y volver, con mucha más información, al inicio de la fase de PROTOTIPADO o construir un producto mínimo viable que pueda implantarse en la fase de ESCALADO.

Qué parte construir

A continuación, debes decidir qué parte de la solución vas a construir. No es necesario acometer toda la solución a la vez ni resolver el problema completo de una sola tacada. 

Por tanto, necesitas dividir el trabajo en unidades de un tamaño manejable. En gestión de proyectos estas unidades se llaman paquetes de trabajo y describen tareas. En las metodologías ágiles, las CARACTERÍSTICAS de la solución propuesta, escritas en forma de historias de usuario, se usan directamente como unidades de trabajo, ya que al estar definidas desde el punto de vista de lo que obtiene la persona usuaria, facilitan que planifiquemos un producto resultante coherente y útil para resolver el problema.

Si lo que vas a construir es uno o varios prototipos, lo que necesitas es concretar qué quieres averiguar, es decir, identificar las preguntas de investigación o hipótesis, de forma parecida a como hiciste en la fase de EMPATÍA . Esto puede incluir la usabilidad, la funcionalidad, la aceptación por parte del usuario, etc. Esto te permitirá elegir el tipo de prototipo más fácil de construir, teniendo en cuenta que el prototipo sólo tiene que abarcar los ATRIBUTOS necesarios para responder a las PREGUNTAS.

No hay que construirlo 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.

EJEMPLO

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?    

Planificación

A veces, para decidir qué incluir en una iteración, es conveniente tener cierta visión sobre los pasos que seguiremos para llegar a la solución final. Para ello, se utiliza el concepto de hoja de ruta. Una hoja de ruta describe a alto nivel los principales objetivos o características de los hitos futuros. No merece la pena entrar en excesivo detalle, pues los planes pueden cambiar a medida que vamos aprendiendo sobre qué funciona y qué no.

La hoja de ruta puede ser interna del equipo, compartirse con el resto de la organización para alinear las iniciativas con las estrategias o incluso ser completamente pública. Lo ideal es que esté formulada en términos que las personas usuarias comprendan, ya que te ayudará a mantener el foco del proyecto en resolver el problema.

Para planificar la iteración, hay que dividir en partes manejables el trabajo necesario para construir la solución.

Los equipos innovadores suelen planificar la iteración colaborativamente. Si existe una persona responsable de asegurar que el proyecto responde a las necesidades de las personas usuarias (a veces se le llama responsable del producto o responsable funcional), su papel en la planificación es fundamental. Como las iteraciones son cortas, normalmente no hace falta definir una planificación de fechas precisa y detallada, sino que basta con tener una lista priorizada de las unidades de trabajo. 

En las metodologías ágiles, la lista de todo lo que se sabe que hay que construir (las unidades de trabajo) se llama backlog de producto, y la planificación de la iteración (sprint), llamada backlog de sprint, consiste en elegir del backlog  de producto qué se acometerá en la iteración.  La cantidad de unidades de trabajo que se incluyen se calcula a partir del ritmo en el que se iban construyendo en la iteración anterior (sprint velocity).

Puedes describir cada unidad de trabajo en el formato que quieras, pero es importante que todas las personas implicadas tengan una idea lo más parecida posible de lo que se desea construir, porque normalmente trabajarás en equipo. Incluso si lo hicieras tú todo, necesitarías organizarte para no perder el rumbo. En metodologías ágiles, se le llama tener una buena “definición de listo”, es decir, que haya las menos dudas posibles de si se ha completado lo que se desea construir.

Para ello, es posible que te interese describir con un poco más de detalle las CARACTERÍSTICAS que hayas elegido implementar. Las ventajas de describir las unidades de trabajo en términos de lo que se desea conseguir (los objetivos) en lugar de lo que se va a hacer (las tareas) es que se centra más la atención en el usuario, se colabora mejor, se fomenta que haya soluciones creativas y las personas trabajan con más autonomía y motivación.

Hay que planificar, pero sin dedicar un tiempo excesivo. A veces es recomendable «pensar con las manos». Al construir aparecen nuevas preguntas que afectan el diseño de la solución, así que es mejor empezar lo antes posible.

Aunque en la InnoGuía estamos presentando las fases secuencialmente para explicar los conceptos y técnicas ordenadamente, en la práctica existe mucho solapamiento. En concreto, en la etapa de CONSTRUIR LA SOLUCIÓN es frecuente planificar a la vez que se construye.  

Construir las características planificadas

Es el momento de «pasar a la ejecución», creando una versión del producto que deberá servir para resolver el problema. Dejamos de estar enredados/as en los bucles de reflexión. La planificación acabó, y ya deberíamos tener claro qué tenemos que construir. 

Decidir el tipo de prototipo

Como hemos visto anteriormente, en la fase de PROTOTIPADO, cuando necesitas tomar decisiones que dependen de cómo se van a comportar las personas usuarias, se utilizan los prototipos. Los prototipos permiten:

  • Comprobar si un diseño es adecuado. 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 comprobar si esa hipótesis es cierta, si el enfoque simultáneo es más eficaz que el secuencial.   
  • Elegir entre varias opciones. Por ejemplo, ¿con qué encabezamiento rellenan mejor un campo de un formulario “Motivación” o “Explica por qué solicitas este servicio”?
  • Aprender cómo se comportan las personas usuarias. Por ejemplo, ¿qué parte de la pantalla llama su atención en primer lugar?

A veces se construyen varios prototipos simultáneamente, por ejemplo para averiguar qué opción se adapta mejor a las necesidades de las personas usuarias.

Los prototipos son efímeros, sólo sirven para probar, así que nos interesa que sean baratos y rápidos de construir. No se van a utilizar en un entorno real, así que no es necesario que funcionen, basta que proporcionen la sensación de funcionamiento suficiente para que las personas interactúen con ellos. Por tanto, normalmente son soluciones simuladas.

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

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. 

Algunos ejemplos de prototipos para innovar en servicios públicos son:

  • Muebles de cartón y carteles de papel que simulan las pantallas de información para experimentar con la distribución de una oficina de atención al público.
  • Pantallas de aplicaciones impresas en papel, el usuario dice dónde pincharía y una persona le muestra la pantalla que aparecería.
  • Pantallas de aplicaciones que simulan el funcionamiento, pero presentan datos ficticios y no guardan en ningún sitio los datos que introduce el usuario.
  • Persona que interpreta un papel y simula una actuación administrativa cuando interactúa con las personas usuarias. Estos juegos de roles son útiles para entender las dinámicas en servicios complejos, como la atención médica o servicios sociales. Permite identificar problemas de comunicación y coordinación entre los diferentes actores, explorando cómo encajan sus necesidades e intereses específicos en el diseño de la solución. Es una manera rápida y tangible de construir un prototipo de la experiencia y poder probar una idea, ensayándola como si fuera real.

No confundas un prototipo con una propuesta de solución. El objetivo de la Propuesta de Solución es COMUNICAR cómo será esta para pedir opinión, obtener los recursos necesarios para implementarla y para que todo el equipo tenga una idea compartida sobre qué se va a construir. El de los prototipos es PROBAR para resolver incertidumbres, así que con los prototipos se puede INTERACTUAR. 

A veces usa el concepto de prototipo de baja resolución o prototipo conceptual, para referirse a un diagrama, el boceto de una pantalla de una aplicación, una maqueta, etc. Cualquiera de estos dispositivos se puede utilizar para probar cómo interactúa la persona usuaria. Por ejemplo, una maqueta de una playa en la que varias personas usuarias van, sucesivamente, pinchando una sombrilla de coctel permite estudiar cómo se comportan las personas a medida que queda cada vez menos sitio.

En la fase de IDEACIÓN también habrás realizado bocetos y diagramas. Sin embargo, no los habrás probado, como mucho los habrás usado para pedir opinión, que no es lo mismo (las personas muchas veces no somos capaces de expresar lo que realmente preferimos, así que las opiniones no sustituyen a los experimentos para resolver las incertidumbres). Por tanto, para evitar confusiones, te recomendamos que sólo utilices el término prototipo para estos dispositivos si se usan para probar:


Término Para qué se usa
Propuesta de solución Mostrarlo, para pedir opinión y alinear al equipo.
Prototipo Interactuar con él para aprender cómo se comportaría una solución de ese tipo.
Producto mínimo viable  Prestar servicio a personas usuarias.

Ejemplo: Prototipando una APP

Se empieza con un prototipo de baja resolución, 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.

Construir el prototipo o el producto mínimo viable

Las estrategias para construir cada característica o realizar cada unidad de trabajo son diversas.

Una opción es comenzar con una visión general del producto final y luego ir desarrollando los componentes necesarios para lograrla. Por ejemplo, para construir un cuadro de mandos, podríamos comenzar por un esbozo del cuadro resultante y después ir automatizando lo necesario para alimentar cada uno de los indicadores. Otro ejemplo es comenzar con un mapa de la experiencia de usuario o un mapa de servicios, que muestran de manera secuencial todos los pasos que recorre una persona en relación al problema que queremos resolver, o todos los pasos que realiza la Administración para prestar el servicio, y después solucionar cada uno de los pasos. 

Un caso extremo es la metodología Test-Driven Development (TDD) de desarrollo de software, en la que primero se diseñan y automatizan las pruebas a las que se someterá al producto y después se empieza a programar la aplicación capaz de superarlas.

Otra opción es comenzar por construir todas las piezas del producto (por ejemplo, analizando todos los datos que tenemos susceptibles de agregarse en indicadores) y después irlas uniendo por prueba y error, como si de un Lego se tratara.

Por ejemplo, para construir un prototipo, el equipo puede reunirse en torno a los materiales a utilizar e ir diseñando a medida que se construye.

Dependiendo del tipo de solución, puede que existan metodologías y técnicas específicas que te interese aprender y aplicar. Por ejemplo, si la solución es optimizar un procedimiento, puedes usar Lean o Six Sigma; Si es elaborar un manual, tal vez te interesen técnicas de comunicación, de lectura fácil, etc. que tienen sus propios procedimientos.

Coordinar el trabajo

Una vez que todo el equipo tiene claro el alcance de la iteración, hay que repartirse el trabajo y coordinarse para realizarlo. En metodologías ágiles, una práctica habitual para ello es que cada miembro del equipo vaya sacando unidades de trabajo de la lista a medida que va terminando los trabajos anteriores, sin que nadie le presione.

Un concepto clave para coordinar el trabajo es el Work In Progress (WIP), que se refiere a la cantidad de unidades de trabajo que se están realizando en un momento dado. Limitar el WIP es fundamental para evitar sobrecargar al equipo y garantizar que las tareas se completen antes de iniciar nuevas. Esto permite mantener un flujo de trabajo constante y enfocado, mejorando la productividad y reduciendo el tiempo de entrega.

Una herramienta eficaz para gestionar y visualizar el WIP es el Kanban, un tablero que muestra el estado de las tareas a medida que avanzan por diferentes etapas del proceso de desarrollo. En un tablero Kanban típico, las columnas representan diferentes fases del trabajo, como "Por hacer", "En progreso" y "Completado". Cada unidad de trabajo se representa como una tarjeta que se mueve de una columna a otra a medida que se avanza en su realización. Esta visualización clara del trabajo en curso permite al equipo identificar cuellos de botella y ajustar prioridades rápidamente, facilitando una mejor coordinación y colaboración.

Otra herramienta visual muy útil son las plantillas que recogen en una sola página los datos fundamentales de la iteración. Estas plantillas proporcionan un marco estructurado para definir tareas, estimar tiempos y asignar responsabilidades. Al utilizar plantillas de planificación, el equipo puede asegurar que el trabajo durante la iteración se mantiene enfocado al objetivo.