Charlas de diseño: mejor colaboración entre diseñadores y desarrolladores con Aarron Walter de InVision

Bienvenido a nuestra serie Design Talks dedicada a compartir los puntos de vista de líderes de opinión y personas destacadas involucradas en el diseño de todo el mundo. Entrevistamos a expertos que trabajan con diseño en diferentes contextos, con diferentes objetivos y a través de diferentes enfoques. En esta serie, esperamos brindar inspiración intelectual y creativa a todos nuestros lectores.

Los diseñadores a menudo tienen dificultades para trabajar con los desarrolladores y viceversa. Los equipos de ambos lados podrían aprender mucho unos de otros, pero aún quedan capas de resistencia. El invitado de esta semana es Aarron Walter, vicepresidente de educación en diseño de InVision, y vamos a hablar sobre la colaboración entre diseñadores y desarrolladores.

Aarron se basa en 15 años de experiencia dirigiendo equipos de productos y enseñando diseño para ayudar a las empresas a implementar las mejores prácticas de diseño. Fundó la práctica de UX en MailChimp y ayudó a hacer crecer el producto de unos pocos miles de usuarios a más de 10 millones.

Su guía de diseño ha ayudado a la Casa Blanca, al Departamento de Estado de EE. UU. y a docenas de grandes corporaciones, nuevas empresas y firmas de capital de riesgo. Es el autor del libro más vendido Designing for Emotion de A Book Apart. Encontrará a @aarron en Twitter compartiendo pensamientos sobre diseño y puede obtener más información sobre Aarron en aarronwalter.com.

En Design Better Podcast, los anfitriones Aarron Walter y Eli Woolery entrevistan a líderes de diseño y personas influyentes que comparten historias sobre cómo resuelven problemas y su trayectoria profesional. Los invitados incluyen a David Kelley (cofundador de IDEO y fundador de Stanford d.school), Julie Zhuo (vicepresidenta de Producto y Diseño en Facebook) y Jake Knapp (autor de Sprint más vendido), entre otros.

Hola Aaron, es un placer tenerte en el blog de diseño de Toptal. ¿Son los desarrolladores de Marte y los diseñadores de Venus?

En mi experiencia, los diseñadores y desarrolladores probablemente tengan más en común de lo que creen, pero definitivamente hay algunas diferencias claras en la forma en que pensamos sobre las cosas. A los diseñadores les encanta pensar en sistemas de diseño y los desarrolladores piensan en código modular que es fácil de mantener. Pero la forma en que lo hacemos puede ser ligeramente diferente.

Los desarrolladores han encontrado formas de dividir su trabajo en partes más pequeñas, y los diseñadores tienden a pensar en todo como el "pastel completo" y cómo nos comemos el pastel completo.

Este es un punto en el que comienzan a chocar. Los ingenieros quieren poder enviar código en pequeños pasos y hacer algo muy rápidamente como parte de la metodología Agile. Los diseñadores tienden a querer dar un gran paso adelante de una manera holística: quieren ofrecer una experiencia consistente. Eso puede ser un punto de discordia para estos dos grupos.

¿Qué pueden hacer los diseñadores para acercar un poco a los desarrolladores a nuestra perspectiva? ¿Cómo hacen los diseñadores para que los desarrolladores entiendan que cada pequeña característica enviada también tiene que ver con la experiencia?

Hay una oportunidad para que ambos lados se dobleguen aquí. Los diseñadores a veces intentan convencer a un desarrollador de que debemos esperar y construir todo, y luego sacarlo a la luz como esta hermosa y completa experiencia.

Pero si el ciclo de creación es demasiado largo, los productos corren el riesgo de morir. La gente empieza a perder interés. Pueden decir: “¿Esto realmente crea valor para el negocio? Estamos gastando un montón de tiempo, energía y recursos en esto, ¿por qué tarda tanto?”. Los diseñadores deben pensar más en el ciclo del negocio.

Si Apple envía un teléfono, una pieza de hardware que tiene un problema, podría costarles miles de millones de dólares, pero si se envía el software y hay un problema, podemos parchearlo, arreglarlo y enviarlo de nuevo. Abordar el proceso de esta manera nos permite volver a conectarnos con el ciclo de trabajo de desarrollo de manera más elegante.

