Signos y síntomas: detectar y abordar la deuda de diseño

Mohit Santram: Creo que deberíamos haber hecho disparos antes de esto. Ya sabes, eso podría haber ayudado o algo así. Así que...

Clinton Bonner: (Riendo) ¿Ustedes no lo hicieron?

Mohit: No.

Kevin McGrath: (Riendo) No.

(MÚSICA DE INTRODUCCIÓN DEL CATALIZADOR)

Clinton: Bienvenido a Catalyst, el podcast Launch by NTT Data. Catalyst es una discusión continua para líderes digitales insatisfechos con el status quo y, sin embargo, optimistas sobre lo que es posible a través de la tecnología inteligente y las personas excelentes. En el episodio de hoy, nos sumergimos profundamente en un tema que a menudo pasa desapercibidos, pero que tiene implicaciones importantes para el éxito de los productos digitales. Estamos hablando de deuda de diseño. Para ayudarnos a desempacar este problema crítico, nos acompañan dos expertos en la materia: Kevin McGrath y Mohit SanTram. Kevin es Director de Diseño aquí en Launch, y es un profesional experimentado con amplia experiencia en diseño de productos y experiencia de usuario. Mohit aporta una gran cantidad de conocimientos de sus años en estrategia de diseño e implementación, y es director creativo asociado aquí en Launch. La deuda de diseño, al igual que su primo más conocido, la deuda técnica, puede acumularse silenciosamente con el tiempo, lo que lleva a desafíos significativos y una tonelada de ineficiencias. Cuando las empresas hacen recortes en el diseño, ya sea debido a presiones financieras o a la necesidad de soluciones rápidas, las consecuencias a largo plazo pueden ser realmente graves. Hoy, exploraremos qué es la deuda de diseño, cómo se manifiesta, su impacto en las organizaciones y, lo que es más importante, cómo abordarla y mitigarla. Kevin y Mo, bienvenidos al podcast. Nos emotiva tenerte en el estudio por primera vez. ¿Cómo estamos? Kevin, ¿cómo estás, hombre?

Kevin: Muy bien, gracias. Gracias por tenernos hoy, Clinton.

Clinton: Por supuesto. Muchísimas gracias. Mohit. Veo la hermosa sudadera con capucha Launch en tu fondo ahí, hombre. Buen trabajo con eso. ¿Cómo te va hoy?

Mohit: Impresionante. Gracias por tenernos aquí. Clinton.

Clinton: Quiero decir gracias chicos. Ustedes me trajeron esto. Usamos Slack internamente. Hablamos mucho de colaboración y comunicación en este podcast. Es tan crucial, ¿verdad? Entonces, para que yo entienda, como, ¿cuáles son los temas que la gente necesita escuchar? Y cuáles son algunos... Digamos antes, como, bajo el radar ¿cosas que tal vez simplemente no se están mencionando tanto como realmente necesitan ser? Todo el mundo habla de deuda técnica. Todo el mundo entiende eso. Pero este tema de la deuda de diseño realmente me intrigó. Entonces, Mohit, empecemos aquí. Si tuvieras que definir deuda de diseño, ¿qué significa para ti? Y, ya sabes, ¿qué tan grande estamos hablando aquí, hombre?

Mohit: Esa es una gran pregunta, Clinton. Creo que es una cosa muy grande. En concreto, creo que la deuda de diseño significa la culminación o la agrupación de decisiones que se tomaron para eludir áreas específicas de experiencia de usuario, investigación y trabajo de diseño. Estas decisiones por lo general se tomaron probablemente por una variedad de razones. Específicamente, decisiones de negocios que cambian rápidamente. Diseño, desarrollo y atajos de producto. Limitaciones de tiempo, presupuesto y equipo. Optimizar las ganancias a corto plazo frente a las metas a largo plazo. Escalar equipos y perder oportunidades específicas.

Clinton: Bastante abarcador, es a lo que se reduce. Muchas formas en que puede colarse o aparecer. Entonces Kevin, ¿qué agregarías a eso, o cómo lo definirías? ¿Hay diferentes palabras que podrías usar?

Kevin: 100% de acuerdo. Creo que algo que me salta a la atención es realmente importante es la parte de deuda de eso. Porque al igual que la deuda técnica y al igual que la deuda real, se complica con el tiempo si no se aborda, ¿verdad? Por lo tanto, cada solución que desea hacer o una nueva característica que desea desarrollar, se vuelve cada vez más difícil y cada vez más costosa a medida que tiene estas capas adicionales de ineficiencia. Y si se pone realmente mal, las cosas pueden ponerse tan lentas y tan caras que mata por completo tu impulso y potencialmente mata tu producto. Entonces puede ser realmente grave si no se aborda.

Clinton: Muy bien. Entonces, Kevin, voy a hacer un seguimiento ahí. ¿Es similar a, ya sabes, como dijimos en la apertura, un primo de la deuda técnica? ¿O es esto realmente más una forma de deuda técnica, desde su perspectiva?

Kevin: Se superponen de muchas maneras. Entonces, por ejemplo, si está arreglando adecuadamente su deuda tecnológica de front-end, eso va de la mano con la construcción de un marco de sistema de diseño. Y muchas de las herramientas modernas que utilizamos para hacerlo son un lugar donde desarrolladores y diseñadores están trabajando juntos. Entonces pensamos en deuda de diseño y la llamamos específicamente porque la deuda técnica no abarca todo lo que la deuda de diseño considera. Pero hay mucha superposición allí, y se derivan de muchos de los mismos problemas centrales, las mismas decisiones comerciales centrales sobre ser rápido y barato en lugar de tener una base sólida y tomarse el tiempo para hacer las cosas bien.

