Guía de Metodología para el prototipado y testeo de servicios digitales

1. Propósito y alcance

Esta guía entrega orientaciones prácticas para construir prototipos y testearlos antes de implementar un servicio digital, reduciendo el riesgo de invertir tiempo y recursos en soluciones que no responden a la necesidad real de las personas.

Esta guía está fundamentada en la Fase 6, Prototipado y Testeo, de la guía Permitido Innovar del Laboratorio de Gobierno (2018). En el modelo de ocho fases de esa guía, el Prototipado y Testeo llega después de la Selección de Conceptos (Fase 5) y antes del Pilotaje y Evaluación (Fase 7). Recibe como insumo un concepto de solución ya priorizado y entrega como producto un prototipo testeado y validado.

2. Público objetivo

Esta guía está dirigida a:

• Equipos de diseño y desarrollo que necesitan validar una solución antes de construirla por completo.
• Product Owners y responsables de proyecto que deben decidir qué se prototipa primero.
• Facilitadores/as de innovación que conducen talleres de prototipado y sesiones de testeo.
• Unidades dueñas de un servicio que participan como contraparte en el proceso de co-creación.

3. Principios del prototipado y testeo

El Laboratorio de Gobierno resume el valor de prototipar y testear en cuatro razones. Esta guía las presenta como principios rectores, junto con dos principios adicionales sobre cómo se ejecuta el proceso.

Desarrollar un entendimiento común

Un prototipo construye un entendimiento compartido de lo que realmente significa una idea de solución: cómo se ve, cómo se siente, cómo interactúan las personas con ella. Mientras la solución exista sólo como descripción verbal, cada persona del equipo puede estar imaginando algo distinto.

Comunicar de forma tangible

Un prototipo expresa el concepto en una forma tangible. Quienes retroalimentan la propuesta pueden dar comentarios más concretos y útiles cuando pueden ver, tocar o interactuar con algo, en lugar de solo escuchar una explicación.

Probar con usuarios reales

Prototipar permite conectar el concepto con los usuarios, de manera que ellos entreguen comentarios e ideas directamente, en lugar de que el equipo decida en base a supuestos internos.

Mitigar el riesgo

La mitigación del riesgo es el corazón de prototipar y testear. Cuando existe incertidumbre sobre una nueva solución, el prototipado permite reducirla a través de ciclos de prueba e iteración, antes de comprometer los recursos necesarios para implementar la solución a mayor escala.

Prototipar y testear temprano permite que el aprendizaje comience desde el inicio del proyecto, cuando los riesgos todavía pueden mitigarse a bajo costo, a diferencia de detectar los mismos problemas recién en la etapa de implementación, cuando corregirlos resulta mucho más caro.

Aprender haciendo

Prototipar es un proceso activo, no uno de análisis puramente teórico: se construye, se prueba, se aprende y se itera. Este ciclo se repite tantas veces como sea necesario dentro de un mismo proyecto.

Co-crear con usuarios, servidores públicos y personas expertas

Las iteraciones del prototipo no dependen solo del criterio del equipo de diseño o desarrollo: se retroalimentan con usuarios finales, con los propios servidores públicos que entregan el servicio, y con personas expertas cuando la complejidad del problema lo requiere.

4. Niveles de resolución del prototipo y qué se puede prototipar

Esta sección explica los tres niveles de resolución de un prototipo y las dos dimensiones de lo que se puede prototipar, tal como los define la metodología del Laboratorio de Gobierno.

4.1 Qué se puede prototipar

Un prototipo no está referido necesariamente a un producto o a un objeto físico. De hecho casi cualquier aspecto de una solución se puede prototipar. Hay dos formas de abordarlo:

• Prototipar la experiencia del servicio: permite visualizar y materializar, de forma integral, la cronología completa de acciones que realiza el usuario al interactuar con el servicio. El principal desafío es representar algo intangible -la experiencia- de forma concreta.
• Prototipar puntos de contacto específicos: permite visualizar y materializar los elementos con los que el usuario interactúa directamente. En un servicio digital, los puntos de contacto suelen ser pantallas, formularios, notificaciones, mensajes de error, correos automáticos, o incluso la forma en que el servicio se conecta con otro sistema del Estado.

