Cuando enseñaba en design studios, siempre pedía a mis estudiantes que trajeran maquetas bien hechas. Sin cinta adhesiva, sin bordes irregulares, sin materiales provisionales. Creía que eso era rigor. Años después, al descubrir el design thinking, entendí que era otra cosa: era una forma de evitar el error. Una cultura del perfeccionismo que, sin proponérselo, estaba paralizando exactamente lo que el proceso creativo más necesita.
Hay un momento en el proceso de diseño que desde entonces reconozco de manera diferente. Alguien está delante del papel — o de la maqueta — y no se mueve. No porque no tenga ideas. Sino porque ninguna de las que tiene le parece suficientemente buena para comprometerse con ella. El miedo al error no paraliza porque haya que esperar a tener la respuesta correcta. Paraliza porque hace imposible saber cuál sería la respuesta correcta sin haberla intentado.
La Carta 12 del mazo Arplaytecture propone una inversión: ¿Y si diseñaras para fallar? Analiza todas las decisiones y elementos que podrían hacer fracasar tu idea. Úsalos como punto de partida para generar ideas absurdas. Luego invierte esas ideas para encontrar soluciones inesperadas.
El error como material de trabajo: de la empatía a la ideación
La lógica es más precisa de lo que parece. De Bono lo llama provocación: no buscar la solución correcta, sino — como él mismo escribe — “una disposición diferente de la información que lleva a una perspectiva diferente de la situación.” La absurdidad no es el objetivo. Es el método. Y lo que produce no es caos, sino un tipo específico de claridad.
En la práctica, esto empieza por ponerse en el lugar del usuario — pero desde una perspectiva de fallo (por eso, a esta técnica también se la conoce como inverse brainstorm). No se pregunta “¿qué necesita este usuario?”, sino “¿qué lo frustraría? ¿Qué aspectos del diseño podrían causar confusión, incomodidad o rechazo?” Por ejemplo, si estás diseñando una biblioteca pública, la lista podría incluir: hacer que los libros estén desordenados, que la señalización sea confusa, que no haya suficiente luz. Esos fallos sirven para identificar lo que no debería ocurrir — y al invertirlos, abren posibilidades que desde la pregunta directa no habrías visto: ¿y si la señalización fuera interactiva y personalizada para cada usuario?
Cuando el proceso avanza hacia la definición, la inversión del fallo se convierte en pregunta: ¿cómo evitar que el usuario se sienta perdido? ¿Cómo crear una experiencia agradable incluso en los espacios más oscuros? ¿Cómo transformar el acto de buscar un libro en un juego? Esas preguntas pueden redefinir el problema y orientar el trabajo hacia lo que realmente importa.
En la ideación es donde la absurdidad se vuelve productiva. Imagina que identificaste que “no encontrar el libro frustraría al usuario”. ¿Y si diseñaras estanterías que se mueven para esconder los libros? Aunque parezca ridículo, esa imagen puede llevar a estanterías móviles que se reconfiguran automáticamente para optimizar el espacio — o a una app que guía al usuario hacia el libro con una experiencia de videojuego. Diseñar para fallar te obliga a señalar exactamente lo que no funciona, y eso te orienta hacia lo que sí podría funcionar.
Prototipar desde el fallo: aprender sin miedo a equivocarse
En las fases de prototipado y testeo, el fallo deja de ser una amenaza y se convierte en material tangible. Aquí el rigor no está en la perfección de la maqueta — sino en la velocidad y en la disposición a aprender. Los prototipos de baja fidelidad, inacabados y aproximativos, dan permiso para que los usuarios interactúen de formas no previstas, precisamente porque no hay nada que “romper”. Una maqueta de cartón de las estanterías móviles, un storyboard que simula la experiencia de la app: el objetivo no es presentar una solución acabada sino capturar la esencia del fallo y ver qué revela. Scott Witthoft lo formula así:
“Fail well by making sense of early outcomes, asking What did I learn and how did I learn it? What you learned relates to the work you’re doing — your questions, your objectives, and your discoveries.”
El testeo refuerza esto: cuando presentas algo imperfecto, los usuarios tienen permiso para criticar y comprometerse con lo que ven de una manera que un diseño pulido no permite. Como señala Tim Brown: “The point is to put something out into the world and then use it to keep learning, keep asking, and keep testing.” Las reacciones más inesperadas son las que más información dan. Y eso es el tipo de dato que la maqueta perfecta, la que nadie quiere tocar por miedo a estropearla, nunca produciría.
La lente del Experimentador: iterar rápido, aprender pronto
Quien trabaja con la lente del Experimentador — uno de los innovation roles del mazo Arplaytecture — hace de esto un método: iteración rápida, prototipos de baja resolución, y la disposición a buscar el fallo de forma activa antes de que el proyecto esté demasiado avanzado para girar. No se trata de no tener criterio. Se trata de aprender a generar criterio a través de la experiencia, no a pesar del error sino gracias a él.
Hay un caso en arquitectura que ilustra bien este mecanismo, aunque no se planificó como tal. Cuando Jørn Utzon estaba desarrollando las cubiertas de la Ópera de Sídney, el sistema estructural original era geométricamente imposible de construir — cada panel tenía una curvatura diferente y el coste y la complejidad eran inasumibles. Lo que parecía un fracaso de proyecto llevó a Utzon a una solución que nadie había considerado: cortar todas las superficies a partir de una única esfera. El resultado fue más elegante, más eficiente y más coherente que el diseño original. El error forzó la pregunta que el proceso correcto nunca habría formulado.
La diferencia entre el fallo que destruye y el fallo que enseña no está en el fallo. Está en la pregunta que le haces después.