Clinton: Me alegro de que hayamos conseguido ampliar eso, o definirlo un poco más profundo para el público. Entonces, agradezco eso. Estás mencionando la deuda de diseño y cómo se acumula al saltarse algunos pasos esenciales. Y mencionaste, como, investigación o validación, y lideraste con eso. ¿Puede dar algunos ejemplos de algunos atajos comunes que ha visto tomar las empresas que sí conducen a esta acumulación de deuda de diseño? Entonces conseguimos algunos tipos. Ya sabes, investigación y validación. Pero tal vez ejemplos, y cosas que realmente has sentido en el suelo, donde estás en una conversación y alguien está como, bien, sea lo que sea, no vamos a hacer esta cosa. Y, ya sabes, tu sentido de Spidey se apaga, tus campanas de alarma empiezan a sonar. Entonces, Mohit, ¿por qué no empiezas?

Mohit: Claro. Creo, como, hacer suposiciones de que no necesariamente necesitamos pasar por áreas específicas de investigación de usuarios, o no necesitamos hablar con los usuarios y entender completamente cuáles son los problemas que podrían estar teniendo. Específicamente, entender los puntos de dolor y las áreas de fricción que están experimentando a diario. También, en la línea de, como, pruebas. Y asegurarnos de que los productos que estamos construyendo realmente funcionen, y que respondan a los puntos débiles y a los problemas que están experimentando estos usuarios. Validar todas las preocupaciones y probar todas estas cosas puede sumar muchas ganancias a corto plazo. Entonces, por ejemplo, si una empresa quería saltarse estas cosas porque sentía que no necesitaba hacer estas cosas, o no tenía el tiempo o el presupuesto o el personal para llevar a cabo todas estas tareas, puede que decidan saltarse algunas de estas tareas para poder ahorrar cierta cantidad de dinero.

Clinton: Kevin, creo que te lo voy a dar. Mohit está diciendo ahorrar dinero, pero ¿es eso tal vez solo una ilusión y una percepción del ahorro? ¿Y esta es una situación de pata de mono aquí, hombre?

Kevin: Creo que sí, sí. Sabes, muy a menudo, entiendo la presión a la que se enfrentan las empresas para continuar ofreciendo nuevas funciones y nuevos productos. Pero si opta por victorias rápidas y MVP y nunca se toma el tiempo para volver a planificar esta visión futura y escalabilidad de planificación, sí, está bien, está ahorrando dinero en esta característica, pero cada nueva característica que lance va a ser cada vez más costosa. Y terminas con una suerte de muerte por una situación de mil cortes.

Clinton: En ese ejemplo en particular, liberas una función, obtienes tu... Tu gratificación instantánea, ¿verdad? Como, golpe de dopamina porque lo sacaste al mercado más rápido. Como, felicidades, marca la casilla, has acertado a tu cita. Y entonces estás sufriendo en el fondo. ¿Cuáles son algunas de las cosas que salen de la línea que has experimentado, Kevin, y visto, cuando una organización toma ese atajo desde el principio?

Kevin: Quizás este sea yo, en particular, en los que he trabajado, pero tiendo a trabajar en una especie de experiencias multiplataforma de clientes, donde tal vez tienen dos portales diferentes, están construyendo dos tecnologías diferentes, y como hacen una muy rápido, no se toman el tiempo para volver atrás y actualizar el otro para que coincida, y terminas con una experiencia de usuario desarticulada. O tiene un sistema de diseño que no se está implementando correctamente en ambas cosas. Entonces, los usuarios tienen dificultades para regresar y entender cómo usar esa característica en el segundo producto, porque es totalmente diferente de cómo la usaron en el primero.

Clinton: Lo tengo. Entiendo esa parte. Entonces, Kevin, ¿algún otro atajos que te venga a la mente?

Kevin: Sí, quiero decir, las soluciones rápidas no siempre son solo cuando se trata de lanzar un producto. A veces se trata de tu organización, también. Entonces creo que no contratar a las personas adecuadas es un atajo común que veremos. Las organizaciones que quieren ahorrar dinero en diseño cargarán de personal al equipo, o contratarán a muchos diseñadores junior porque, ya sabes, son menos costosos. Pero esos diseñadores junior tal vez no saben cómo manejar la deuda de diseño, o no saben cómo construir soporte de nivel ejecutivo para la inversión que se necesita para hacer las cosas bien. Por lo tanto, es tanto en su proceso diario de construcción de un producto, como en la organización de su equipo, como en las herramientas y el proceso que utiliza para colaborar como organización.

Clinton: Entonces, eso realmente me lleva a otra pregunta que tenía para ustedes alrededor... Estás hablando de contratar y asegurarte de tener a las personas adecuadas ahí, o al menos estás accediendo y trabajando, trayendo a los socios adecuados. Si no estás en la, ya sabes, la arena a contratar. Eso me hace pensar en el liderazgo de diseño y tal vez la falta del mismo. Entonces, Mo, si vas a entrar en un entorno cliente, ¿cuáles son algunos de los síntomas o sentidos que obtienes, si simplemente hay una falta de liderazgo en diseño? ¿Cómo lo sabes cuando lo ves?