Prototipar primero la experiencia completa suele ayudar a identificar cuáles de esos puntos de contacto son los más críticos de prototipar en detalle a continuación.

4.2 Niveles de resolución

El proceso de prototipado se puede abordar en distintos niveles de resolución, que aumentan progresivamente a medida que una idea se va validando.

• Nivel conceptual: es la representación más básica de la idea, generalmente a través de historias o relatos que narran cómo se espera que funcione la propuesta. Sirve para poner a prueba si el concepto general tiene sentido, antes de invertir en cualquier detalle de diseño.
• Nivel sensorial: dentro de la experiencia completa del servicio, se eligen puntos de contacto específicos y se desarrolla una primera aproximación a cómo se deberían ver y sentir superficialmente, sin entrar todavía en el detalle de cómo funcionan.
• Nivel funcional: permite poner a prueba las funcionalidades reales de los puntos de contacto elegidos, y evaluar la factibilidad técnica de implementarlos. Es una preparación directa para el pilotaje.

Conviene avanzar de un nivel al siguiente solo cuando el nivel anterior ya permitió aprender lo que se necesitaba aprender en esa etapa.

5. El ciclo de prototipado y testeo

El ciclo construir–probar–aprender–iterar es la secuencia que resume el proceso de prototipado y testeo: se construye el prototipo, se prueba con usuarios, se aprende de lo observado, y se itera antes de volver a construir. El ciclo se repite tantas veces como sea necesario dentro de un mismo proyecto, generalmente aumentando el nivel de resolución en cada vuelta

5.1 Definir qué prototipar y la hipótesis

Antes de construir nada, el equipo decide qué va a prototipar -la experiencia completa o puntos de contacto específicos- y qué hipótesis busca poner a prueba.

Actividades clave:

• Conocer el detalle de lo que se necesita crear.
• Decisión sobre si se prototipará la experiencia completa o puntos de contacto específicos.
• Definición de las hipótesis que se quieren poner a prueba.

5.2 Elegir el nivel de resolución y construir el prototipo

El equipo elige el nivel de resolución adecuado para la hipótesis que se quiere testear y la técnica de construcción más apropiada.

Actividades clave:

• Selección del nivel de resolución (conceptual, sensorial o funcional) según la sección 4.2.
• Selección de la técnica de construcción más adecuada (ver sección 6).
• Construcción del prototipo con el equipo.

5.3 Planificar el testeo

El equipo define con quién se testeará, cómo va a medir el resultado, y el paso a paso para ejecutar el testeo.

Actividades clave:

• Definición de con quién se realizará el testeo: usuarios, servidores públicos o personas expertas, según corresponda.
• Definición de cómo se medirá si la hipótesis se cumple.
• Detalle del paso a paso: dónde, cuándo, por cuánto tiempo, y qué se necesita preparar.

5.4 Ejecutar el testeo

El equipo aplica el testeo dejando que cada participante viva la experiencia del prototipo sin inducir sus respuestas.

Actividades clave:

• Aplicación del testeo según el proceso definido.
• Uso de preguntas abiertas, cerradas, semi-abiertas o cerradas para evaluar, según lo que se necesite indagar.
• Registro de todos los momentos de la experiencia (fotos, notas, grabación cuando corresponda).

5.5 Consolidar el aprendizaje

El equipo reúne lo observado en todas las sesiones usando una pauta de retroalimentación común, para identificar patrones en vez de reaccionar a un solo comentario.

Actividades clave:

• Responder cuatro preguntas: ¿qué funcionó?, ¿qué podría mejorar?, ¿qué preguntas surgieron?, ¿qué nuevas ideas surgieron?
• Contraste de los resultados con la hipótesis definida.

5.6 Iterar el prototipo

Con el aprendizaje consolidado el equipo decide si valida la solución, la ajusta, o la descarta en busca de una alternativa distinta.

