Vuelta a los prototipos: el desafío del malvavisco (post-184)
Anna Cabañas me ha recomendado hoy vía Twitter un vídeo genial, que me sirve para seguir dando la vara con los beneficios de desarrollar una cultura de prototipos para innovar.
De esto ya hablé bastante en este post, y conecta con el Design Thinking (Pensamiento de Diseño), una temática que tratamos mucho en esta casa.
Esta charla de Tom Wujec en TED, fue reseñada originalmente por Carles Caño en una entrada de su blog presentArte, así que a él le debemos sobre todo poder recomendarla aquí.
El vídeo explica cómo con un sencillo ejercicio de prototipado (“el desafío del malvavisco“) pueden revelarse múltiples dimensiones de la naturaleza de la colaboración. Me quedo fundalmentalmente con estas ideas:
- Perdemos demasiado tiempo al principio, cuando nos piden una tarea, intentando “encontrar el único plan correcto” que después ni siquiera cumplimos = el ponente certifica que eso pasa mucho con los graduados de las escuelas de negocio 🙂
- Los niños no hacen eso (y por eso superan mejor la prueba), se ponen rápido manos a la obra, construyen prototipos sucesivos, iterativos, y de cada uno “reciben observaciones instantaneas de lo que funciona y lo que no”, al más fiel estilo de learning-by-doing.
- El prototipado es una experiencia compartida y de lenguaje común que ayuda a desarrollar habilidades de colaboración.
- El diseño (o diría mejor, el pensamiento de diseño) “es un deporte de contacto”, de manosear la arcilla y trabajar con las manos, para aprender juntos.
- El rendimiento de los equipos mejora con: 1) Habilidades especializadas (por eso los arquitectos e ingenieros consiguen tan buenos resultados en esta prueba), 2) La participación de “facilitadores” que dirigen/entienden el proceso y mejoran el rendimiento colaborativo de sus miembros.
Pues nada, es un video que vale la pena ver, se pasa rapidísimo (con subtitulado en castellano gracias a TED), y si eres consultor o facilitador de procesos participativos, seguro que te sugiere un montón de cosas para hacer:
La duda que siempre me queda cuando defiendo este punto de vista, es el de los costes que implica el método de “ensayo y error”.
Es un viejo debate entre “reflexivos” y “practicantes” que gracias a las herramientas digitales se decanta progresivamente a favor de los segundos. Ahora los prototipos son cada vez más baratos, y eso invita a probar, a experimentar, mientras se piensa y se aprende (no olvides esto: “build to think”)
Si te apetece ya me cuentas aquí qué te ha parecido el video, y si has hecho ejercicios parecidos de “prototipado colaborativo” de los que podamos aprender, me encantará que los compartas con nosotros en este espacio.
Deja una respuesta
Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.
15 Comments
Quizás también te interese
Alejandra
Hurrah! In the end I got a website from where I know how to really get helpful facts regarding my study and knowledge.
JT
Me gusta el desafío, me lo anoto por si tengo oportunidad de ensayarlo algún día.
Respecto de lo que dices del coste, no es tema baladí. En arquitectura no se hacen muchos prototipos (aunque sí muchos modelos, como decía más arriba) casi siempre por razones de presupuesto. Dado que un prototipo ha de ser fiel en sus propiedades al producto prototipado, supone una inversión similar o mayor.
Ej. Si quiero estudiar las características de un muro de hormigón que estoy diseñando, tendría que hacer varias muestras de ese muro, a escala real y con todas sus propiedades y dimensiones, y no siempre el presupuesto de la obra da para ello.
Si se ve el prototipo como algo elaborado y representativo como se ha visto hasta ahora (como comentabas en tu anterior post), el coste siempre es elevado.
Pero si hablamos de prototipos de trabajo, estos pueden ser parciales (estudian sólo un aspecto o dos del diseño y por tanto son más rápidos) y de baja calidad material (saliendo por tanto más baratos).
Ej. En el caso del muro de hormigón, puedo obviar sus capacidades resistentes y centrarme en probar las texturas del acabado, para lo cual con un espesor de unos centímetros de hormigón, me vale… y ahorro bastante. O puedo hacer una muestra dde la mezcla y ensayarla mecánicamente para ver su resistencia real, de hecho.
Vamos, que el método de ensayo y error mediante prototipos se hace más asequible si fallas de forma “pronta, rápida y parcial” en el proceso de diseño.
Y se hace aún más asequible si los resultados son replicables, para que el coste del prototipo se distribuya entre cada una de las réplicas.
Ej. No es lo mismo hacer un prototipo de 5m del muro si luego pienso hacer 10000 m de muro iguales en todas mis obras, que si van a ser sólo 10m y en esa única obra.
Supongo que de ahí viene que los prototipos se usen mucho en automovilismo (diseñas un coche, y sacas tropecientosmil iguales) y poco o nada en arquitectura (donde cada edificio es distinto).
Y es una lástima, intuyo que hacer prototipos (espaciales/ambientales, por ejemplo) de futuros edificios podría ser una pasada.
Jaume Armengol del Pliego
No te falta razón pero quizás depende también del escenario. Hay proyectos con timings muy ajustados y entornos donde la big picture la sueles tener más clara tú que el propio cliente que necesita aún un recorrido en la comprensión del canal que no tienes tiempo de asumir en ese proyecto (tiempo para cumplir con fechas claro).
Mi estrategia en esos escenarios es un poco como el método stanislavsky (ponerte en el lugar del otro de forma completa), pero con el know-how y mis propias características profesionales. De este modo, a menudo se consigue un punto de partida lo suficientemente consistente como para que las alteraciones evolutivas pivoten sobre unas ideas fuerza fáciles identificar de inicio.
Me creerás si te digo que hay clientes que se extrañan de que les haga según que preguntas que no tienen relación aparente con el proyecto (como si un actor se preguntase sobre su hipotética relación con sus padres que no aparecen en el libreto o guión). Cuando el proyecto acaba suelen comprender porqué les preguntaste aquello.
Desde luego un proyecto de comunicación sin involucrar al cliente está condenado al fracaso, no por el resultado en sí que puede ser cojonudo, pero si el cliente no lo hace suyo, estará vació: el cliente es quien lo llena.
Supongo que la diferencia está también en que imagino que a ti te llaman sobretodo para que les ayudes a innovar (a pensar) y a mi me llaman sobretodo para que les ayude a comunicar (a hacer). Aunque a veces se mezclen las cosas me parece que tu negocio está más en hacer de facilitador (de herramienta) y el mío en dar las cosas hechas (adaptadas pero hechas).
En mi caso las características del proyecto (su alcance y restricciones), así como el perfil del cliente marcan la metodología. Eso sí, te aseguro que no se programa una línea de código hasta que el prototipado definitivo está aprobado.
Pd. Abundando te diré que yo prefiero trabajar las arquitecturas de información sobre árboles de contenido, pues es más sencillo para todos discutir su organización. Sin embargo, mi experiencia me dice que hasta que el cliente no ve una distribución en pantalla (prototipo) no se imagina realmente como será la experiencia de usuario… y ahí viene un detalle delicado y es que la usabilidad y las buenas experiencias de usuario se construyen en base a aspectos más o menos técnicos que el cliente no suele conocer… por lo que desgraciadamente adapto el prototipado a su visión, pero quien dice cuando se cae el malvavisco (cuando no funciona como solución) soy yo;-)
Pd2. Afortunadamente la visión de los clientes cuando se manchan de harina (se involucran en el proceso de definición) es muy enriquecedora y aportan soluciones e ideas creativas a las que no hubiera llegado fijo en el timing del proyecto :-D. Cuando se da suenan violines, que a veces solo oigo yo…
Alberto Blanco
Sin duda los procesos iterativos facilitan enormemente el aprendizaje, permitiendo centrarse no sólo en el producto sino en el propio proceso. Fantástico post.
Amalio
Alberto:
Pues eso, lo “iterativo” es aprendizaje vivo, y parte de reconocer que el error es algo natural en la busqueda de la mejor solución posible.
Gracias…
Jaume Armengol del Pliego
Hola familia,
Yo que utilizo SIEMPRE el prototipado en proyectos web discrepo en parte con ese mensaje del ensayo y error como la mejor técnica para sacar adelante los proyectos en los que se involucra creatividad e innovación.
Creo que la capacidad de análisis de los objetivos del cliente, sus necesidades (no siempre coincidentes), el contexto y las posibilidades técnicas [y de costes :-(] ofrecen un marco de trabajo lo suficientemente refinado como para empezar el proyecto con una idea bastante clara de por dónde deben ir los tiros y cuál será el itinerario que tendrá el proyecto.
El ejemplo del Malvavisco o el del Alberto B. obvia algo fundamental si lo aplicáramos a un proyecto en Internet (mi campo): en ambos se parte casi de cero; no tenemos experiencia previa ni formación específica. No tenemos expertise (por lo menos yo) montando estructuras con palillos o espagueti. Fijaos en la analogía con los niños, y porqué ellos no se paran a reflexionar, no tienen background alguno (no llevan libros en la mochila ;-).
Mis clientes me escogen no tanto por mi creatividad (que también, o al menos eso quiero creer) y mucho menos por mi método; sino por qué sé hacer lo que ellos me piden. Obviamente existe una fase de aproximación evolutiva desde la conceptualización hasta el diseño de experiencia de usuario y Arquitectura de Información definitivos en los que es preciso involucrarles. Ahí es cuando entran los prototipos, básicamente porque el cliente es capaz de visualizar mucho mejor el resultado si puede “tocar” un esquema de éste y conseguir depurar mucho mejor la idea final de cómo debe especificarse el desarrollo del proyecto.
Otro tema sería si nos centrásemos exclusivamente en la creatividad neta, no tanto en el desarrollo de proyectos con componentes creativas. Ahí lo veo más claro, porque para crear debe fluir el momentum, y el momentum fluye haciendo no pensando. En esas me vienen a la cabeza las imágenes en B/N de Picasso con las manos en la arcilla, decorando botijos, haciendo… haciendo cosas que le llevaban a otras, descubriendo rutas originales por el simple hecho de caminar sin rumbo.
Pd. Por supuesto un escenario como el que plantea el ponente en sus propios proyectos con clientes el proceso iterativo tiene muchísimo sentido. No en vano tiene que involucrar muy activamente en el proceso creativo a equipos de trabajo heterogéneos y en ese contexto con tanta variedad de experiencias, conocimientos, motivaciones, etc. procesos iterativos que ajustan y adaptan a los equipos parecen ideales.
Seguimos en la brecha. Feliz verano, Jaume.
http://twitter.com/besmarthinkfree
Amalio
Jaume:
Aportas una reflexión interesante. Nosotros en emotools también trabajamos mucho con el “prototipado-web”, porque hacemos de arquitectos de información en el diseño funcional de web complejas que tratan sobre innovación. Es un trabajo que hacemos cada vez más.
Según nuestra experiencia, ese “marco de trabajo lo suficientemente refinado para empezar el proyecto” que dices conseguir al iniciar un proyecto-web está lejos todavía de ser “bastante claro”. Son solo suposiciones que nos hacemos los proveedores de lo que quiere/necesita el cliente.
Incluso sabiendo hacer las mejores preguntas para definir bien las especificaciones, te das cuenta que tu forma de conducir la conversación es bastante sesgada. Incluso cuando sabes escuchar, el cliente puede estar equivocado en lo que te cuenta o se imagina que “necesita”. Del “itinerario” ya ni te digo, está lleno de incertidumbres en la mayoría de los proyectos.
Tienes razón, no es el caso del Malvavisco, donde partimos de cero. Eso es cierto. Así que más vale que pienses primero, que eches mano de tu experiencia antes de ponerte a probar, como he comentado antes a Alberto.
Por eso me gustaría aclarar que no defiendo la idea de ponerse a programar como un loco antes de pensar primero lo que hay que hacer. Es importante la reflexión previa.
Pero lo que digo es que “pensamos demasiado” antes de ponernos manos a la obra. Mi hipótesis es que conviene adelantar el momento en el que te pones a probar los materiales, a montarlos, a probar opciones, a dibujar posibles interacciones-web.
Otra idea importante = eso que llamas “aproximación evolutiva” puede y debe hacerse con ayuda proactiva del cliente. Por eso los prototipos pueden entrar casi desde el principio, y es bueno que así sea, porque le ayudas a que piense contigo. El mensaje es anticipar lo más posible esa fase, desarrollando pronto lo que los expertos en DT llaman “Quick & Dirty prototypes”.
Este es un debate que he tenido con muchos informáticos en mis charlas, y se reduce a estas dos posturas: 1) Informáticos: prefieren presentar el prototipo (v. Alpha o Beta) cuando el proyecto está al 60%, 2) Amalio: les propongo presentar al cliente un “prototipo-rápido-y-sucio” cuando el proyecto está solo al 20%.
Si lo presentas al 60%, tu concepción del prototipo es “build to communicate”, mientras que si lo presentas al 20%, tu lógica con el cliente es totalmente distinta: “build to think”.
En el primer caso, usas el prototipo para contar lo que ya tú has pensado, mientras que en el segundo, presentas un “modelo abierto” que invita al cliente a pensar contigo. Y como me conozco esto del diseño-web, lo bueno que tiene esto es que las ideas que te propone el cliente cuando el proyecto está al 20% son mucho más asumibles por el informático, que si le vas con un “prototipo tardío” que ha incorporado ya el 60% de la carga de trabajo prevista.
Por cierto, eso que llamo “prototipo” en diseño-web, es una simple materialización de la “cultura del boceto”. Un prototipo al 10-20% es eso, un boceto muy elemental que busca provocar al cliente para que te ayude a pensar, y que incluso le comprometa con el resultado.
Puff, me he larga’o una respuesta tan extensa que es un post en sí misma, pero bueno, creo que el tema lo merece, y que la conversación está para eso.
Un abrazo!!!
Alberto Barbero
Hola de nuevo, Amalio:
No podré tener video al menos hasta noviembre, cuando tengo previsto hacer de nuevo el ejercicio… aunque no sé, me están entrando tentaciones de hacer el del malvavisco. Sin embargo dispongo de algunas fotos y de las instrucciones completas. Si te interesa en algún momento, ya sabes…
Sigo sin ver la primera cuestión. Hasta ahora yo siempre he entendido la innovación como resultado de un proceso ordenado en cuatro fases muy clásicas (casi me da verguenza mencionarlas): identificación de objetivo, generación de ideas, selección y plan de acción o gestión del cambio. Siempre he pensado -y así he entendido la teoría de los sombreros de Bono- que cuando el cerebro está en fase creativa/ generativa lo hace por asociación/ imaginación, de tal modo que si irrumpimos en esta fase con críticas producimos un funcionamiento pobre del cerebro en la búsqueda de ideas y dificultamos que una idea imposible se convierta en una idea aplicable por asociación. Si ésto es así -que no sé cómo lo verás-: ¿no deberíamos dejar las observaciones sobre lo que no funciona para más adelante?
Amalio
Alberto:
Vaya, hazte el del malvavisco y nos cuentas qué tal.
En cuanto a la pregunta que planteas, te diré mi opinión que es, obviamente, una más.
La “generación de ideas” es necesaria, y los prototipos no la empobrecen, sino todo lo contrario. OJO, el primer paso NO es en muchos casos ponerse a hacer el prototipo, porque es posible que valga la pena primero “pensar”, imaginar opciones, etc, etc. Pero lo que este experimento defiende es que llegado a un punto, es mucho mejor pasar rápido a la acción, “manosear” las posibles soluciones. Si hay un equipo, cada miembro puede construir su propio prototipo, su propio “modelo de solución”, y entonces despues se va a la fase de “prototipado colaborativo” o busqueda de convergencia entre las distintas soluciones.
Lo que aporta de nuevo el prototipo es: 1) un feedback más directo y palpable, 2) una evidencia visible de las restricciones (de materiales, de tiempo, de habilidades, etc.) que hay que superar, 3) un escenario honesto donde no cabe la berborrea porque tienes que demostrar que lo que tu propones, funciona… o tiene visos de funcionar.
Este hilo de reflexión que abres pone en evidencia las grandes diferencias que existen entre “creatividad” e “innovación”. La creatividad admite practicamente de todo, es loca, caótica, incontrolada. Pero la innovación exige una correcta gestión de las restricciones, porque va de convertir una idea en algo usable/vendible, y yo pienso que los prototipos ayudan a entender mucho mejor el problema y a ser más honestos en la búsqueda de las soluciones.
Por otra parte, Alberto, no dividiría el proceso de innovación en fases, como propones. No es algo tan lineal. Está todo mezclado, y por eso me gusta tanto la idea del Design Thinking que concibe la innovación como un proceso “iterativo”, en el que propones-fallas-mejoras-pruebas… y asi hasta encontrar la mejor solución.
En resumen, la diferencia está en que pasamos lo más pronto que podemos del discurso imaginario o verbal a construir “artefactos” (objetos, bocetos en servilletas o videos, si lo prefieres) que ayuden a pensar.
un abrazo!!
Alberto Barbero
Hola, Amalio:
Gracias por el video a Anna, a sus propias fuentes y, especialmente, a tí.
Yo suelo usar un ejercicio muy parecido que consiste en construir una carrocería para un huevo. En este caso los materiales son 20 pajitas, 2 huevos (uno para ensayar) y un rollo de cello. Cada grupo ha de poner un nombre al proyecto y decir la altura desde la que se dejará caer al huevo sin que se rompa. Los proyectos se valoran, en este orden, en función de:
1. Que se rompa o no.
2. La altura desde la que se lanza.
3. El número de pajitas utilizadas (cuantas menos, mejor).
La dinámica que tiene lugar es muy parecida y los resultados también.
Con las conclusiones tengo dos dudas:
1. Las observaciones instantáneas sobre lo que no funciona, ¿no pueden inhibir el despliegue de la creatividad? Si yo estoy en “fase generativa” y me estoy encontrando con un repetitivo “esto no funciona”, ¿no se cortocircuita mi creatividad?
2. Muchas veces las “habilidades especializadas” paradigmatizan y dificultan la visibilidad de los océanos azules. De hecho, en el ejercicio, los niños sacan bastante buenos resultados…
Saludos!!!
Amalio
Alberto:
Gracias a tí por hacerme la visita.
Vaya, ese ejercicio del huevo no lo conocía. A ver si te grabas un video y lo compartes. Será más fácil verlo.
En cuanto a las dudas que comentas:
1) ¿Por qué las “observaciones instantaneas de lo que no funciona” van a inhibir la creatividad? Si no funciona, no funciona, entonces de lo que se trata es de que seas mas creativo aún “rizando el rizo”, buscando otras soluciones. OJO: Eso es así si el prototipo esta bien hecho, es decir, si “simula” bien la realidad que quieres resolver. Porque si el prototipo es incorrecto, es falso, entonces lo que parece “no funcionar” en él, no aporta realismo porque las premisas son equivocadas.
Que no hagamos eso puede generar algo peor: “la milonga”, el montarse un peliculón de algo que queda guay pero que no sirve para nada…
Vale, eso es “creatividad”, pero no es “innovación”, y yo en este post hablo de usar los prototipos para INNOVAR.
2) Tu apunte sobre las “habilidades especializadas” tiene mucho sentido. Yo también me lo preguntaba cuando escuché al ponente. Pero es que influye mucho el tipo de problema. En el experimento del malvavisco, si te fijas, había que construir estructuras de cierta altura, y ahí una persona que tiene formación en física, arquitectura, estructuras de ingenieria, juega a favor, y además puede aplicarlas rápido, las tiene muy asimiladas. Lo que quiero decir es que en ese ejercicio, para quien no tuviera “conocimientos especializados”, era mejor “jugar rapidamente” con el prototipo, confiar en la creatividad-por-contacto.
De todos modos, estoy de acuerdo contigo en poner en cuarentena al conocimiento-experto, o como minimo, mezclarlo con “ideas frescas” de outsiders.
un abrazo!!
JT
Esto se sale un poco del tema del post, pero lo del prototipo “falso, incorrecto, no realista” es un punto interesante a recalcar.
Se supone que un prototipo trata de replicar/anticipar fielmente algún aspecto del diseño. Si no es así, es un modelo.
En arquitectura hemos trabajado siempre con modelos, ya sean analítico-numéricos, físicos (a escala), informatizados, etc. Pero prototipos propiamente dichos, no se suelen hacer.
Funcionan de forma distinta. Por ejemplo, una maqueta (modelo) podría darnos una idea de cómo es la geometría que estábamos imaginando y de su comportamiendo aproximado (y por tanto sirve para pensar), pero si los del grupo de al lado están prototipando a escala real, con cargas y dimensiones reales, es más probable que encuentren antes algún acierto probado (sirven además para evaluar).
Yuri
Ey man me parecio buenazo el aporte, en el Ted lo bueno es que cuelgan videos que hacen pensar mucho y reflexionar,un punto importantisimo en el disño es esté el temor a el error, el querer que salga bien a la primera, al parecer debe quedar claro que es un proceso iterativo.
Amalio
Hola, Yuri:
El TED es de las iniciativas más impresionantes que conozco desde el punto de vista de compartir conocimiento. Aparte de que los ponentes son extraordinarios, de muchísimo nivel, la opción del subtitulado (cuando afortunadamente lo tiene, gracias a esos estupendos voluntarios que colaboran) multiplica las posibilidades de que eso conocimiento llegue a gente que no maneja otros idiomas.
Ese mantra perfeccionista de “hazlo bien a la primera” es la mejor prueba de lo equivocados que estamos al extrapolar la cultura de la calidad industrial a otros ámbitos de los servicios o de la gestión.
un saludo!!