Mohit: Ahí hay otra gran pregunta, Clinton. Yo sí creo que hay... Muchas veces hay muchas señales que vas a ver. Entonces, por ejemplo, para una organización que puede tomar atajos, puede que no haya defensores de luchar por el usuario, o puede que no haya una persona que no reconozca que hay una pérdida a largo plazo al asumir o asumir una deuda de diseño. Para que alguien pueda reconocer y decir, esto es genial, estamos optimizando ciertas características, o asegurándonos de que estamos lanzando código o productos en un marco de tiempo determinado. O podría ser, como señaló anteriormente, podría estar eligiendo usar más diseñadores o desarrolladores junior o gente de producto para poder construir un producto. Eso podría indicarme que alguien está haciendo un... Tomar un atajo, y no necesariamente aceptar que hay mejores opciones que tomar, o que se deben tomar, para asegurarse de que un producto se lance correctamente y satisfaga los objetivos comerciales que fueron la razón principal para construir el producto en primer lugar.

Clinton: Kevin, devolviéntelo a ti, ¿qué tal esas señales reveladoras? Sabes, ¿hay un par de cosas que ves? O, ya sabes, empiezas a meterte bajo el capó con un cliente, y cuáles son algunas de las cosas que empiezas a escuchar de ellos donde estás como, oh, chico. Puede que no se den cuenta, pero están sufriendo de esta deuda de diseño, pero probablemente simplemente no saben nada mejor.

Kevin: Hay cosas, creo, que no tienes que ser diseñador para ver siempre. Entonces cosas como quejas de los usuarios. Si su equipo de soporte y su equipo de ventas siguen regresando y diciendo, estamos escuchando las mismas quejas de UX una y otra vez de los usuarios, y tenemos bajos puntajes de satisfacción del cliente, métricas bajas de adopción de funciones, tenemos estos problemas de degradación de marca, eso es una señal ahí mismo. Altos costos de mantenimiento. Entonces, cuando un cliente habla de cómo le lleva un montón de tiempo simplemente lanzar algo nuevo, o intentaron construir algo y les costó una fortuna y fue increíblemente lento, eso es porque no tienen una base sólida en su lugar. Pero creo, honestamente, lo más importante que me salta a la vista, y lo que le pediría a cualquier líder que no esté en el espacio del diseño que piense y busque es la frustración del equipo. Creo que el factor humano es donde realmente empiezas a ver esto, donde tienes diseñadores y desarrolladores que están frustrados por la complejidad de su trabajo diario. Y en situaciones más extremas, la rotación de equipos. Dificultad para contratar y retener el tipo de personas que son capaces de resolver estos desafíos por ti.

Mohit: Me gustaría agregar, también, que también hay algunos otros signos. Entonces, por ejemplo, experiencias inconsistentes. A lo que Kevin estaba diciendo, pensando en el mayor tiempo que se necesita para diseñar, desarrollar y enviar las características del producto. Cuando una base de código no está sincronizada, o un sistema de diseño no se utiliza completamente de la manera correcta, encontrará que puede haber muchos atajos, y esos pueden surgir de inconsistencias visuales que mencioné antes. Y pensar en la satisfacción de que las personas en el equipo que están construyendo esos productos, si su satisfacción comienza a bajar, o la complejidad del contenido o el trabajo que están haciendo toma un giro marcadamente malo, eso es definitivamente una señal de que no se está prestando suficiente atención a esta deuda de diseño que se va construyendo con el tiempo.

Clinton: Si. Lo que es realmente interesante de lo que ambos me dijeron es que... Yo esperaría, por el bien de la audiencia, que cuando están, si lo están, sientan que podrían estar sufriendo de esto, o incluso podrían empezar, incluso sentirlo, que podría estar ahí, es como, oye, en realidad hay una gran variedad de personas con las que puedes ir a platicar. Y Kevin, cuando mencionaste rotación, es como, bueno, puedes ir a mirar, tal vez ir a platicar con RRHH. Como, literalmente, entrar en los datos de recursos humanos, como, oye, ¿estamos viendo rotación dentro de esta parte de la organización? ¿Por qué? Como, ¿qué es lo que está pasando con esas entrevistas de salida? Como, bien, están frustrados. ¿Por qué están frustrados? Y yo diría hasta, si hay un Chief Experience Officer o un Chief Digital Officer. Y platicar con la gente que está tratando de trabajar y descifrarlos, porque les importa profundamente. Como, su trabajo es examinar, desenterrar y realmente cuidar cada transacción digital o experiencia digital que posiblemente podría estar ahí fuera. Y por supuesto, ese es un cuento bastante alto. Podría haber miles y miles. Pero esa es su carta. Y creo que platicar con ese equipo y destapar sus frustraciones, y creo que eso en realidad podría burbujear, Kevin, con el ritmo del que hablabas. Probablemente están siendo inundados por el negocio constantemente. Entonces sienten que tal vez no pueden entregarlo tan rápido como quieren, o sienten que deberían poder hacerlo, y podrían ir a platicar con el negocio. Esa podría ser otra gran señal revelador. Sí, tenemos una hoja de ruta de dos años. Y nada parece que realmente se haga. Y cuando se hace, no es exactamente derribar calcetines, ¿verdad? Entonces, si quieres llegar al fondo, probablemente haya varias personas con las que puedas ir a conversar, lo que creo que es fascinante. Es bastante cool.

Kevin: Sí, 100%. Podrían tener formas ligeramente diferentes de articularlo, pero creo que si hablas con todos ellos, podrás ver las similitudes ahí. Si.

Clinton: Entonces, Mo, digamos que ellos hicieron esta investigación, y descubrieron que, sí, es la deuda de diseño la culpable. Como, estoy seguro que ustedes han estado en situaciones en las que han tenido que presentar esa noticia. Entonces, si no hay un líder de diseño dentro de la organización con la que está trabajando, ¿cómo representa eso? Y ¿cómo haces que, ya sabes, digamos que un CEO o un CIO o un oficial digital, le impidan un comido? ¿Entonces toman la información y luego actúan sobre ella?

