Prototipar para preguntar mejor.

Elegir una incertidumbre

Intentar probarlo todo al mismo tiempo hace difícil interpretar lo que sucede. Conviene elegir una pregunta concreta y construir solo lo necesario para observarla.

Un prototipo ambicioso, que intenta validar la idea completa de una sola vez, casi siempre termina generando resultados confusos. Si algo no funciona, no queda claro si fue la interacción, el contenido, el material o la instrucción inicial. Demasiadas variables cambiando al mismo tiempo hacen que cualquier conclusión sea, en el mejor de los casos, una intuición disfrazada de dato.

Preferimos anotar, antes de construir nada, cuál es la pregunta específica que ese prototipo va a responder, y dejar todo lo demás lo más simple y aburrido posible. Si la pregunta es sobre el gesto de activación, el resto del objeto puede ser una caja de cartón sin terminar. Nadie necesita ver el diseño final para responder una pregunta sobre un gesto.

El costo real de un prototipo

Un prototipo tiene un costo que casi nunca se calcula bien al principio: no solo el material y las horas de construcción, sino el tiempo de las personas que participan en la prueba, muchas veces sin ninguna compensación más allá de la experiencia misma.

Ese costo cambia cómo decidimos cuántas pruebas hacer y con qué nivel de detalle. No siempre tiene sentido construir cinco versiones distintas de un mecanismo si se puede aprender lo mismo con dos versiones bien elegidas y una conversación honesta con quien participó.

Tratar el tiempo de las personas que prueban un prototipo como un recurso limitado, y no como algo disponible sin costo, cambia también el tono de la prueba misma. Se vuelve menos un experimento sobre alguien y más una conversación con alguien.

Dejar visibles los límites

Las personas deben saber qué funciona y qué está simulado. Explicar los límites de una prueba evita atribuir al sistema capacidades que aún no existen y mejora la conversación sobre sus posibilidades reales.

Un truco común en pruebas tempranas es el mago detrás de la cortina: alguien del equipo activa manualmente una respuesta que, en teoría, algún día hará un sensor automático. Es una técnica válida y útil, pero solo si la persona que participa en la prueba sabe que está pasando. Si no lo sabe, la prueba mide su reacción a una magia que quizás no vamos a poder construir a tiempo ni con ese presupuesto.

Ser honestos sobre esto no le resta valor a la prueba. Permite hacer una pregunta más precisa: no si esto funcionó, sino si esto funcionara de verdad, de forma automática, seguiría teniendo sentido para la persona. Son preguntas distintas y ambas son útiles, siempre que sepamos cuál estamos haciendo.

Observar antes de explicar

Cuando algo no se entiende, la tentación es añadir una explicación. A veces resulta más útil esperar y observar qué intenta hacer la persona. Ese recorrido muestra las expectativas que el diseño está generando sin que nadie las diga en voz alta.

La primera reacción de cualquier persona presente durante una prueba, cuando ve a alguien confundido, es intervenir: prueba tocando aquí, eso se activa así. Ese impulso, aunque bien intencionado, borra la información más valiosa de la prueba, que es justamente ver qué intenta la persona antes de que alguien la corrija.

Hemos entrenado al equipo para contar hasta diez, literalmente, antes de intervenir en una prueba. Ese silencio incómodo casi siempre revela algo que ninguna entrevista posterior hubiera sacado a la luz: la primera hipótesis de la persona sobre cómo funciona el objeto, correcta o no.

Cuando el prototipo se equivoca de forma útil

Algunos de los aprendizajes más importantes que hemos tenido vinieron de prototipos que fallaron de una forma que nadie anticipó. Un mecanismo que se atascaba de manera consistente terminó revelando una preferencia real: a la gente le gustaba la resistencia, el pequeño esfuerzo antes de que algo cediera.

Es tentador tratar cualquier falla como un error a corregir cuanto antes. Pero antes de corregirla vale la pena preguntarse si esa falla está comunicando algo sobre cómo la gente realmente quiere interactuar con el objeto, en lugar de cómo asumimos que querría hacerlo.

Esto exige cierta disciplina para no apurarse a arreglar todo de inmediato. Un prototipo que se rompe de una forma interesante merece, al menos, una sesión más de observación antes de pasar a la siguiente versión.

Guardar lo aprendido

Documentar una prueba implica registrar decisiones, contexto y preguntas nuevas, no únicamente imágenes del objeto. Una nota clara puede evitar repetir un error y abrir el siguiente experimento en vez de reiniciarlo desde cero.

Es fácil terminar una sesión de pruebas con una carpeta llena de fotos y videos y ningún registro de qué pregunta se intentaba responder ese día. Seis meses después, esas fotos son bonitas pero inútiles: nadie recuerda qué se estaba probando ni qué se concluyó.

