Hay un momento en casi cualquier sesión de test de usabilidad que lo dice todo. El usuario llega a una pantalla, titubea, teclea algo y levanta la vista buscando aprobación. No está explorando el producto. Está intentando adivinar qué quieres que haga.
En ese instante, el test ha dejado de medir usabilidad. Está midiendo obediencia. Y el culpable, casi siempre, es el propio prototipo.
- Un prototipo de alta fidelidad que parece una app real activa el modo "examen" en el usuario: respuestas performativas, no comportamiento auténtico.
- Un artefacto descuidado o incompleto genera ruido distinto pero igual de dañino: el usuario corrige mentalmente el diseño en lugar de interactuar con él.
Fidelidad: El Lujo que Distorsiona la Realidad
Existe una confusión muy extendida entre equipos de producto: cuanto más pulido el prototipo, mejor el test. La lógica parece sólida. En la práctica, es una trampa.
Cuando el artefacto se parece demasiado a un producto terminado, el usuario ajusta inconscientemente su comportamiento. Sabe que no es real —el login que no funciona, el menú que no tiene back, el dato inventado en el perfil— y esa distancia cognitive le convierte en actor, no en sujeto de estudio. Sus respuestas te dicen cómo cree que debería usar una app así, no cómo usaría la tuya.
La fidelidad de un prototipo no es un indicador de calidad del test. Es una variable de diseño que debes controlar deliberadamente.
La solución no es volver siempre al papel y los post-its. Es entender que el nivel de fidelidad debe responder a una pregunta concreta. ¿Estás validando arquitectura de información? Un wireframe funcional es suficiente. ¿Estás testeando microcopy o tono emocional? Necesitas algo más cercano al producto real, pero con las costuras visibles borradas. La decisión es estratégica, no estética. Y si tienes dudas sobre cuándo construir antes de validar, los errores más caros de producto arrancan exactamente aquí.
Artefactos Descartables: Pensar con las Manos, No Entregar con Ellas
El otro extremo del problema es igualmente costoso: equipos que confunden cualquier artefacto con un entregable, y que por tanto invierten tiempo puliendo bocetos que deberían ser desechables.
Los artefactos descartables —sketches rápidos, flujos en papel, maquetas de cartón conceptual— tienen un propósito muy específico: externalizar el pensamiento del diseñador para poder criticarlo, no para mostrárselo al cliente ni pasarlo al sprint de desarrollo. Son herramientas cognitivas, no comunicativas.
El problema aparece cuando el equipo cae en el sesgo del coste hundido: "hemos invertido dos horas en este flujo, no podemos tirarlo". Sí podéis. De hecho, debéis. Un artefacto que te ha ayudado a pensar ya ha cumplido su función, aunque acabéis descartando la dirección. Este tipo de disfunción tiene mucho que ver con el rol del diseñador dentro del equipo de producto y la presión constante de demostrar output entregable en lugar de impacto en la decisión.
En Room 714 auditamos con frecuencia procesos de diseño donde el 60% del tiempo se invierte en prototipos que nadie va a testear y el 40% restante en tests que producen datos contaminados. Si tu equipo está en ese ciclo, tiene sentido parar y recalibrar antes del próximo sprint. Una conversación de una hora puede ahorrarte varios ciclos de iteración vacíos.