Mohit: Gran pregunta. Yo sí creo que realmente está identificando la raíz del problema. Y creo que es tener una conversación franca y abierta con la dirección sobre el cliente, per se, que podría haber estado ignorando algunas de las señales reveladoras. Creo que como narradores digitales y desarrolladores de productos y creadores, es nuestro trabajo asegurarnos de que estamos transmitiendo lo que es esa historia a todos los participantes. Entonces, si un defensor del diseño de nuestro lado ve que hay algo que se está perdiendo, es importante para nosotros ser capaces de reconocer cuáles son esas cosas, empaquetar una historia real, mostrar datos reales. Entonces, por ejemplo, como Kevin estaba aludiendo anteriormente, la cantidad de tiempo que puede llevar entregar o enviar una característica específica del producto o un producto real en sí... Si ese tiempo comienza a alargarse, porque, digamos, el sistema de diseño está fuera de sincronía, o los desarrolladores se sienten frustrados por que el código base sea muy complejo, es importante para nosotros poder tomar toda esa información y poder articular eso mostrando exactamente cuánto tiempo ha tardado algo en ser liberado o desarrollado o diseñado. Y luego volver y decir, bueno, bajo las situaciones ideales, o en otras instancias, este es el tiempo que debe tomar una función, en situaciones ideales. Y luego comenzar a construir una historia o un camino en cuanto a, cómo podemos tender un puente desde donde estamos hasta donde deberíamos estar. Pagar la deuda de diseño es una tarea muy ardua, pero es una tarea importante que las empresas tendrán que asumir en ciertos puntos. Nos toca a nosotros, creo, como diseñadores, como defensores, como desarrolladores, como líderes, volver a esos líderes de nuestro lado del cliente y decir, estos son los síntomas, estos son los problemas reales, esta es el área que podemos ayudarle a abordar. Y estos son los pasos específicos que podemos tomar para volver a la pista.

Clinton: Entonces, Kevin, qué difícil puede ser eso para... No quiero decir el diseñador promedio, porque eso es solo pintar con un pincel terriblemente amplio. No obstante, eso no suele ser lo que hacen ahí en su día a día. Y no es en lo que se les educó, y no son las cosas por las que van a conferencias, ¿verdad? Pero eso es un problema de negocios. Tienen que lograr, como, lograr la gestión del cambio desde su perspectiva. Y Mo, como dijiste, enmarcánelo en un problema de negocios. Que hay datos, que las cosas están tardando demasiado, y nos está costando dinero e ingresos y ganancias y servicios, etcétera, etcétera. ¿Qué tan difícil puede ser para la mayoría de los diseñadores hacer ese argumento y hacer que se mantenga?

Kevin: Definitivamente puede ser difícil para los diseñadores que son nuevos, que son junior o simplemente nuevos en el espacio tecnológico. Porque tienes razón, no vas a la escuela, escuela de diseño para aprender ese tipo de cosas. Acudes a la escuela de diseño para aprender a construir estos grandes productos y experiencias. Y creo que parte del reto catch-22 es que, además, los diseñadores no quieren tener que comunicar esto. Sé que suena un poco raro, pero, como, quieres estar construyendo cosas, y todo el tiempo que tienes que pasar obteniendo la aceptación de los líderes y convenciendo a la gente de que esto es importante es tiempo que no estás llegando a gastar construyendo un producto fantástico. Entonces es un poco desafiante en dos frentes ahí. Es ambos.

Clinton: Si.

Kevin: La comunicación toma tiempo para aprender a hacer eso, y también a menudo puede sentirse como una distracción. Como, es importante, obviamente, pero es tiempo de construir una experiencia fantástica.

Clinton: Derecha. Y se inclina hacia atrás en el punto que mencionaste antes sobre la importancia del liderazgo en diseño. Ojalá estén en, alguien en el nivel de C-suite, pero si no están realmente atados para que la voz esté ahí y el pulso siempre esté ahí, para que la gente entienda cómo van las cosas en el mundo de asegurarse de que las cosas sean realmente suaves, que puedas operar y que el diseño no sea un cuello de botella. Porque, ya sabes, el diseño siempre está destinado a ser... Es el altamente colaborativo, podemos ir rápido, podemos obtener los prototipos en los que se puede hacer clic, podemos mostrarte el futuro y podemos hacerlo bastante rápido. Por eso el liderazgo en diseño y tener esa voz podría ser súper importante. Y si no lo tiene en su organización, bueno entonces al menos cuando esté trabajando con sus proveedores y sus socios, asegurándose de que ellos sí. Y cerciorarse de que puedan ser ese defensor. Porque sin él, me imagino que cosas como esta probablemente solo seguirán amontonándose y no se aborden, es mi, ya sabes, mi intuición sobre eso. Entonces, Mo, te voy a dar esto a ti también. Hemos identificado deuda de diseño. Tenemos buy-in. Nosotros hicimos el caso. La gente es como, consíguelo. Tienes razón. Tenemos que ir a abordar esto. ¿Cuáles son algunas de las cosas tácticas que deberían estar haciendo... Después de que se haya tomado la decisión. Sí, tenemos que abordar esto. ¿Cómo empiezas a compilar esa... Hay tantas cosas que podrías ir a hacer primero. ¿En qué estás enfocado?