Actividades clave:

• Decisión sobre validar, ajustar o descartar la solución evaluada.
• Ajuste del prototipo según lo decidido.
• Repetición del ciclo tantas veces como sea necesario, generalmente subiendo de nivel de resolución en cada vuelta.

6. Herramientas y plantillas de apoyo

Esta sección detalla algunas técnicas y plantillas de la Fase 6 de Permitido Innovar mencionadas en las secciones anteriores: para qué sirve cada una, cómo usarla en términos generales, y un ejemplo concreto de aplicación.

6.1 Viaje de Usuario Aspirado

Para qué sirve: Representar, en un prototipo de nivel conceptual, cómo sería la experiencia ideal de un usuario con el servicio rediseñado, a partir del viaje de usuario real levantado en la investigación previa.

Cómo usarlo:

1. Tomar como base el viaje del usuario actual y construir un nuevo viaje que describa cómo deberían ocurrir las cosas en un estado ideal, incorporando las ideas de solución priorizadas.

2. Para cada momento del viaje, anotar qué hace el usuario, con qué o quién interactúa.

3. Revisar cada momento para lograr una experiencia satisfactoria.

Ejemplo: si el viaje actual muestra que un usuario se siente confundido al no saber en qué etapa está su solicitud, el viaje aspirado plantea que, en ese mismo momento, debería sentirse tranquilo porque puede ver el estado con claridad en un solo lugar.

6.2 Storyboard o Guión Gráfico

Para qué sirve: Representar, mediante una secuencia de imágenes simples, cómo interactúa un usuario con la solución propuesta, a nivel conceptual.

Cómo usarlo:

1. Escribir la historia que se quiere contar, incluyendo el viaje del usuario, los personajes involucrados y el escenario donde ocurre.

2. Dibujar imágenes simples para cada momento, lo suficientemente claras para transmitir la idea, pero abiertas para generar preguntas.

3. Mostrar el storyboard a un usuario y pedirle que describa, con sus propias palabras, lo que está pasando en cada viñeta.

Ejemplo: representar en viñetas cómo una usuaria de un centro de salud viviría un nuevo sistema de toma de horas, antes de construir cualquier prototipo funcional.

6.3 Role Playing o Juego de Roles

Para qué sirve: aunque no requiere ninguna pantalla, permite testear conceptualmente el flujo de un servicio digital antes de construir una sola interfaz, actuando paso a paso lo que haría un usuario al navegar la futura aplicación o sitio.

Cómo usarlo:

1. Definir qué flujo del servicio digital se quiere poner a prueba con esta técnica.

2. Asignar los roles a representar: alguien hace de "sistema" y muestra tarjetas de papel que representan cada pantalla en el momento correcto, mientras otra persona actúa de usuario tomando decisiones como si estuviera usando la aplicación real. Idealmente, alguien más queda como observador no participante.

3. Representar el flujo completo, estando abiertos a improvisar ajustes durante la actuación.

4. Al finalizar registrar qué funcionó, qué podría mejorar, qué preguntas surgieron y qué nuevas ideas aparecieron.

Ejemplo: un equipo que diseña una nueva aplicación de agendamiento de horas actúa el flujo completo antes de dibujar ninguna pantalla: una persona va mostrando tarjetas de papel que representan cada paso de la app, mientras otra decide qué "tocaría" en cada una, lo que permite detectar pasos confusos o faltantes de forma muy temprana.

6.4 Prototipos rápidos

Para qué sirve: materializar en papel, de forma simple y a bajo costo, una primera versión de una pantalla, mensaje o notificación de un servicio digital, para testear rápidamente el concepto detrás de ella antes de construir nada funcional.

Cómo usarlos:

1. Elegir un punto de contacto digital (una pantalla, un mensaje, una notificación) y la hipótesis que se quiere poner a prueba con él.

2. Dibujar el prototipo en papel con materiales simples, priorizando la velocidad por sobre el acabado.