Nuestra plantilla de notas empieza siempre con la pregunta original, no con la descripción del prototipo. Eso obliga a cerrar cada sesión respondiendo, aunque sea de forma parcial, la pregunta con la que empezamos, en vez de describir simplemente lo que el objeto hizo.

Cuando el prototipo convence demasiado bien

Existe un riesgo particular con los prototipos que se ven casi terminados: convencen a quien los observa de que el proyecto está más avanzado de lo que realmente está. Un acabado pulido genera confianza, incluso cuando esa confianza no está justificada por lo que realmente se ha probado o resuelto.

Hemos visto reuniones donde un prototipo visualmente impecable, que en realidad solo simulaba una función clave detrás de escena, generó aprobaciones y decisiones de inversión basadas en una capacidad que todavía no existía de verdad. Nadie mintió a propósito, pero la estética del objeto comunicó algo distinto a lo que el equipo técnico sabía que era cierto.

Por eso, cuando un prototipo está más pulido de lo que su funcionalidad real justifica, tratamos de decirlo explícitamente antes de que alguien lo vea, no después de que ya se haya formado una expectativa equivocada. Un prototipo honesto a veces necesita verse un poco peor de lo que podría verse, solo para no generar una promesa que la tecnología detrás todavía no puede cumplir.

Probar solo no sirve

Es tentador probar un prototipo uno mismo, repetidamente, ajustando pequeños detalles hasta que se sienta bien. El problema es que quien construyó el objeto ya sabe cómo usarlo, y esa familiaridad hace invisibles justo los problemas que una persona nueva encontraría de inmediato.

Un prototipo probado únicamente por su propio equipo de diseño tiende a parecer más terminado de lo que realmente está, porque las dificultades reales de aprendizaje ya fueron superadas por quienes lo construyeron mucho antes de que alguien externo lo toque. Esa ceguera no es un defecto de carácter, es una consecuencia casi inevitable de pasar semanas trabajando con el mismo objeto.

Insistimos en llevar cualquier prototipo, por incompleto que esté, frente a alguien ajeno al proyecto lo antes posible. Las primeras reacciones de una persona que nunca vio el objeto valen más que veinte iteraciones internas, porque revelan justo lo que el equipo ya no puede ver por sí mismo.

El prototipo como herramienta de negociación interna

No todos los prototipos existen para mostrarle algo a un cliente o a un usuario final. Algunos de los más útiles sirven para resolver un desacuerdo dentro del propio equipo, cuando dos personas defienden enfoques distintos y ninguna palabra logra convencer a la otra.

En esos casos, construir dos versiones pequeñas y comparables, una por cada enfoque en disputa, suele resolver la discusión más rápido que cualquier argumento verbal. El objeto hace visible una diferencia que la conversación abstracta no lograba comunicar, y a veces revela que ambas posiciones tenían razón en partes distintas del problema.

Este uso del prototipo rara vez se documenta o se muestra fuera del equipo, pero le atribuimos tanto valor como a los prototipos que sí llegan a manos de un usuario externo. Resolver un desacuerdo interno con evidencia construida, en vez de con la opinión de quien habla más fuerte en la reunión, mejora la calidad de las decisiones que después sí llegan al público.

Lo que aprendimos de un prototipo que nunca mostramos a nadie

Algunos prototipos se construyen, responden su pregunta, y se quedan completamente internos, sin que ningún cliente ni usuario externo llegue a verlos. Uno de esos objetos, pensado para explorar una forma de retroalimentación háptica que finalmente decidimos no usar, nos enseñó más sobre los límites de esa tecnología que cualquier ficha técnica de fabricante.

No incluir ese aprendizaje en ningún entregable formal no significa que haya sido tiempo perdido. Saber qué no funciona, y por qué, tiene el mismo valor práctico que saber qué sí funciona, aunque sea mucho más difícil de mostrar en un portafolio o justificar en una factura.

Nos parece importante decir esto porque la presión de mostrar resultados tangibles puede llevar a evitar este tipo de exploración interna, la que probablemente no va a convertirse en nada presentable. Esa exploración sigue siendo, para nosotros, una parte legítima y necesaria del trabajo, incluso cuando nadie más la vea nunca.

Cuando no hay tiempo para prototipar

No todos los proyectos tienen presupuesto o cronograma para una fase extensa de prototipado. A veces la decisión debe tomarse con la información disponible, sin el lujo de construir y probar antes de comprometerse con una dirección.

En esos casos tratamos de replicar la lógica del prototipado sin construir nada físico: identificar la pregunta más incierta del proyecto, y buscar la evidencia más barata y rápida posible para responderla, aunque sea una prueba de papel, una simulación en video, o simplemente una conversación estructurada con alguien que ya enfrentó un problema parecido.