Mohit: Creo que es importante reconocer primero cuál es el problema. Y en concreto, ¿cuáles son los síntomas? O ¿por qué estos diseños, por qué se devenga la deuda de diseño en primer lugar? Entender cuál podría ser ese proceso a partir de un proceso de toma de decisiones, o, ¿hay las personas adecuadas? ¿Tenemos suficiente personal? ¿Tenemos a las personas adecuadas en los niveles adecuados que tengan la capacidad de tomar esas decisiones? Y luego poder decir, bien, desde ese punto de vista, ¿cuáles son las áreas más importantes donde podemos tener la mayor cantidad de impacto? Si es retroceder y mirar un sistema de diseño que está desactualizado, ¿actualizará un sistema de diseño para que sea más fácil para los desarrolladores encontrar la información que necesitan, de modo que no dependan de cuellos de botella o decisiones de otras personas, ya sea producto o diseño o negocio, para poder ejecutar ciertas áreas de código? Si esa es un área en la que podemos ayudarlos a optimizar, entonces sin duda ayudaremos a priorizar primero las áreas que son importantes. También es, creo, importante ayudarlos a entender las elecciones que están tomando y las ramificaciones. Entonces, elegir una victoria a corto plazo sobre una pérdida a largo plazo, creo que creará daños colaterales. Y es importante para nosotros decir, este es el resultado. Entonces, en el futuro, para ayudar a educarlos, cuando esto se presente, cuando haya una decisión que pueda necesitar ser tomada y podamos eludir ciertos aspectos del diseño o del pensamiento, ya sea estratégico o de producto o de ingeniería, va a ser importante entender que esto es lo que podría suceder. Entonces, ayudarlos a reconocer cuáles son los síntomas de los problemas, cuáles podrían ser los efectos de esos problemas, pero luego también cómo evitarlos en primer lugar, es algo que podemos ayudarlos a hacer.

Clinton: Sí, eso tiene mucho sentido. Seguro, Mo. Y luego... Otra cosa que sin duda he experimentado en mis, lo que sea, 13 o 14 años... He estado en tecnología. Ahora soy comercializadora. Hablo de tecnología. Yo no codico. Sin embargo, termino hablando con muchos líderes diferentes, diferentes personas que ciertamente están en tecnología y pueden meterse bajo el capó. Una de las cosas más grandes que veo que funciona una y otra vez, y ya sea que se trate de deuda de diseño o algún otro tema, es conseguir victorias en la pizarra temprano y ganar impulso para mostrar un valor temprano que tu hipótesis, tiene algunos brotes verdes y luego tal vez incluso algunas victorias tempranas. Entonces Kevin, ¿hay algún tipo de ganancias rápidas de bajo costo que las organizaciones puedan ver si están empezando a mirar la reducción de la deuda de diseño? ¿Hay algunos que alinearías y dirías, sí, haz estos primero si la intención es, mostrar valor rápido, ganar impulso?

Kevin: Sí, es una buena pregunta. Es una dura. Porque creo que depende del nivel de la deuda de diseño. Si el nivel de deuda de diseño está en el lado inferior, entonces sí, absolutamente. Puedes introducir un sistema de diseño, si no has estado trabajando en uno. Puede revisar el que está usando o tratar de vincular más a un entorno front-end para lograr eficiencia allí. Puedes agregar una función de operaciones de diseño a tu equipo. Si no tienes a alguien que sea una especie de responsable de eso, puedes contratar un nuevo rol o convertirlo en un rol gerencial, eso te va a ir muy lejos. También puedes... Tal vez sea un poco opuesto a una victoria rápida, pero puedes tomar la decisión de ralentizar el lanzamiento de una función y darle al tiempo, al equipo un poco más de ancho de banda para construir una solución escalable, ¿verdad? Si haces, como, una cadencia de sprint. Diga, como, bien. El cuarto sprint, nos vamos a centrar en escalar y convertir lo que hemos estado construyendo antes en una base más sólida. Puede subir el nivel de liderazgo en diseño. Realmente es fácil tomar a un líder de diseño que lo está haciendo bien en este momento y simplemente darles más visibilidad estratégica, más voz a nivel de liderazgo. Entonces creo que si la deuda de diseño no es tan mala... Sí, hay un montón de cosas que puedes hacer. Pero si el problema se ha enfurecido, ¿verdad? Si la deuda de diseño realmente se ha acumulado, realmente no hay forma de evitar el hecho de que es un alto costo y un tiempo significativo para arreglar las cosas. Y ese es un punto difícil en el que estar porque hay que arreglarlo. Cuanto más espere, más cara va a ser la solución. Y tal vez hay que retroceder un poco en contra de la idea de conseguir victorias rápidas e impulso, porque no quieres empezar a construir cosas nuevas o hacer cosas nuevas que solo van a empeorar la deuda. Si es realmente malo, tienes que sentarte y tener una conversación real sobre, ¿cómo podemos volver al punto de partida y hacer un pequeño reinicio en estas cosas? Porque lo hemos dejado pasar demasiado tiempo.

Clinton: Esa es una gran respuesta, hombre. Me encanta el hecho de que... Viene con el peso, que hay que tener un poco de juicio sobre la situación en cuestión y ser honesto al respecto. No hay alguna línea en blanco y negro que vaya, bien, esa cosa extra y es severa versus más leve, así que por lo tanto ve por las victorias rápidas. Pero creo que es algo realmente inteligente decir que ahí hay alguna línea para entender que si o no, ¿en qué cubo te caes? A pesar de que hay un gradiente, claro. Y donde las victorias rápidas para uno de ellos pueden darte impulso, puede ser exitoso, puede ser algo que sea positivo. Y luego Mo, te vi asentiendo por ahí cuando Kevin respondía. Pero en el otro caso, cuando es realmente severo, en realidad podrías estar haciéndote un mal servicio si solo vas por las victorias rápidas. ¿Hay algo que puedas agregar a eso, o ejemplos que hayas tenido que pelear, de manera positiva, con un cliente sobre, oye, tenemos que retrasar alguna gratificación para hacerlo de la manera correcta?

