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

Orientaciones prácticas para construir prototipos y testearlos antes de implementar un servicio digital, reduciendo el riesgo de invertir en soluciones que no responden a la necesidad real de las personas.

Qué resuelve y a quién está dirigido

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. Sintetiza prácticas de prototipado y testeo de fuentes nacionales e internacionales vigentes, incluyendo la metodología del Laboratorio de Gobierno, el Service Manual de GOV.UK y las prácticas de investigación del U.S. Web Design System (USWDS), adaptadas para el diseño y evaluación de servicios digitales del Estado.

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.

Cuándo utilizarlo y cuándo no

Utilízala cuando:

• Ya tienes un concepto o idea de solución (propia o proveniente de una investigación previa) y necesitas validarlo antes de construirlo a mayor escala.
• Necesitas decidir qué nivel de resolución (conceptual, sensorial o funcional) usar para poner a prueba una hipótesis específica.
• Debes testear una interfaz, flujo o mensaje con personas usuarias, servidores públicos o personas expertas antes de implementarlo.

No la utilices cuando:

• Aún no tienes una hipótesis ni evidencia sobre el problema: primero levanta esa evidencia con la Guía de metodologías de investigación usuaria.
• Ya cuentas con un prototipo funcional validado y necesitas organizar cómo el equipo construye e implementa la solución a escala: consulta la Guía de gestión ágil de proyectos digitales.
• Necesitas medir el impacto real de un cambio ya implementado (por ejemplo, si efectivamente redujo las llamadas a mesa de ayuda): eso requiere medición posterior con el servicio en producción, no un testeo de prototipo.

Reglas o criterios principales

• 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 solo 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. 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.

Cómo aplicarlo

Qué evaluar y cómo

Antes de decidir el nivel de detalle de un prototipo, conviene tener claro qué pregunta se busca responder y qué se puede prototipar.

Tipos de evaluación según la pregunta. Prototipar y testear no siempre responde la misma pregunta:

• Prototipado: responde si un concepto o idea de solución tiene sentido para las personas usuarias, antes de invertir en construir nada funcional.
• Prueba de concepto: responde si algo es técnicamente viable de construir, más allá de si conviene o no hacerlo.
• Prueba de usabilidad: responde si las personas pueden completar una tarea específica usando una interfaz concreta, y con qué nivel de dificultad.
• Evaluación de accesibilidad: responde si una interfaz cumple los estándares de accesibilidad vigentes y es utilizable con tecnología de asistencia.
• Factibilidad técnica: responde si una solución se puede integrar con los sistemas, datos o procesos ya existentes del Estado.

Estos tipos de evaluación no son excluyentes entre sí, y varios pueden aplicarse en distintos momentos sobre un mismo prototipo.

Niveles de resolución. Este es un eje distinto del tipo de evaluación: un mismo nivel de resolución puede usarse tanto para una prueba de concepto como para una prueba de usabilidad. Conviene avanzar de un nivel al siguiente solo cuando el nivel anterior ya permitió aprender lo que se necesitaba aprender en esa etapa.

• Nivel conceptual (equivalente a un sketch): 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 (equivalente a un prototipo click-through): 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 (equivalente a un prototipo de código, testeable incluso con tecnología de asistencia como lectores de pantalla): 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.

Qué se puede prototipar. Un prototipo no está referido necesariamente a un producto o a un objeto físico; casi cualquier aspecto de una solución se puede prototipar:

• 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.
• Prototipar puntos de contacto específicos: permite visualizar y materializar los elementos con los que el usuario interactúa directamente (pantallas, formularios, notificaciones, mensajes de error, correos automáticos, o 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.

El ciclo de prototipado y testeo

El ciclo definir–construir–probar–aprender–iterar resume el proceso: primero se define qué prototipar y qué hipótesis se pondrá a prueba, luego se construye el prototipo, se prueba con personas usuarias y relacionadas al servicio, se aprende de lo observado, y se itera antes de volver a construir. Se repite tantas veces como sea necesario, generalmente aumentando el nivel de resolución en cada vuelta.

1. Definir qué prototipar y la hipótesis. El equipo decide si prototipará la experiencia completa o puntos de contacto específicos, qué tipo de evaluación corresponde y qué hipótesis busca poner a prueba, retomando los hallazgos de la investigación usuaria cuando corresponda. La evidencia que se busca debe corresponder exactamente a lo que la hipótesis afirma: una técnica que mide la comprensión de un concepto no permite concluir que un cambio reducirá las llamadas a mesa de ayuda una vez implementado; confirmar ese tipo de impacto requiere medición posterior, con el servicio ya funcionando. Entregable esperado: hipótesis definida; alcance del prototipo acotado.

2. Elegir el nivel de resolución y construir el prototipo. El equipo elige el nivel de resolución adecuado para la hipótesis y la técnica de construcción más apropiada, utilizando los componentes y patrones del UI Kit del Sistema de Diseño cuando el nivel de resolución lo permita, en vez de crear elementos visuales desde cero. Entregable esperado: prototipo listo para testear.

3. Planificar el testeo. El equipo define con quién se testea (personas usuarias, servidores públicos o personas expertas, procurando incluir a personas en situación de discapacidad, personas mayores y personas con distinto nivel de alfabetización digital), cómo va a medir el resultado, el paso a paso, y prepara el consentimiento informado que se solicitará a cada participante. Entregable esperado: planificación de testeo (hipótesis, forma de medición, paso a paso).

4. Ejecutar el testeo. El equipo aplica el testeo dejando que cada participante viva la experiencia del prototipo sin inducir sus respuestas. Puede ser moderado (alguien del equipo guía la sesión) o no moderado (la persona completa las tareas por su cuenta y el equipo revisa el resultado después). Se registran todos los momentos de la experiencia, resguardando los archivos según lo acordado en el consentimiento informado. Entregable esperado: registro de las sesiones de testeo.

5. Consolidar el aprendizaje. El equipo reúne lo observado en todas las sesiones usando una pauta de retroalimentación común, respondiendo cuatro preguntas (¿qué funcionó?, ¿qué podría mejorar?, ¿qué preguntas surgieron?, ¿qué nuevas ideas surgieron?) y contrastando los resultados con la hipótesis definida. Entregable esperado: pauta de retroalimentación consolidada.

6. Iterar el prototipo. Con el aprendizaje consolidado, el equipo decide si valida la hipótesis, la ajusta, o la descarta en busca de una alternativa distinta, y repite el ciclo tantas veces como sea necesario. Entregable esperado: prototipo refinado, o decisión documentada de descarte.

Herramientas

• Viaje de Persona Usuaria Aspirado. Representa, en un prototipo de nivel conceptual, cómo sería la experiencia ideal de una persona usuaria con el servicio rediseñado, a partir del viaje de usuario real levantado en la investigación previa.
• Storyboard o Guión Gráfico. Representa, mediante una secuencia de imágenes simples, cómo interactúa un usuario con la solución propuesta, a nivel conceptual.
• Prototipos rápidos. Materializan en papel, de forma simple y a bajo costo, una primera versión de una pantalla, mensaje o notificación, para testear rápidamente el concepto antes de construir nada funcional.
• De boceto a prototipo funcional. Sube progresivamente de resolución —de boceto a wireframe, a maqueta, a prototipo funcional— hasta llegar a una interfaz navegable y testeable, utilizando los componentes del UI Kit del Sistema de Diseño en la etapa de maqueta en vez de crear elementos visuales desde cero. En el nivel funcional ya es posible testear con tecnología de asistencia.
• Testeo remoto de prototipos digitales. Complementa el testeo presencial cuando se necesita llegar a personas que no pueden asistir a una sesión en vivo, aprovechando que un prototipo digital puede compartirse como un enlace.
• Planificación de testeo. Prepara con anticipación cómo se va a testear un prototipo: hipótesis, forma de medición, y el paso a paso (con quién, dónde, cuándo, por cuánto tiempo, qué preparar).
• Pauta de retroalimentación. Consolida y sistematiza lo aprendido en cada testeo, evitando que el aprendizaje quede solo en la memoria de quienes participaron en la sesión.

Ejemplos recomendados y no recomendados

Recomendado — caso de aplicación con resolución creciente: un equipo debe rediseñar cómo las personas usuarias conocen el estado de su solicitud de un beneficio social.

• Nivel conceptual (Storyboard): el equipo redacta la hipótesis de comprensión "las personas entienden en qué consiste cada estado de su solicitud al verlos representados en una sola pantalla" —distinta de la hipótesis de impacto "esto reducirá las llamadas a la mesa de ayuda", que solo podrá confirmarse más adelante con datos de uso—. Construye un storyboard de seis viñetas y se lo muestra a tres personas que usaron el servicio recientemente. La pauta de retroalimentación registra que dos de las tres no entienden uno de los estados intermedios, lo que lleva a simplificar el lenguaje antes de avanzar.
• Nivel sensorial (prototipos rápidos): con el concepto ajustado, el equipo construye un prototipo rápido en papel con distintas variantes de la línea de tiempo, y testea 45 minutos con ocho personas en la sala de espera del servicio.
• Nivel funcional (de boceto a prototipo funcional): toma la variante que mejor resultó y la lleva a un esqueleto digital que testea con cinco personas usuarias adicionales, esta vez con una planificación de testeo formal. Tras dos rondas de ajuste, construye una maqueta con la identidad visual institucional y un prototipo funcional navegable.

No recomendado — riesgos comunes a evitar en cada etapa del ciclo:

• Prototipar sin una hipótesis clara, lo que dificulta interpretar el testeo después.
• Saltar directo a un nivel de resolución más alto del necesario para la pregunta que se quiere responder.
• Testear solo con personas cercanas al equipo, sin haber planificado antes cómo se interpretarán los resultados.
• Intentar "vender" la idea a la persona que testea, en vez de dejarla vivir la experiencia libremente.
• Quedarse con el comentario más llamativo de una sola sesión, en lugar de identificar patrones entre varias.
• Iterar indefinidamente sin nunca decidir avanzar, o al contrario, avanzar sin haber iterado lo suficiente.

Consideraciones de contenido y accesibilidad

• Al planificar el testeo, procura incluir a personas en situación de discapacidad, personas mayores y personas con distinto nivel de alfabetización digital, y no solo a usuarios ya familiarizados con trámites en línea: su participación permite identificar problemas de accesibilidad y usabilidad que de otra forma no aparecerán.
• A partir del nivel funcional, testea también con tecnología de asistencia (como lectores de pantalla), ya que los niveles conceptual y sensorial no permiten evaluar accesibilidad técnica real.
• Prepara y entrega a cada participante un consentimiento informado que explique para qué se usará su participación y cómo se resguardarán sus datos personales, conforme a la normativa de protección de datos vigente.
• Usa los componentes y patrones del UI Kit del Sistema de Diseño desde el nivel de maqueta en adelante, en lugar de crear elementos visuales desde cero, para heredar la accesibilidad ya resuelta en esos componentes.

Checklist de implementación o revisión

Recursos y contenidos relacionados

Plantillas de apoyo:

• Plantilla de Storyboard.
• Plantilla de planificación de testeo.
• Plantilla de pauta de retroalimentación.

Guías relacionadas del sistema de diseño:

• Guía de metodologías de investigación usuaria.
• Guía de gestión ágil de proyectos digitales.
• Diseño de servicios digitales.
• Fundamentos y Componentes (UI Kit del Sistema de Diseño).

Evidencia o fuentes

Los principios y técnicas de esta guía sintetizan marcos reconocidos de prototipado y evaluación de servicios digitales, adaptados para su aplicación en el sector público. El ciclo de prototipado y testeo, y la organización general de esta guía, corresponden a una sistematización propia elaborada para este contexto.

• Government Digital Service. (s.f.). Prototyping. GOV.UK Prototype Kit.
• Government Digital Service. (s.f.). Using moderated usability testing. Service Manual, GOV.UK.
• General Services Administration. (s.f.). Research. U.S. Web Design System (USWDS).
• Laboratorio de Gobierno. (2018). Permitido Innovar: ¿Cómo podemos resolver problemas públicos a través de Proyectos de Innovación? Fase 6: Prototipado y Testeo.