No es un sustituto perfecto de la prueba física. Pero mantener la disciplina de identificar la incertidumbre principal, incluso sin tiempo para construir un objeto, evita que la falta de presupuesto se convierta en excusa para no cuestionar ninguna suposición antes de avanzar.

El prototipo que nunca se termina

Algunos de nuestros mejores objetos de aprendizaje nunca llegaron a convertirse en un producto terminado. Cumplieron su función completa respondiendo la pregunta para la que fueron construidos, y ahí se quedaron, guardados en un estante, sin necesidad de evolucionar hacia nada más.

Nos parece importante decir esto en voz alta porque hay una presión constante, dentro y fuera del estudio, a mostrar que todo prototipo avanza hacia un producto final. Un prototipo que responde su pregunta y termina ahí no es un proyecto fallido. Es, quizás, uno de los usos más eficientes posibles del tiempo de un equipo.

Medir el éxito de un prototipo por si se convirtió en producto terminado es, en el fondo, aplicarle una vara ajena a su propósito original. La pregunta correcta no es qué tan lejos llegó, sino qué tan bien respondió la incertidumbre para la que fue construido.

Una pregunta que vale la pena repetir

Después de suficientes proyectos, uno empieza a notar que la pregunta más útil de todo el proceso de prototipado no cambia mucho de un proyecto a otro: ¿qué necesitamos saber que todavía no sabemos, y cuál es la forma más barata de descubrirlo?

Repetir esa pregunta al inicio de cada nuevo prototipo, en vez de asumir que ya la sabemos responder por experiencia previa, sigue siendo la disciplina más simple y más difícil de mantener en el tiempo.

Cuando el equipo se enamora del prototipo

Después de suficiente tiempo trabajando en un prototipo, es normal que el equipo desarrolle cierto apego hacia él, casi como si fuera un pequeño logro personal. Ese apego, aunque comprensible, es uno de los sesgos más difíciles de manejar durante una prueba con usuarios reales.

Cuando alguien externo señala un problema serio en un objeto que el equipo construyó con esfuerzo durante semanas, la reacción natural es defenderlo, explicar por qué esa persona no lo entendió bien, o restarle importancia a la crítica. Esa reacción, aunque humana, es exactamente lo contrario de lo que una prueba de prototipo necesita para ser útil.

Hemos adoptado la práctica de asignar, en cada sesión de prueba, a alguien del equipo que no participó directamente en la construcción del objeto, específicamente para moderar la conversación con usuarios. Esa distancia ayuda a recibir la crítica sin la necesidad automática de defender el trabajo propio.

No elimina el apego por completo, ni debería hacerlo del todo: cierto nivel de orgullo por el trabajo hecho es sano y necesario. Pero mantenerlo bajo control durante el momento específico de escuchar retroalimentación marca la diferencia entre una prueba que genera aprendizaje real y una que solo confirma lo que el equipo ya quería creer.

Esta dinámica se vuelve más delicada cuando el cliente, no solo el equipo interno, también se ha encariñado con una dirección de diseño específica. En esos casos, nuestro papel incluye ayudar a todos los involucrados a separar el apego emocional hacia una idea de la evidencia real sobre si esa idea está funcionando.

Un prototipo también puede mentir

Así como un prototipo puede convencer de más, también puede fallar de forma engañosa, mostrando un problema que no sería real en el contexto de uso definitivo. Un mecanismo probado en una mesa de laboratorio, con luz e iluminación controladas, puede comportarse de forma completamente distinta en el ruido y el desorden de un espacio público real.

Hemos aprendido a desconfiar tanto de un prototipo que funciona sorprendentemente bien en condiciones ideales como de uno que falla de forma dramática en esas mismas condiciones controladas. Ambos resultados pueden estar midiendo el entorno de prueba, no el objeto que realmente nos interesa evaluar.

La única forma confiable de saber cuál de los dos casos estamos viviendo es acercar las condiciones de prueba, tanto como sea posible, a las condiciones reales de uso, aunque eso implique pruebas más costosas, más lentas y más difíciles de controlar que las que se hacen cómodamente dentro del estudio.

Esta lección nos ha costado más de un proyecto entregado con retraso, porque insistimos en probar en el contexto real en vez de conformarnos con resultados prometedores obtenidos en condiciones artificiales. Seguimos pensando que ese retraso vale la pena frente al riesgo de construir algo que solo funciona en un laboratorio.

Si algo comparten todas estas historias es que ninguna trata en realidad sobre construir objetos. Tratan sobre construir preguntas lo bastante honestas para que la respuesta, venga de donde venga, nos sirva de algo.