Prototipar: Hazte más inteligente, más rápido

Un día a principios de la década de 1980, el científico informático Danny Hillis estaba almorzando con el físico ganador del premio Nobel Richard Feynman. Hillis mencionó que iba a crear un startup, con el objetivo de construir una computadora paralela que tuviera un millón de procesadores. Al estilo típico de Feynman, el físico respondió que era “positivamente la idea más tonta que he escuchado”. Pero estaba intrigado y al final del almuerzo había aceptado pasar el verano trabajando en la empresa.
Durante los primeros meses en el trabajo, Feynman trabajó en los circuitos del enrutador. Estos permitirían a los procesadores comunicarse y eran mucho más complejos que los propios procesadores. Los enrutadores, encargados de transportar información de un punto a otro, tenían que encontrar un camino libre a través de un atasco de tráfico de 20 dimensiones entre los procesadores o mantener el mensaje en un búfer hasta que el camino estuviera despejado. Una cuestión fundamental era si el diseño había permitido suficiente almacenamiento en búfer para funcionar de manera eficiente.
Feynman comenzó a estudiar los diagramas de circuitos y estaba dispuesto a escuchar explicaciones de por qué funcionaban las cosas. Pero prefería usar lápiz y papel para simular la acción de cada circuito y descubrir las cosas por sí mismo.
El trabajo de Feynman con los enrutadores ayudó al equipo a descubrir el potencial de la computadora, a la que llamaron la Máquina Conexión, para la computación numérica compleja y la simulación física. Esto fue útil para modelar cosas como el comportamiento de los fluidos y la simulación de vida artificial, programas que otras computadoras de esa época no estaban diseñadas para realizar de manera eficiente.
El equipo había asumido inicialmente que su máquina no sería capaz de realizar este tipo de cálculos numéricos, pero Feynman argumentó que valía la pena cuestionar la suposición.
Para resolver la discusión y averiguar qué tan bien funcionarían estos cálculos en la práctica, Feynman tuvo que crear un programa prototipo para ejecutarlo. Solo estaba realmente familiarizado con el lenguaje de programación Basic que se ejecutaría en los procesadores paralelos. Escribiría el programa y luego lo simularía a mano para estimar qué tan rápido la Máquina Conexión podría ejecutarlo.
Feynman trató estos desafíos como un juego, comenzando con preguntas muy básicas como, “¿Cuál es el ejemplo más simple?”. Luego continuaría haciendo preguntas hasta que hubiera reducido el problema a algo que pensaba que podía resolver, lo que atacaría con lápiz y papel.
Las contribuciones de Feynman finalmente ayudaron a la empresa a convertirse en líder en computación paralela, generando decenas de millones de dólares en ingresos.

Cuando Hillis recuerda su trabajo con Feynman, se dio cuenta de que en casi todo en lo que colaboraban eran aficionados. Desde las redes neuronales hasta la computación paralela, no sabían lo que estaban haciendo, pero estas cosas eran tan nuevas que nadie más las sabía.
Al descomponer problemas complejos en problemas simples y usar prototipos para responder preguntas críticas, pudieron impulsar la innovación que incluso ellos mismos no sabían que era posible.

Aunque Richard Feynman era físico y no diseñador de productos, entendió intuitivamente el poder de la creación de prototipos. La creación de prototipos nos ayuda a aprender, resolver desacuerdos y probar ideas de forma rápida y económica. Feynman comenzó el proceso de diseño con bocetos, que lo ayudaron a comprender el problema e identificar las preguntas críticas que el prototipo necesitaba responder.
La construcción de un prototipo le dio a Feynman la oportunidad de resolver la discusión que presentó sobre la capacidad de la Máquina Conexión para resolver cálculos complejos. Sin él, él y sus colegas podrían haberse sentado frente a una pizarra, lanzándose ecuaciones sin cesar y citando trabajos de investigación.
Finalmente, en lugar de tomarse el tiempo para aprender a sí mismo un lenguaje más complejo, utilizó herramientas familiares para construir rápidamente un programa que simulara la eficiencia de la máquina. Si hubiera fallado en este punto, solo habría costado días o semanas en lugar de meses.
Enmarcado de esta manera, queda claro por qué las organizaciones impulsadas por el diseño hacen prototipos temprano y, a menudo, durante todo el proceso de diseño, para crear mejores productos. En el resto de este artículo, veremos un caso de estudio en el que Uber realizó un prototipo para construir mejores productos para uso multilingüe, y analizaremos algunas técnicas que pueden ayudarte y a tu equipo a inculcar un sesgo hacia la creación de prototipos desde el inicio del proceso de diseño del producto.