Mohit: Otra gran pregunta aquí. Tenemos un cliente actual con el que estamos trabajando que, de nuevo, de presupuesto limitado. Quieren liberar mucho trabajo muy, muy rápido. Tienen un conjunto limitado de usuarios que están usando este producto internamente, que se está utilizando para difundir mucha información externamente. Y es importante que esas personas puedan ingresar información en el sistema fácilmente. Pero lo que encontramos es que a veces, cuando estamos manteniendo un ritmo frenético de intentar liberar mucho código, o de lanzar una gran cantidad de características que tal vez no hayan pasado por suficiente investigación o pensando desde el punto de vista del diseño de sistemas, tendemos a perder, porque lo que sucede es que, bueno, vamos a construir esto para un par de usuarios, vamos a sacar este código. Y lo que encontramos es que el tiempo total que nos toma liberar ese código y lanzar esa característica específica lleva mucho más tiempo. Debido a que vamos muy lejos, hemos lanzado un montón de diseños, y luego descubrimos un problema. Y este problema específico, podríamos haber descubierto en una fase mucho más temprana si hubiéramos pasado por el proceso de pasar por la investigación y asegurarnos de que estábamos hablando con los usuarios y pensando en puntos débiles y haciendo todo el trabajo que inicialmente deberíamos estar haciendo. Y lo que encontramos es que más adelante, ese daño colateral que mencionamos antes, que empieza a aflorar. Para que podamos decirlo, tomemos una victoria rápida al pensar en desarrolladores específicos como ejemplo, que podrían estar más comprometidos al asegurarnos de que se sienten como si estuvieran siendo escuchados, o las recomendaciones que el producto, la UX y la ingeniería podrían estar proporcionando a un cliente están siendo escuchadas. Esa es una muy buena victoria rápida. Creo que eso podría tener un efecto a más largo plazo de poder ayudar a deshacer los daños de la deuda de diseño en los que se ha incurrido.

Clinton: En términos de, bien, entonces, en ese caso, estoy pensando que tal vez tienes a alguien que tiene una carta, ¿verdad? Tienen una hoja de ruta. Y su trabajo probablemente se mide por cuántas, posiblemente, cuántas características obtienen. Ya sabes, y luego, por supuesto, pueden medir la captación y todas esas cosas en el camino. Entonces están en producto y están realmente alineados para asegurarse de que todos los boletos de JIRA se hagan, y que este maldito producto salga con las características que prometimos, y si no, su trasero podría estar en juego. Si esa es la persona que realiza la llamada, en definitiva, porque es el dueño del producto, digamos, ¿qué tienes que decirle para que vengan a tu lado?

Kevin: Sí, es un reto. Y parte de eso es una especie de naturaleza única del trabajo que hacemos. Como sabe, no somos diseñadores integrados en una organización de productos. Nos contratan como expertos para venir y apoyar a los clientes que están pasando por estos desafíos. Entonces, es algo así como, primero tienes que asegurarte de que el cliente directo con el que estamos trabajando lo entienda. Entonces tienes que averiguar qué tan malo es. Entonces, tienes que ayudarlos a ser el agente de cambio dentro de su propia organización para comunicarlo de nuevo y obtener ese cambio de mentalidad sobre, bien, no podemos estar juzgando basándonos en el éxito de, como, ¿cuántas características enviamos? Necesitamos cambiar la forma en que juzgamos basándonos, tal vez, en cuántas personas adoptan esas características. ¿Correcto? Esa es, creo, para mí, una medida más significativa de lo útil que es un producto, cuántos de los usuarios realmente están interactuando con él, en lugar de cuántos empujaste por la puerta. Y creo que a veces la parte más gratificante de, cuando llegamos a profundizar en proyectos que están realmente en lo profundo de esto, es que realmente podemos ser el socio de alguien para ayudarlos a solucionar este problema real. Porque algo de lo que Mo y yo hemos hablado antes es que, cuando las orgs se han acostumbrado a hacer las cosas de manera incorrecta, a saltarse la investigación, a decir, es suficiente, eso se convierte en algo cultural que es realmente difícil de deshacer, y puede ser muy perturbador sacar a una org de eso. Pero, ¿sabes qué? Necesitan disrupción. Así es como funciona.

Mohit: Y creo también, para agregar a eso, creo que a veces, ya sabes, como, los hábitos que están arraigados por ese tipo de procesos de toma de decisiones son difíciles de sacudir. Y se necesita un poco de trabajo para que podamos reconocer y ayudarlos a reconocer por qué están haciendo ciertas cosas, o por qué tienen este tipo de pensamiento incorporadas a su cultura corporativa. Como Kevin está hablando de ser agentes de cambio, es importante para nosotros poder mostrarles, estas son las carencias. Y es por eso que. Pero sin embargo hay un camino más roser, hay un camino más productivo, siguiendo más ideales.