3. Presentarlo a potenciales usuarios sin dar demasiadas instrucciones y registrar su reacción.

4. Contrastar lo observado con la hipótesis inicial.

Ejemplo: para decidir cómo notificar a un usuario que su solicitud fue aprobada, el equipo dibuja en papel tres variantes de una notificación y las muestra, sin dar instrucciones, a personas que no participaron en su diseño, para ver cuál transmite la información con mayor claridad antes de programar nada.

6.5 Prototipado de aplicaciones digitales

Para qué sirve: llevar una idea de aplicación o plataforma digital, paso a paso, desde un boceto en papel hasta un prototipo funcional testeable, siguiendo un nivel de resolución creciente.

Cómo usarlo:

1. Empezar con un boceto en papel que responda qué servicio se entrega, por qué es importante, qué contenidos tendrá y cómo será.

2. Testear el boceto con potenciales usuarios e incorporar sus comentarios en un esqueleto (wireframe): una ilustración de cada pantalla centrada en qué hace, más que en cómo se ve.

3. Testear el esqueleto y avanzar a una maqueta (mockup) que ya incorpore colores, tipografías y otros elementos visuales, idealmente construida en una herramienta de prototipado digital (por ejemplo, Figma u otra equivalente) que permita simular la navegación entre pantallas sin programar.

4. Llegar a un prototipo funcional y navegable, fácilmente modificable, que incluya tanto la visualización de las interfaces como sus funcionalidades.

Ejemplo: una aplicación de trámites en línea puede pasar de un boceto a lápiz de la pantalla principal, a un esqueleto que define dónde va cada botón, a una maqueta interactiva con la identidad visual institucional, y finalmente a un prototipo navegable en el que se puede simular el trámite completo como si fuera la aplicación real.

6.6 Testeo remoto de prototipos digitales

Para qué sirve: complementar el testeo presencial cuando se necesita llegar a usuarios que no pueden asistir a una sesión moderada, aprovechando que un prototipo digital puede compartirse como un enlace.

Cómo usarlo:

1. Preparar el prototipo navegable y un guión de tareas igual de claro que en un testeo presencial.

2. Enviar el prototipo junto con las instrucciones escritas a los participantes, o usar una herramienta de grabación de pantalla que registre su interacción mientras las realizan.

3. Revisar las grabaciones o respuestas para identificar en qué paso los participantes se detienen o se confunden.

Ejemplo: en vez de citar a diez personas a una sala, el equipo envía el enlace de un prototipo navegable junto con tres tareas escritas, y cada persona graba su pantalla mientras las realiza en el horario que le acomode, lo que permite testear con usuarios de regiones distintas sin costo de traslado.

6.7 Planificación de testeo

Para qué sirve: Preparar con anticipación cómo se va a testear un prototipo, para no improvisar el proceso ni perder la posibilidad de aprender de forma ordenada.

Cómo usarla:

1. Definir la hipótesis que se quiere validar con este testeo específico.

2. Definir cómo se va a medir si esa hipótesis se cumple (qué indicadores observar).

3. Detallar el paso a paso: con quién se realizará, dónde, cuándo, por cuánto tiempo, y qué se necesita preparar previamente.

Ejemplo: para testear un boceto de formulario, el equipo define la hipótesis ("simplificar los campos reduce el abandono"), decide medirlo observando si los participantes lo completan sin detenerse a preguntar, y planifica cinco sesiones de 20 minutos con usuarios reclutados en la sala de espera del servicio.

6.8 Pauta de retroalimentación

Para qué sirve: Consolidar y sistematizar lo aprendido en cada testeo, evitando que el aprendizaje quede solo en la memoria de quienes participaron en la sesión.

Cómo usarla:

1. Al finalizar cada testeo, reunir al equipo y responder cuatro preguntas: ¿qué funcionó?, ¿qué podría mejorar?, ¿qué preguntas surgieron?, ¿qué nuevas ideas surgieron?

2. Registrar las respuestas por escrito, no solo comentarlas verbalmente.