Uber, el servicio de viajes compartidos cada vez más omnipresente, cuenta con estadísticas impresionantes. En el momento de redactar este artículo, más de un millón de conductores de Uber, o “socios conductores”, como Uber prefiere llamarlos, habían brindado más de 2 mil millones de viajes a más de 8 millones de usuarios. Independientemente del destino al que viaje, es probable que encuentres un conductor de Uber; están presentes en más de 400 ciudades en 70 países.
Diseñar la aplicación de Uber para que funcione sin problemas para los conductores y pasajeros en esta multitud de países generó un conjunto único de desafíos. Hay diferencias en el idioma, por supuesto, así como en la simbología y las velocidades de acceso inalámbrico. Todas estas variables debían tenerse en cuenta cuando Uber trabajó en un rediseño desde cero de su aplicación de conductor en 2015.
El equipo comenzó con prototipos ligeros de la aplicación en inglés, utilizando Sketch e InVision. A medida que trabajaban en estos flujos, el equipo también tenía que tener en cuenta su audiencia global, por lo que volverían a los archivos de Sketch y actualizarían los idiomas para reflejar las versiones hindi o china de los prototipos de InVision.
Con los prototipos en la mano, el equipo podía probar con los usuarios de cada país y comenzar a responder preguntas críticas sobre dónde la aplicación podría ser confusa o no ofrecer una excelente experiencia de usuario para los conductores. Comenzaron con la estructura de navegación. ¿Cuáles eran las funciones importantes para los conductores y cómo deberían organizar el contenido de la aplicación? En la fase de evaluación, preguntaron si términos como “ganancias” y “calificaciones” se traducirían adecuadamente a los otros idiomas.
En el camino, hicieron algunos descubrimientos interesantes. Por ejemplo, uno de los íconos de Ingresos era un gráfico de barras, que representaba cómo se vía la pantalla de Ingresos cuando lo tocaba.
Sin embargo, cuando probaron el prototipo en India, los conductores pensaron que el icono los llevaría a la configuración de red. La alta latencia y las velocidades lentas mantuvieron la red en primer plano para los conductores indios, y el ícono de Ingresos se parecía mucho a los íconos comunes de intensidad de señal que puedes ver en la barra de estado de un teléfono inteligente.
Este descubrimiento permitió a los diseñadores de Uber alterar el rumbo y crear un ícono más representativo del efectivo, lo que resolvió el problema antes de que tuviera la oportunidad de aparecer en un producto real.

Otro descubrimiento, también relacionado con las redes de baja fidelidad, fue el escenario en el que un conductor comenzaba su turno y se conectaba a Internet para comenzar a aceptar viajes. En este punto, el equipo había pasado de prototipos de baja fidelidad, a prototipos animados e interactivos de mayor fidelidad, a construcciones funcionales tempranas.
En estas compilaciones iniciales, el conductor no recibió comentarios después de tocar el botón para conectarse, solo un retraso mientras la aplicación llamaba al servidor para verificar que el conductor podía aceptar viajes en su área actual. Para el conductor, la aplicación parecía congelada.
En este caso, agregar una transición animada, que normalmente podría considerarse un “pulido” no crítico de la aplicación, fue fundamental para su función. La animación resolvió este problema y mejoró la experiencia del usuario para los conductores.
Una cosa importante que hizo el equipo de Uber durante todo el proceso de diseño fue hacer coincidir la fidelidad de sus prototipos con las preguntas que tenían que responder. Al principio del proceso, se utilizaron prototipos de baja fidelidad para comprender mejor cómo se traducía el producto a otros idiomas. A medida que la dirección del producto se solidificó, los prototipos funcionales de mayor resolución resolvieron algunos de los posibles obstáculos en la experiencia del usuario.

