Al abrir un prototipo, la primera pregunta no debería ser solo dónde hay que hacer clic. También importa saber qué situación representa, qué se puede explorar y qué decisiones todavía están por tomar. Para mí, explicar ese recorrido es parte del trabajo técnico, no un añadido para cuando el proyecto ya está terminado.
Empezar por el problema concreto
Antes de enseñar una interfaz, conviene delimitar la pregunta que intenta responder. En una herramienta interactiva vinculada a una emergencia, por ejemplo, podría tratarse de mostrar cómo cambia la información disponible según el escenario, sin dar a entender que una simulación sustituye los procedimientos reales. Esa precisión ayuda a interpretar la prueba en su justa medida.
Una ficha breve puede recoger el contexto, el objetivo y el tipo de interacción previsto. No hace falta convertirla en una memoria extensa: basta con que alguien que llega por primera vez entienda qué está viendo y por qué se ha construido.
Hacer visible el estado
En un prototipo interactivo, los estados importan tanto como la pantalla inicial. Conviene indicar qué ocurre al cambiar una opción, qué información depende de esa elección y qué partes son todavía provisionales. Así, una persona colaboradora puede valorar la lógica de la prueba sin confundir una decisión pendiente con un fallo.
Dejar claro qué queda fuera
Una demo no tiene que aparentar ser un producto cerrado. Señalar sus límites —datos de ejemplo, funciones incompletas o aspectos aún sin validar— hace más útil la conversación que genera. Cuando reúno proyectos y pruebas, quiero que cada pieza permita entender tanto lo que explora como el punto en el que se encuentra.