Clinton: La parte fascinante para mí es que muchas de las conversaciones en este podcast, en el podcast Catalyst, terminan hirviendo o se reduce a duras conversaciones de liderazgo y gestión del cambio. Es solo que... una y otra vez. Y creo que es porque, o al menos creo que una de las cosas que tienen en común es, siempre estamos discutiendo sobre hacer esto dentro de la empresa. Y la empresa es grande y rechinada. Y hay mucha gente y hay niveles y hay personalidades y hay política, hay todas estas cosas. Y es un poco genial que una discusión que comienza con este problema de esta deuda de diseño se resuelva al menos en parte siendo un retador honesto, una gran comunicación y ayudando -lo dijiste, Kevin- como, tal vez tomando el antihéroe y luego convirtiéndolo en el héroe de la historia. O bien, ellos son los que son detractores y tienes que, como, abrazar al que te gusta, conseguir que lo vean a tu manera. Y luego tienen que ser los defensores vocales, porque son los que están en la sala con el equipo. Que salgan a tomar cervezas con, tal vez, o al menos ver virtualmente y pasar el rato y hacer trivia con. Ya sabes, como, eso es algo real para moverte. Eso es muy... Es... Para mí, es genial escuchar eso también, porque simplemente no hablas de diseño de esa manera muy a menudo, porque la gente es tan... No quiero decir amigos, humanos. Somos tan visuales. Entonces, nos encantan las cosas brillantes. Nos encantan los prototipos rápidos y en los que se puede hacer clic. Pero debajo de eso hay mucho trabajo duro para que las organizaciones estén listas para aceptar la verdad, y luego mejorar. Lo cual creo que es realmente fascinante. Entonces, entretejamos el tema omnipresente, y potencialmente omnipotente, de la IA. ¿Correcto? Entonces, la IA está en todas partes y por una buena razón. ¿Qué pasa con la IA? Mo, voy a empezar contigo. ¿Las empresas están considerando la combinación de IA más humanos para abordar específicamente la deuda de diseño? ¿Hay caminos ahí donde eso pueda ser exitoso y utilizado de esa manera?

Mohit: Absolutamente. Creo que muchas empresas probablemente estén viendo la promesa de la IA para ayudar a automatizar ciertas tareas específicas. Como profesionales y diseñadores de UX, es importante para nosotros luchar siempre por los usuarios y ayudar a representar sus necesidades. Pero cuando pensamos, a veces, en el tiempo que se tarda en hacer ciertos aspectos de nuestro trabajo, puede requerir mucho tiempo. También puede ser costoso. Entonces creo que muchas empresas podrían mirar algunas de estas herramientas de IA, y nosotros también podemos ayudar a acelerar algunas de las tareas de nivel inferior, o para poder pensar, ¿cuáles son las cosas que podemos hacer y automatizar, que son necesarias? Eso puede no haber conseguido que la luz brillara sobre ellos, o que se hubiera cortado en el pasado. Pero si pudiéramos usar IA para ayudar a usar esa tecnología para hacer ese tipo de trabajo, y eso nos permite como profesionales pensar realmente, y pasar más tiempo en puntos de vista estratégicos, o pensar en las áreas que realmente necesitan un enfoque más específico, creo que eso proporcionará, o podría proporcionar, beneficios de costos reales, así como beneficios de experiencia, para las empresas que construyen productos digitales.

Clinton: Entonces, Kevin, en el tema de IA, ¿algo que agregarías a lo que dijo Mo?

Kevin: Mo y yo somos miembros del AI Guild del equipo de diseño, así que en realidad podemos platicar sobre esto bastante a menudo, lo cual es divertido. Tengo algunas preocupaciones sobre el impacto de la IA en la deuda de diseño. Sospecho que muchos negocios van a ver, en YouTube o TikTok, alguna herramienta de diseño donde dicen, oh Dios, puedo poner un aviso y va a diseñar una pantalla para mí y eso significa que no necesito este marco de diseño robusto. Pero esa no es una solución escalable, ¿verdad? Así que me preocupa un poco que los enfoques miopes de la IA hagan que la deuda de diseño sea significativamente peor para las empresas que aún no tienen un enfoque de diseño maduro, y realmente no entienden el peligro de hacerlo. Algo de lo que llegamos a hablar en el Gremio a veces es que históricamente, la nueva tecnología no siempre devuelve tiempo a la gente, sino que eleva las expectativas de lo que pueden lograr en el tiempo que se les da. Entonces, las herramientas de IA que aceleran la capacidad de los diseñadores para hacer las pequeñas cosas tácticas... Si las organizaciones piensan, bien, eso significa que tiene tiempo para hacer más cosas en lugar de una oportunidad de dar un paso atrás y pensar en cómo tiene una solución escalable, entonces no va a resolver nada. Entonces creo que de verdad, son las prácticas organizacionales que van a ser lo que determine la deuda de diseño. Y la IA es una especie de solo una de las muchas herramientas que los diseñadores van a utilizar para ello.

Clinton: De nuevo, me encanta el matiz, y un poco del yin y yang que tenemos en el... Puede ser ese acelerador y puede colapsar algunos marcos de tiempo, y luego el... La pequeña advertencia de, bien, pero ten cuidado con cuáles son las expectativas y cómo luego vas a usar ese tiempo, y no solo para ir tal vez sacar la siguiente cosa, en lugar de, tal vez algún trabajo más profundo que podría suceder para, ya sabes, cambiar la forma en que haces parte del trabajo, también. Entonces, algunos grandes pensamientos ahí. Una última pregunta, voy a empezar contigo, Kevin. Entonces, de cara al futuro, ¿qué otras tendencias o tecnología emergente ve que juegan un papel importante o un papel floreciente para ayudar a las organizaciones a comprender y luego pagar su deuda de diseño?