Como diseñador, es casi seguro que hayas construido prototipos de un producto antes de lanzarlo, pero es posible que estés buscando formas de insertar prototipos en una etapa anterior de tu proceso. Al considerar la fidelidad de un prototipo, siempre es importante considerar el tipo de preguntas que estás tratando de responder y ser cauteloso al interpretar los resultados de probar prototipos de muy baja fidelidad con los usuarios.
Dicho esto, si estás trabajando en el flujo de una nueva función o tratando de comunicar ideas a los miembros del equipo, los bocetos y los prototipos de papel son formas completamente válidas de avanzar. Aquí, describiremos una serie de técnicas e ideas para mover prototipos al comienzo de tu proceso de diseño. Algunos también se pueden encontrar en Stanford d.school Bootcamp Bootleg.
Prototipo de tiempo cerrado
Crea un prototipo de baja resolución de una función que te gustaría probar con tu equipo, antes de invertir tiempo en crear una versión de mayor fidelidad para probar con los usuarios.
Ponte a prueba para trabajar rápido. Reserva una hora y crea 2-3 variaciones del prototipo. Las pantallas se pueden dibujar a mano, captúralas en un teléfono inteligente y llévalas a InVision para que sean interactivas. Como alternativa, puedes utilizar la aplicación Prototype on Paper (POP).
Prototipo para decidir
Arregla una discusión entre tu equipo sobre qué dirección tomar para un producto o característica.
Al igual que Richard Feynman y Danny Hillis, tu equipo puede tener diferentes puntos de vista sobre la dirección que puede tomar un producto. Para tomar una decisión, crea prototipos de las soluciones de la competencia.
Si tus usuarios van a juzgar, intenta llegar a un nivel de fidelidad que provoque una reacción genuina y observable de ellos, pero no pierdas más tiempo del necesario. Extrae el problema tanto como sea posible y aísla la variable que estás probando.
Prototipo del Mago de Oz
Crea un prototipo más rápido utilizando humanos en el bank-end para ahorrar tiempo y recursos.
El servicio de transmisión de música Pandora tiene una capacidad casi mágica para crear listas de reproducción de las canciones que te gustan, simplemente calificando una pista o dos con un pulgar hacia arriba o hacia abajo. A la compañía le gusta dar crédito a su Proyecto de Genoma Musical, que intenta categorizar toda la música por atributos (tempo, voz, etc.) y luego clasificarlos usando un algoritmo complejo.
Sin embargo, desde el principio, la empresa se dio cuenta de que necesitaba un toque humano para hacer que las listas de reproducción resonaran en los oídos humanos. Al igual que el Mago de Oz, hay un humano detrás de la cortina, categorizando y describiendo cada canción como parte del “algoritmo”.
La creación de prototipos de Mago de Oz te permite aprender mucho sobre cómo se comunican tus usuarios antes del compromiso de escribir cualquier código de back-end.
Prototipo para enseñar
En 1986, 7 astronautas perdieron la vida cuando el transbordador espacial Challenger se despedazó a los 73 segundos de su vuelo. A raíz de esta estrategia, Richard Feynman participó en una audiencia del Congreso investigando la causa del desastre.
En lo que se ha convertido en una anécdota famosa, se sentó frente al panel del Congreso y demostró lo que sucedió con las juntas tóricas del transbordador en la temperatura del día de lanzamiento más fría de lo normal. Usando un vaso de agua y colocando una junta tórica fijada en el vidrio, mostró cómo las juntas tóricas se vuelven frágiles e inflexibles cuando se exponen al frío.
Compara esta simple demostración con los complejos gráficos producidos por los ingenieros en un intento de advertir sobre los peligros de la exposición de la junta tórica a temperaturas frías.
Imagen Junta Tórica

Una vez más, la capacidad de Feynman para resumir un problema hasta su esencia y crear un prototipo que probara su hipótesis fue fundamental para su capacidad de compartir este experimento. Hacemos prototipos para aprender, pero también poder hacer prototipos para enseñar.
Desafíate a ti mismo para encontrar nuevas formas de insertar prototipos en tu proceso de diseño; esto podría enseñarle a tu equipo un enfoque nuevo para una idea desafiante. A veces, el acto de construir es la mejor manera de generar energía y superar un problema. Sé claro acerca de las preguntas que estás tratando de responder y el nivel de fidelidad que necesitas para hacerlo.
Para muchos diseñadores prácticos, la creación de prototipos es donde comienza la diversión. Y aunque es la cuarta fase de este marco de Design Thinking, puede ser fácilmente un punto de partida (recuerda, el proceso no siempre es lineal). A veces, la clave para una buena Empatía es compartir o co-crear un prototipo con tus usuarios y recibir comentarios.
En el próximo capítulo, hablaremos sobre cómo usar estos prototipos para probar tus hipótesis, de modo que puedas canalizar tu Feynman interno para superar el problema en cuestión.