Los diseñadores también podrían tratar de cerrar la brecha entre los dos grupos al involucrar a los ingenieros en el proceso de diseño desde el principio para que se sientan incluidos en la fase inicial de ideación, no solo en la etapa final. Los diseñadores pueden decir: "Se nos ocurrió esta brillante idea, ¡hazla para nosotros!" y eso hace que los desarrolladores sientan que no son parte del proceso de ideación. Son solo las manos y alguien más es el cerebro.

La relación más disfuncional entre diseñadores y desarrolladores ocurre cuando existe una clara división del trabajo. Cuanto más comiencen a mezclarse y esos equipos trabajen juntos, mejor. Como resultado, habría múltiples perspectivas y propiedad compartida, lo cual es realmente clave para que los diseñadores y desarrolladores trabajen juntos de manera efectiva.

Sobre entender mejor el espacio del otro...

¿Qué pueden hacer los equipos para comprender mejor el espacio de los demás? ¿Deberían los diseñadores familiarizarse con el desarrollo y viceversa?

Primero, los diseñadores y desarrolladores podrían hablar más con los clientes y aprender juntos sobre el espacio problemático. Podían hablar con tres o cuatro clientes por la mañana mientras tomaban un café; todos podrían aprender muy rápidamente y llegar a un entendimiento compartido de cuáles son las preocupaciones.

En segundo lugar, en términos del proceso de trabajo, es importante que los diseñadores y desarrolladores tengan, tal vez no fluidez, pero algo de comprensión del lenguaje de los demás. No quiero decir que un diseñador deba saber codificar, o que los desarrolladores deban dominar la tipografía, pero al menos hay un entendimiento compartido.

Si los diseñadores pudieran enmarcar las cosas en un lenguaje que los desarrolladores entiendan, "tal y tal cosa no funciona y eso es malo para el negocio", entonces los desarrolladores comprenderían rápidamente el problema. No es algo que les resulte natural a los diseñadores, pero necesitan ser mejores para comunicar el valor de su trabajo cuantitativamente , no solo cualitativamente . El equipo de ventas, el equipo de marketing, ingeniería, producto, ejecutivos, todas esas personas hablan en números, hablan cuantitativamente .

Dicho esto, sí creo que el diseño aporta algo muy valioso, que hay cosas que cuentan que no se pueden contar. La experiencia del cliente, la alegría, el amor por el producto es muy valioso y eso es difícil de cuantificar.

Sin embargo, puede ser cuantificable, en el futuro ese componente de calidad traerá un ROI que es cuantificable.

Sí, podemos reducir los costos de atención al cliente con el diseño, podemos reducir la rotación, podemos aumentar la velocidad de incorporación. Tener métricas como esa para fijar la vista ayuda al diseño a alinear sus esfuerzos con los objetivos comerciales. Cuanto más puedan hacer eso los diseñadores, más se les entenderá. Cuanto más se valore el diseño en la empresa como una ventaja competitiva, más crecerá el potencial para una mayor inversión.

Sobre los peligros de la colaboración entre diseñadores y desarrolladores...

¿Cuáles son algunos de los mayores obstáculos con los que se encuentran los diseñadores y desarrolladores que trabajan juntos?

Uno de los mayores escollos es no tener un idioma compartido, no tener objetivos compartidos y las proporciones son muy desproporcionadas. A veces hay equipos multifuncionales con un diseñador y 75 ingenieros. Eso suena loco, pero es bastante común.

La gran mayoría de esas situaciones no son buenas. Ese diseñador solitario es un expatriado. Son un extraño en una tierra extraña donde nunca encajaron del todo en la cultura... y su sistema de valores es diferente al sistema de valores de todos sus colegas.

En ese entorno, defender una característica de UX es extremadamente desafiante para un diseñador: "Deberíamos tener esta animación en el producto porque va a crear una experiencia más convincente..." cuando hay 75 ingenieros que dicen: "Son 250 más". líneas de código y dos días extra de trabajo. ¿Realmente vale la pena?” Y probablemente no lo sea. Para ellos, parecerá como "glaseado". Pero esas microinteracciones animadas con un diseñador de UX realmente dan forma a la experiencia del cliente. No son lo único, pero son importantes.