Kevin: Mo ya señaló muchas oportunidades interesantes en el horizonte en torno a la aceleración de los sistemas de diseño y la documentación y la investigación. Dos cosas que me llaman la atención es que, los marcos de sistemas de diseño son cada vez más accesibles. React, Tailwind, Angular, esas son todas las cosas que tienen un mejor y mejor soporte para el enfoque de sistemas de diseño. Los sistemas de tokens finalmente están obteniendo soporte oficial en herramientas como Figma, a pesar de haber sido algo de lo que los diseñadores han hablado durante una década. Entonces, muchos de estos sistemas se están volviendo más accesibles. Y creo que, más o menos, a medida que los sistemas de diseño se acercan y el diseño escalable se convierten en el estándar en este tipo de espacio central de productos digitales, esas mejores prácticas tienen una manera genial de comenzar a abrirse camino en otras áreas de productos digitales. Entonces, como, el año pasado, tuvimos un cliente que quería moverse más al espacio 3D inmersivo y en tiempo real, pero estaban preocupados por administrar la deuda de diseño en esta tecnología totalmente nueva. Uno que no va de la mano con Figma. Entonces construimos una herramienta de sistema de diseño primera en su tipo para ayudar a automatizar ese proceso, por lo que no pueden preocuparse por tener esta explosión de deuda de diseño solo por intentar adoptar una nueva tecnología.

Clinton: Y conozco ese proyecto. Ojalá pudiera nombrar quién fue. Pero sé lo que era, y he visto el caso de estudio interno, y es como, oh, ese es un caso de uso genial, tan genial. Y de nuevo, la creatividad y la invención de, bien, este es un nuevo problema de negocios. Pero lo hizo en cola realmente genial, Kevin, que el cliente entendió, nos estamos aventurando en este nuevo entorno colaborativo. Y si no tenemos cuidado, si solo empezamos a arder armas, por así decir, salir y empezar a crear cosas sin una apariencia de lo que este nuevo sistema necesita hacer, vamos a terminar en una situación en la que no podemos escalar, no podemos replicar, simplemente estamos desguazados, y vas a tener que tener gente con exquisito conocimiento de dominio de esa herramienta específica para hacer cualquier cosa, y entonces nadie podría usarla, que era exactamente el propósito opuesto de hacerlo colaborativo y más compartible en primer lugar.

Kevin: Sí,

Clinton: Así que realmente, muy genial, muy genial viñeta allí. Mohit, ¿algo más que agregarías a, ya sabes, pronósticos futuros, si quieres, de esta área en particular y abordar la deuda de diseño?

Mohit: Solo soy un gran fan. Yo simplemente, creo que a todos nos encanta Figma, más o menos, pero creo que es genial poder ver la democratización, creo, del acceso a muchas de las herramientas, y las vías que elegimos para poder pensar en diseño. Entonces, es genial, como ejemplo, cuando estoy trabajando con desarrolladores específicos que se están metiendo en Figma, a modo de ejemplo, como saben, Kevin está aludiendo a, muchas herramientas, solo una de muchas. Pero cuando ves que los desarrolladores son capaces de abrazar las tecnologías que estamos usando, y poder colaborar con ellos de manera más abierta, más rápida y más fácil, de modo que la información o la difusión de información va del cerebro de una persona al cerebro de otra persona con bastante rapidez, es realmente asombroso. Entonces, simplemente me encanta la colaboración de todas las herramientas que estamos usando, y el hecho de que podamos estar dispersos por todo el mundo, si no por todo el país, y poder tomar decisiones muy rápidamente, en lugar de pensar en las cosas como eran antes en nuestras carreras, eso podría haber tomado una gran cantidad de tiempo para haber llegado a una decisión específica. Ahora bien, creo que podemos usar herramientas que nos ayuden a reconocer que hay problemas significativos con la deuda de diseño, y ahora podemos ayudar a usar algunas de esas herramientas para ayudar a abordar esos problemas más rápido y antes.

Clinton: Me encanta esta conversación. 12 de diez, lo recomendaría. Kevin y Mohit, muchas gracias por acompañarnos hoy y compartir sus valiosas ideas sobre la deuda de diseño, sus perspectivas sobre cómo la deuda de diseño, cómo se acumula, la importancia crítica de abordarlo y los pasos prácticos para mitigarla han arrojado mucha luz sobre este tema pasado por alto. Como hemos visto y aprendido hoy, ignorarlo podría conducir a experiencias de usuario inconsistentes, una tonelada de recursos desperdiciados y frustración, e incluso poner en peligro el éxito a largo plazo del equipo y el negocio. Pero al reconocerlo, tener esas conversaciones difíciles desde el principio, invertir en las prácticas adecuadas y los equipos adecuados, y aprovechar las nuevas tecnologías netas y experimentar, podría cambiar el rumbo, y hacerlo muy, muy bien para que pueda escalar y tener un buen flujo y tener gente feliz y excelentes productos en el mercado lo más rápido posible, y puedan salir ahí. Entonces chicos, muchas gracias por estar hoy en el pod. Y para nuestros oyentes, esperamos que la discusión de hoy les haya parecido tan esclarecedora e inspiradora como nosotros. La deuda de diseño puede parecer un concepto abstracto, pero sus efectos son claramente, muy, muy reales y de largo alcance. Y gracias de nuevo, chicos. Como siempre, gracias y por favor transmita estos episodios a sus amigos, a sus compañeros. Pensamos que ellos también los disfrutarían. Porque en este estudio creemos en el envío de software sobre slideware, ese rápido seguirá sin problemas, y apuntar a crear experiencias digitales que muevan millones es una búsqueda muy digna. Únase a nosotros la próxima vez mientras la búsqueda continúa en Catalyst, el podcast Launch by NTT Data.

(CATALIZADOR DE MÚSICA OUTRO)