3. Usar este registro como insumo directo para decidir cómo iterar el prototipo.

Ejemplo: tras testear un prototipo funcional de una aplicación, el equipo registra que "funcionó" la navegación principal, "podría mejorar" la claridad del botón de confirmación, "surgió la pregunta" de qué pasa si el usuario se equivoca de trámite, y "surgió la idea" de agregar un buscador.

7. Caso de aplicación

El siguiente caso ilustra cómo se aplican, en conjunto, los niveles de resolución, el ciclo de fases, y las herramientas descritas en esta guía, a lo largo de tres rondas de prototipado y testeo con resolución creciente.

Contexto

Un equipo debe rediseñar cómo las personas usuarias conocen el estado de su solicitud de un beneficio social, después de priorizar la idea de un sistema integral de seguimiento de solicitudes.

7.1 Nivel conceptual: Storyboard

El equipo redacta la hipótesis: "mostrar el estado en un solo lugar visible reducirá las llamadas a la mesa de ayuda". Construye un storyboard de seis viñetas que muestra a un usuario revisando el estado de su solicitud desde una única pantalla, y se lo muestra a tres personas que han usado el servicio recientemente, pidiéndoles que describan lo que entienden en cada viñeta. La pauta de retroalimentación registra que dos de las tres personas no entienden qué significa uno de los estados intermedios, lo que lleva al equipo a simplificar el lenguaje antes de avanzar al siguiente nivel.

7.2 Nivel sensorial: prototipos rápidos y testeo

Con el concepto ya ajustado el equipo construye un prototipo rápido en papel de la pantalla de estado con distintas variantes de cómo mostrar la línea de tiempo. Realiza un testeo de 45 minutos en la sala de espera del servicio, mostrando el papel a ocho personas sin muestreo predefinido, y registrando cuál variante se entiende más rápido.

7.3 Nivel funcional: prototipado de aplicaciones digitales

El equipo toma la variante que mejor resultó y la lleva a un esqueleto digital que testea con cinco usuarios adicionales siguiendo esta vez una planificación de testeo formal, con hipótesis y forma de medición definidas de antemano. Después de dos rondas de ajuste, construye una maqueta con la identidad visual institucional y un prototipo funcional navegable.

8. Recomendaciones para aplicar esta guía en el sector público

Los principios y el ciclo descritos en esta guía son aplicables a cualquier proceso de diseño de producto. Esta sección reúne las consideraciones específicas para aplicarlos dentro de una institución pública.

Reclutar sin generar carga indebida sobre otras reparticiones

Cuando se convoca a funcionarios/as públicos como participantes del testeo (por ejemplo, para servicios de uso interno del Estado), conviene coordinar con sus jefaturas y limitar el tiempo solicitado, para no convertir la convocatoria en una carga adicional sobre otras unidades.

Resguardar el consentimiento informado y los datos personales de los participantes

Toda persona que participa en un testeo debe ser informada de para qué se usará su participación y, cuando corresponda, dar su consentimiento explícito antes de registrar la sesión. El tratamiento de los datos personales recolectados debe ajustarse a la normativa de protección de datos vigente.

Incorporar la accesibilidad en la planificación del testeo

La convocatoria de participantes y el paso a paso del testeo deben considerar explícitamente a personas con discapacidad, personas mayores y personas con distinto nivel de alfabetización digital, y no solo a usuarios que ya están familiarizados con trámites en línea.

Sentar las bases para la gestión del cambio desde el testeo

Conviene involucrar tempranamente a los servidores públicos que van a operar el servicio como parte de quienes testean el prototipo, no solo a los usuarios finales. Esa participación puede empezar aquí, en el testeo, en lugar de recién al momento de escalar la solución.

Documentar los aprendizajes también como evidencia de uso responsable de recursos

Las pautas de retroalimentación y el plano del servicio de cada ronda de prototipado pueden servir como evidencia de que las decisiones de diseño se tomaron con base en evidencia y no solo en criterio interno, lo que resulta útil también para efectos de rendición de cuentas.