Cuando tienes esas proporciones desiguales entre diseñadores y desarrolladores, se vuelve realmente problemático. Sin embargo, hay soluciones. Empresas como Slack resuelven este problema con el "diseño emparejado". Si hay un diseñador por cada 10 ingenieros en un equipo, y la misma proporción en otro equipo, esos diseñadores independientes pasan unas ocho horas a la semana trabajando juntos, presentándose soluciones unos a otros: "Así es como estoy resolviendo este problema, ¿es esto tiene sentido para ti? ¿Hay una mejor manera de hacer esto?" Pueden ayudarse mutuamente a despegarse y no sentirse como si estuvieran en una isla.

Sobre los diseñadores que transmiten la importancia de UX...

¿Cómo pueden los diseñadores enfatizar la importancia del diseño centrado en el ser humano con desarrolladores que realmente no entienden HCD? Por ejemplo, ¿cómo transmiten los diseñadores que agregar características no necesariamente beneficia al cliente, que la experiencia de usar el producto es más importante que sus características?

Hay un par de formas efectivas de hacerlo. La mayoría de los diseñadores probablemente lo hayan hecho de manera ineficaz al decirles directamente a los desarrolladores: “Oye, agregar más funciones no hace que la experiencia sea mejor. La gente dice que lo quiere, pero en realidad solo hace que el producto sea más complicado”, y es probable que los desarrolladores respondan: “No creo que tengas razón, esa es una opinión. Escuchamos esto de nuestros clientes, por lo que debemos seguirlos”.

Es mejor no abordarlo de frente, sino hacerlo de lado y decir: "Comprendamos mejor el espacio del problema juntos". Compré el almuerzo para nosotros mañana y he quedado para mostrarles a cinco de nuestros clientes usando nuestro producto.

He visto a ingenieros retorcerse en sus asientos cuando ven a un cliente usando el producto y darse cuenta: "Hicimos algo que es bastante difícil de usar, y la gente se siente frustrada por eso". Los ingenieros quieren hacer un gran trabajo, al igual que los diseñadores. A menudo, simplemente no tienen la oportunidad de ver el resultado de su trabajo.

Probablemente haya oído hablar de la predicación de Jeff Gothelf de que debemos centrarnos en los "resultados, no en los productos". Esa es otra forma en que podemos replantear nuestro pensamiento, que un resultado es: "enviamos cinco funciones más", frente a un resultado: "reducimos la rotación en un 10 %".

Sobre el futuro de la colaboración entre diseñadores y desarrolladores...

Hablas con muchas empresas y ves muchos equipos de diseño y desarrollo trabajando juntos. Las herramientas, los entornos y las metodologías están cambiando. ¿Qué depara el futuro para la relación diseñador/desarrollador?

Hay agua salobre en desarrollo, cuando el agua salada y el agua dulce se mezclan, hay una fusión de herramientas de ingeniería y diseño. En lugar de un proceso que se siente como una transferencia donde todo lo que es diseño está aquí y todo lo que es ingeniería está allá, comienzan a mezclarse.

En esa medida, vemos que los diseñadores pasan mucho tiempo en Jira, piensan en las historias de los usuarios y también comienzan a pensar con una mentalidad de ingeniería. Y viceversa, vemos ingenieros que usan herramientas como InVision Inspect, donde ven las especificaciones y el desglose de un sistema de diseño, y comprenden los componentes de cómo encaja todo. Gracias a estas herramientas ya la combinación de disciplinas, se está desarrollando un entendimiento compartido.

Ya sea un desarrollador o un diseñador, puede comenzar a comprender la perspectiva de su socio clave. No significa que tengas que ser un codificador experto como diseñador. Pero no matará a un diseñador si supiera un poco sobre cómo usar Git y cómo escribir algo de HTML y CSS, tal vez un poco de JavaScript. Eso realmente ayudará a los diseñadores a comprender cómo se construyen las cosas y fomentará una mejor colaboración entre diseñadores y desarrolladores.

Lectura adicional en el blog de diseño de Toptal:

• Cómo abordar el diseño para desarrolladores
• Design Talks: Investigación en acción con la investigadora de UX Caitria O'Neill
• Design Talks: diseño emocionalmente inteligente con Pamela Pavliscak
• Design Talks: La búsqueda del diseño basado en valores con Nick Disabato
• Cómo hacer la transición de diseñador UX a consultor UX