Elegir un prototipo no consiste en decidir cuánto debe parecerse al producto final. Consiste en identificar qué duda importante conviene resolver antes de invertir más tiempo y presupuesto. Un boceto puede aclarar si una propuesta se entiende; no demuestra que la tecnología pueda sostenerla. Una prueba técnica puede reducir esa duda, pero no confirma que alguien quiera usar el producto.
Para responsables de producto, negocio y tecnología, la regla práctica es sencilla: el formato debe responder a la incertidumbre principal, con el menor coste y realismo suficientes. Así se evita construir de más y, también, interpretar una reacción favorable como prueba de viabilidad o de uso real.
Empieza por nombrar la incertidumbre
Antes de abrir una herramienta de diseño o escribir código, concreta qué decisión dependerá del aprendizaje. Puede tratarse de varias preguntas, pero conviene priorizar una por experimento:
- Problema: ¿el público experimenta una necesidad relevante y reconoce sus consecuencias?
- Comprensión: ¿entiende qué ofrece la propuesta y qué debe hacer?
- Deseabilidad: ¿la solución resulta suficientemente valiosa para que la persona quiera avanzar?
- Viabilidad técnica: ¿pueden funcionar las integraciones, los datos o las restricciones relevantes?
- Operación: ¿se puede prestar el servicio con las personas, los procesos y los tiempos disponibles?
Una entrevista o una prueba de concepto de servicio quizá sea más adecuada que un prototipo visual si todavía no está claro si el problema importa. En cambio, si las personas describen una necesidad concreta, pero no se entiende cómo completar la tarea, puede ser útil probar una estructura o un recorrido.
Boceto o wireframe: comprobar estructura y comprensión
Un boceto en papel o un wireframe sencillo permite explorar jerarquía, contenido y organización de pantallas sin invertir en detalles visuales. Es útil cuando se necesita saber si una persona identifica la acción principal, comprende las etiquetas o encuentra la información que necesita.
Preséntalo con una tarea concreta, por ejemplo, «encuentra cómo cambiar la dirección de entrega», en lugar de preguntar si la pantalla gusta. Observa qué intenta hacer, dónde se detiene y qué interpreta de los elementos. Si varias personas se confunden con la misma instrucción, hay una señal para revisar el diseño.
Qué puede aportar: indicios sobre comprensión, jerarquía y estructura. Qué no demuestra: la calidad de la interfaz terminada, la facilidad de uso en producción ni la disposición a pagar. Al ser esquemático, puede dejar fuera señales visuales que influirían en la decisión.
Prototipo navegable: evaluar recorridos sin construir el producto
Un prototipo navegable simula pantallas y transiciones para que alguien recorra un flujo, como registrarse, comparar opciones o iniciar una solicitud. Es apropiado cuando la pregunta pendiente se refiere a la secuencia de pasos, la claridad de las decisiones o las fricciones entre pantallas.
Define una tarea realista y deja que la persona avance sin instrucciones sobre dónde pulsar. Registra errores, retrocesos, dudas, abandonos y momentos en los que pide ayuda. Si el flujo contiene estados importantes —como un error, una confirmación o una alternativa—, inclúyelos: un recorrido que solo funciona en el camino ideal puede ocultar problemas.
El prototipo puede dar una impresión convincente, pero los elementos simulados no equivalen a funciones operativas. No permite concluir que el rendimiento, la seguridad, las integraciones o el comportamiento con datos reales sean adecuados. Aclara qué partes son simuladas para no confundir una demostración fluida con un producto ya viable.
Simulación o servicio manual: probar la experiencia completa
Cuando la propuesta depende de trabajo humano detrás de la interfaz, una simulación permite ensayar el servicio antes de automatizarlo. Por ejemplo, un equipo puede recibir solicitudes mediante un formulario y resolverlas manualmente para observar qué información falta, cuánto esfuerzo exige cada caso y qué espera el usuario después de enviarlo.
Este enfoque resulta valioso si la incertidumbre principal es operativa: quién atiende, qué pasos se repiten, qué excepciones aparecen o dónde se generan demoras. Conviene delimitar el alcance, explicar honestamente las condiciones de la prueba y proteger cualquier información personal que se recoja. No prometas una capacidad que el equipo todavía no pueda prestar de forma consistente.
Una experiencia manual ayuda a entender el proceso, pero no prueba que la operación pueda escalar ni que una automatización futura vaya a reproducirla. Si cada caso requiere intervención excepcional, eso es un dato para la decisión, no un detalle que deba ocultarse tras una pantalla pulida.
Prueba técnica o spike: reducir riesgos de implementación
Si la duda está en una integración, un formato de datos, una restricción de arquitectura o el acceso a un sistema, una prueba técnica pequeña puede aportar más que otra ronda de diseño. El objetivo no es construir una primera versión completa, sino contestar una pregunta verificable: ¿se puede intercambiar este dato?, ¿qué limitación aparece?, ¿qué alternativa merece evaluarse?
Antes de empezar, define el alcance, el supuesto que se pone a prueba y qué resultado cambiaría la decisión. Documenta dependencias, restricciones y lo que queda sin probar. Una demostración en un entorno controlado no garantiza fiabilidad, seguridad, rendimiento ni cumplimiento en producción. Si esos aspectos son decisivos, deben tener su propia evaluación y responsables.
Cómo elegir el formato adecuado
Compara cada opción según el aprendizaje esperado, el coste de prepararla, el realismo necesario y el riesgo de que se interprete más allá de lo que demuestra. No hace falta maximizar el realismo en todos los casos: una fidelidad mayor puede distraer o inducir a confundir apariencia con funcionamiento.
- Si aún se discute qué problema importa, empieza por investigar el problema antes de prototipar la interfaz.
- Si la duda es dónde encontrar algo o cómo se entiende una pantalla, usa un boceto o wireframe.
- Si necesitas observar una secuencia de acciones, prepara un prototipo navegable con tareas concretas.
- Si el servicio exige intervención humana, simula el proceso y registra el trabajo que requiere.
- Si una dependencia técnica puede bloquear la propuesta, acota una prueba técnica a esa dependencia.
También puedes combinar formatos, pero de manera secuencial: primero una prueba barata que elimine una duda temprana y después otra más realista si la decisión sigue abierta. Así, el equipo no invierte en un recorrido detallado cuando todavía no sabe si la necesidad merece resolverse.
Participantes, señales y límites de interpretación
Selecciona participantes que se parezcan al público afectado por la decisión; la conveniencia de reclutar personas cercanas al equipo no las convierte en representativas. El número de sesiones, por sí solo, no corrige una muestra sesgada. Describe quién participó, en qué contexto y qué aspectos podrían limitar la interpretación.
Prioriza señales observables ligadas a la tarea: si la completó, dónde dudó, qué alternativa eligió o qué información solicitó. Las opiniones ayudan a explicar una reacción, pero «me gusta» no equivale a uso, adopción o compra. Tampoco una tarea exitosa en un entorno guiado demuestra que la persona volverá por iniciativa propia.
Evita preguntas que sugieran la respuesta, como «¿te parece fácil?». Es mejor pedir que la persona explique qué espera que ocurra o que intente completar una tarea sin ayuda. Anota tanto los hallazgos que confirman la hipótesis como los que la contradicen; seleccionarlos solo después de conocer el resultado facilita conclusiones prematuras.
Convertir el aprendizaje en una decisión
Antes de probar, acuerda qué resultados permitirían avanzar, qué hallazgos exigirían cambiar el enfoque y qué riesgos requieren otra evaluación. No hace falta fijar umbrales numéricos arbitrarios: importa que el equipo defina de antemano qué evidencia sería suficiente para la decisión concreta.
Después, resume la pregunta, el formato utilizado, las condiciones de la prueba, las señales observadas y las limitaciones. Decide entre iterar, revisar el problema, explorar otra solución o pasar a una validación posterior. Si el aprendizaje es inconcluso, cambia el experimento para aislar la duda en vez de presentar la incertidumbre como un resultado positivo.
Un buen prototipo no es el que parece más terminado, sino el que permite tomar una decisión mejor informada. Elegirlo según la incertidumbre mantiene el esfuerzo proporcionado al riesgo y hace explícito qué se sabe, qué sigue sin saberse y cuál es el siguiente paso razonable.