Panel de Discusión: UX y la Superposición Diseño/Desarrollo

Muchas gracias. ¿Podemos aplaudir a nuestros panelistas? Gracias por estar aquí. Hay una larga introducción que se supone que debo leer para todos ustedes. En cambio, voy a ignorar eso y comenzar con, ya saben, una introducción personal porque ustedes tres podrían ser, ya saben, un poco de mis héroes de design desarrolladores, cada uno a su manera.

Steve trabaja en TLDraw como fundador y creador de TLDraw. Y es uno de los desarrolladores más perspicaces y detallistas que he visto cuando se trata de crear increíbles interacciones de usuario en TLDraw y en otros lugares. Así que estoy muy contento de tenerte aquí, Steve. Gracias. Sí.

Y un poco de todo, desarrolladora, diseñadora, antropóloga, es una increíble pensadora profunda en los paradigmas de la interacción entre computadoras y humanos. Pero también es una diseñadora maravillosa y ha contribuido a tantos proyectos y tantos recursos en Internet, así como a JavaScript. Así que gracias por estar aquí, Maggie. ¿Podemos aplaudir a Maggie? ¿Puedo recibir un aplauso? ¿Oh, Steve no recibió un aplauso? ¿Podemos aplaudir también a Steve? Y finalmente, Anjana se une a nosotros desde San Francisco. Ella es realmente una polímata. Ha hecho un poco de todo, desde estudiar filosofía hasta enseñar inglés y lingüística computacional, y creo que une todas estas cosas en una visión realmente holística de la programación y está trabajando en algunos proyectos realmente emocionantes que estoy seguro de que podemos escuchar durante este panel. Gracias por estar aquí, Anjana.

Muy bien, empecemos. El tema de este panel es la superposición entre UX y desarrolladores. Y creo que la pregunta cliché que siempre escuchamos es si los diseñadores deben programar. Y realmente no necesitamos entrar en eso aquí, pero quiero plantear la pregunta opuesta. ¿Debería cada ingeniero de productos o ingeniero de front-end design y qué significa participar en ese proceso de design? ¿Quién quiere ir primero?

Quiero decir, la respuesta simple es no, los desarrolladores no tienen que convertirse en diseñadores, ¿verdad? Esa nunca es la solicitud. Por eso todos resentimos la pregunta, ¿deben los diseñadores programar? ¿Deben los desarrolladores design? Todos dicen, bueno, estoy un poco abrumado aquí con las herramientas de JavaScript. Por favor, no me hagan asumir una disciplina completamente nueva. Creo que tal vez sea más interesante convertirlo en pedirle a las personas que se pongan su sombrero de desarrollador/diseñador de manera flexible y estén muy abiertas a aprender cosas fuera de esa caja muy estricta en la que nos metemos y simplemente pensar que los desarrolladores deberían estar abiertos a aprender más sobre design y trabajar muy de cerca con los diseñadores y aprender a pensar como un diseñador en lugar de convertirse en un diseñador, lo que sea que eso signifique.

Estoy de acuerdo con eso. Veo el design como opiniones sobre cómo deberían funcionar y verse las cosas, etc. Y luego mucho proceso. Entonces, ¿cómo tomamos esas decisiones basadas en nuestros usuarios y como equipo? ¿Basado en el producto? Y luego está, como, la etapa de ejecución, construyendo cosas en Figma. Los desarrolladores no necesariamente tienen que estar en la última etapa, pero definitivamente deben ser parte de las dos primeras, ya sea teniendo opiniones sobre lo que se ve bien y lo que no y teniendo esas opiniones informadas por su práctica técnica. Y luego, sí, si hay procesos relacionados con el design, ese podría ser un lugar incluso si eres un desarrollador, un desarrollador frontend, absolutamente un lugar para que participes. Oh, oh.

¿Podemos conseguir otro micrófono? Creo que está allí. Sí. Y creo que estoy totalmente de acuerdo con lo que ya se ha dicho. Creo que también hay un aspecto del ámbito de construcción de aplicaciones web, incluso sin mencionar la infinidad de otros productos que podríamos estar construyendo, desarrollando y diseñando, que se está volviendo tan enorme que no hay forma de que una sola persona pueda abarcar todas las habilidades necesarias para tener en cuenta al construir estos sistemas complejos.

Creo que lo que realmente podemos intentar hacer mejor, y tal vez como se ha insinuado anteriormente, es colaborar realmente con personas que tienen un enfoque totalmente diferente o una perspectiva totalmente diferente sobre lo mismo que todos estamos tratando de construir. Y así, poder trabajar juntos en equipos multidisciplinarios y asegurarnos realmente de valorar esas diferencias en los antecedentes, perspectivas, áreas de enfoque y conjuntos de habilidades de los demás, y no priorizar falsamente a unos sobre otros y pensar que las habilidades que tenemos son las únicas necesarias para construir algo realmente genial.

Para construir software, creo que, ya sabes, hay algunas limitaciones naturales. Si eres un equipo de una persona, debes hacerlo todo tú mismo. Si eres un equipo de muchos, puedes especializarte un poco. Entonces, tal vez en esta cuestión de la colaboración versus la capacidad de tomar decisiones de producto de forma sincrónica en una sola cabeza, ¿dónde se produce realmente la diferencia? ¿Qué tipo de tareas de diseño o qué tipo de tareas de producto requieren que una sola persona o esa colaboración sincrónica estrecha? Y cuándo podemos dividir más las responsabilidades entre el equipo? Bueno, siento que Steve va a ser el experto en esto. Tal vez rápidamente diré mi propia opinión inicial al respecto, que sería que cuando los productos están en una etapa temprana, me refiero a esa fase realmente temprana cuando estás tratando de describir la forma de algo o definir la forma de algo, tener a alguien que pueda comprender los requisitos técnicos a un nivel muy profundo, de una manera que creo que la mayoría de los diseñadores simplemente no lo hacen. Si no has programado, no comprendes todas las pequeñas cosas en las que te puedes tropezar en las bases de datos y el código frontend, simplemente no puedes. Y ahí es donde tener a alguien que conozca íntimamente cómo programar y que haya sido capacitado en el pensamiento de diseño o UX, marca una diferencia increíble en la calidad del producto y en la capacidad de concebir lo que es posible y la forma de lo que es posible. Creo que cuando tienes un producto establecido más grande, tal vez puedas dividirte en equipos, tal vez te especialices y simplemente mantengas o desarrolles algo existente que puede que no sea tan importante, pero la definición temprana del producto, si estás en alguna agencia o empresa que lo hace, ahí es donde esos pensadores híbridos son fundamentales.

Sí. Diría que, bueno, la mayor parte del diseño, al igual que la mayor parte del desarrollo, sigue convenciones. No estás empezando desde cero cada vez. Y eso es especialmente cierto si estás diseñando para una plataforma muy opinada, como iOS o algo así. Estás siguiendo el camino. Estás copiando otras aplicaciones. Y eso es totalmente normal. Creo que las partes donde tienes que crear un diseño real, original, pueden ser realmente difíciles para los diseñadores así como para los equipos de desarrollo, donde se plantea la pregunta: bueno, ¿cómo debería sentirse esta parte muy personalizada de nuestra aplicación? No necesariamente cómo se ve, sino cómo debería ser esta interacción. ¿Cómo debería verse y sentirse nuestra calculadora de precios? Es muy difícil hacerlo solo desde, digamos, Figma y solo desde Box. Es un lugar donde quieres iterar con un desarrollador o tener un desarrollador a cargo de eso y hacer todo el enfoque híbrido. Pero, sí, cuanto más te alejas de las convenciones y las vías, más importante es la colaboración híbrida entre diseñadores y desarrolladores. Si es solo un botón y si es solo un botón en iOS, no necesitas un diseñador que programe para hacer eso. Es posible que ni siquiera necesites un diseñador. Y eso probablemente sería un buen nombre para una charla o algo así. Pero, sí, una vez que empiezas a meterte en cosas extrañas, ahí es donde importa.

Entonces, Steve, quería preguntarte tu opinión personal sobre esto porque siento que encarnas este tipo de flujo de trabajo sincrónico entre diseñador y desarrollador, ¿verdad? Como, ¿cuántas horas has pasado perfeccionando las flechas? Oh, muchas horas. ¿Y cómo es ese proceso? ¿Es pura intuición y buen gusto o hay un elemento de investigación de usuarios y un proceso de diseño más metódico?

Como dije antes, el design implica muchos procesos. ¿Cómo tomas una decisión? Si esa decisión es sobre un color, ¿verdad? Como, si alguna vez has visto trabajar a diseñadores gráficos, tienen bibliotecas de colores y material de origen. No están eligiendo su azul favorito. Es un proceso. Es mucha iteración. Hacer una flecha perfecta es lo mismo. Es solo que con todos estos problemas híbridos de design desarrollador, poder iterar y decir, como, eso no está exactamente bien, o eso es mejor, lo que sea, y trabajar hacia una solución de la misma manera que lo harías con un diseño, con un esquema de colores o con un design, un design normal Ese proceso iterativo es simplemente imposible de hacer si solo estás haciendo esto en algo como maquetas. Es realmente como, oh, bueno, esa flecha se siente mejor que la otra, o como, oh, mira lo que sucede cuando están demasiado juntas. Ese es un caso que no había considerado, y tener la capacidad de hacer esa iteración es la única forma de hacer el design para tomar esa decisión sobre si esta es la flecha perfecta o esta es la tinta perfecta.

Sí. ¿Cuánto crees que es... prometimos no hablar de herramientas. No estamos hablando de herramientas. Pero la falta total de herramientas adecuadas para desarrolladores y diseñadores. El hecho de que un diseñador no pueda iterar en Figma de manera interactiva y significativa. Siempre digo que Figma es la peor herramienta de design excepto por todas las demás. Aún no satisface nuestras necesidades como diseñadores y desarrolladores para construir productos realmente buenos. Y simplemente falta una herramienta que esté en algún punto intermedio entre Figma y React. Sí. Vi tu tweet al respecto y pensé, eso es provocativo. Creo que es muy tentador pensar que... sin criticar el sentimiento, como desearía que mi... pero realmente se trata de tener... especialmente si estás diseñando dentro de una convención o para una plataforma, cuanto más sepa esa herramienta sobre lo que estás diseñando, menos tendrás que design. Y eso es un gran problema con, por ejemplo, Figma y herramientas de design basadas en maquetas, es que estás simulando todo el tiempo. Eso es casi un problema aparte de cómo tendrías herramientas que te permitan design cualquier cosa, como una calculadora de precios interactiva, solo como ejemplo. No sé si se puede tener algo así. Como, realmente, creo que en cada producto donde esto es importante, la situación normalmente es lo suficientemente única como para que realmente necesites hacerlo en el mismo código base, casi como lo que vas a lanzar. Y me pregunto si tal vez también hay algunas lecciones que aprender en cómo pensamos como ingenieros en incorporar algunas de las convenciones de un código base particular, de un proyecto particular, como reglas de estilo particulares sobre cómo se escribe el código, convenciones particulares como, ya sabes, con la llegada de TypeScript y el tipado estático, como qué tipos de data se pasarán en nuestros programas. ¿Hay también formas en las que podemos, como community, pensar realmente de manera diferente en cómo incorporar algunas de las preguntas que, ya sabes, sabemos que un diseñador nos hará o algunas de las iteraciones, algunos de los cambios que podríamos imaginar que el equipo de design podría pedir en el futuro. ¿Hay alguna manera de ayudar a integrar eso con nuestras herramientas de código existentes para que sea más fácil para nosotros como desarrolladores ver esas posibilidades y adherirnos a esas restricciones?

a medida que se desarrollan, entendiendo que podrían cambiar. Entendiendo que de manera similar a cómo podríamos, ya sabes, ajustar nuestras reglas de linting una vez que las cosas se convierten en un problema, podríamos necesitar codificar más o menos de las design elecciones en el código de una manera que podamos avanzar fácilmente más adelante cuando las cosas cambien. Esta es la promesa de los sistemas de diseño, ¿verdad? La promesa. La promesa. Nunca funciona. Hay algunos dolores profundos detrás de eso. ¿Está este sistema de diseño en la habitación con nosotros en este momento?

Los sistemas de diseño están bien. Son buenos. Algunas personas en la habitación probablemente trabajan para empresas lo suficientemente grandes como para tener equipos extensos de sistemas de diseño. Mi sensación es que los productos pequeños a menudo se mueven lo suficientemente rápido como para que si haces un sistema de diseño demasiado temprano, termine siendo más un problema que una solución. Pero si puedes hacer que la promesa sea real, entonces es bastante efectivo en ese tipo de lenguaje compartido entre desarrolladores y diseñadores, y anticipando cambios y estilos. Como con la ingeniería en general, ya sabes, la optimización prematura siempre es un problema. Pesar ese compromiso entre cuánto tiempo pasamos asegurándonos de que las herramientas estén en el código todas nuestras suposiciones actuales versus cuánto tiempo pasamos validando realmente esas suposiciones y viendo si realmente necesitamos esas cosas que pensamos que necesitamos. Creo que es casi como volver al problema original de cómo creamos un proceso iterativo que pueda moverse tan rápido como necesitamos.

Sí, creo que, siguiendo esta especie de, siento que la conclusión lógica de esta conversación es cuál es la relación entre UX y DX, ¿verdad? Creo que a menudo son como, ya sabes, post-antítesis, ya sabes, hay mucho moralismo, ya sabes, por ejemplo, desarrolladores web que piensan que construir herramientas de DX pone al usuario en segundo lugar. Pero creo que Maggie, has sido históricamente muy crítica con la experiencia del usuario de las herramientas de desarrollo que usamos, ya sabes, por ejemplo, es completamente imposible para un diseñador que no tiene mentoría técnica ejecutar un proyecto moderno de React la mayoría de las veces. Entonces, ¿qué crees que todos en esta habitación deberían hacer para ayudar en esta colaboración? Ok. ¿Cómo puedo responder de manera breve? Por lo general, tomo la posición de que, sí, las experiencias de los desarrolladores en este momento son realmente bastante malas. No sé si se me permite decir palabrotas en el escenario, así que no lo haré, pero usaría palabras malsonantes. Quiero decir, como desarrolladores soy un mal desarrollador, pero también soy un desarrollador. Me siento mal por mí y por todos ustedes por tener que usar estas herramientas en este momento. Son fundamentalmente limitadas y no aprovechan nuestra rica y visual comprensión del mundo. Estamos todos atrapados en texto. Todo debería ser mejor. Y la pregunta es cómo elevar esa calidad. Y una forma es que los desarrolladores se interesen más en la experiencia del usuario y el diseño como disciplina. Mejorar en UX y diseño porque los diseñadores nunca construirán mejores herramientas de desarrollo. Los desarrolladores resuelven sus propios problemas con herramientas. Se vuelven locos, crean sistemas. Pero nunca se acercan con una comprensión muy sólida de la interacción y el diseño visual. Y el proceso de diseñar cosas para otra persona y hacer pruebas de usuario e iterar en eso.

Creo que la forma en que se construyen las herramientas de desarrollo actualmente no tiene mucha práctica de diseño sofisticada o matizada. Y si hubiera un grupo de diseñadores... Quiero decir, desarrolladores que se capacitaran en diseño y luego resolvieran sus propios problemas con herramientas y aplicaran el proceso de pensamiento de diseño, creo que las herramientas de DX mejorarían. Así que esa es mi estrategia actual, cómo hacer que las personas que ya tienen inclinación hacia el diseño se involucren. Como tú, que vienes del diseño en primer lugar. Pero las personas que tienen una combinación de ambas probablemente serán las que construyan las mejores herramientas de DX en el futuro.

Si puedo agregar algo, la mayoría de las herramientas de DX no están diseñadas. Y lo digo en el sentido de que no hay un proceso de diseño involucrado en la creación de esta API o lo que sea. Un proceso de diseño que se basa en la idea de que, bueno, no sé cómo debería funcionar, deberíamos involucrar a las personas y descubrirlo de esa manera. Así que diría que en la mayoría de los casos, DX es un proceso de cero a uno. Y se nota cuando es bueno. Cuando es bueno, te das cuenta de que involucraron a personas que no están en el equipo en el diseño de esta API o en el diseño de esta herramienta o flujo de trabajo. Pero también se nota cuando fue solo una persona. Y creo que muchas de las herramientas de desarrollo más exitosas o queridas provienen de esa persona, alguien que tiene buen gusto y visión, que tiene una idea original sobre algo. Y algunas de ellas terminan siendo exitosas. Pero luego están todas esas miles de otras herramientas de desarrollo, bibliotecas y paquetes y CLIs que no resultan ser tan útiles.

¿Crees que aplicar un proceso de diseño ayudaría a esos proyectos que están luchando? Bueno, si tienes algo ahí fuera el tiempo suficiente, por ejemplo, React es un gran ejemplo de una API que ha estado en el mundo el tiempo suficiente como para ser diseñada de la manera difícil, es decir, tener a personas como David gritándole al equipo: esto no funciona, deberían mejorarlo, y hay mucha interacción con la comunidad. Los nuevos proyectos, los proyectos pequeños no van a tener eso. Y sí, puedes hacer tu mejor suposición y tal vez esté bien. Pero creo que si quieres que DX sea parte del ADN de tu producto desde el principio, no debería ser algo en solitario, sin importar cuán buenas sean tus opiniones o lo que sea. Es simplemente un conjunto de datos incompleto para tomar esa decisión o esas decisiones. Y en ese sentido, creo que debemos seguir nuestro propio consejo y también preguntar a nuestros usuarios qué es lo que realmente necesitan, en lugar de pretender saber lo que quieren. Así que gracias por abrir el Slido, fue una buena señal de lectura de quien esté en la cabina.

Creo que una pregunta en la que probablemente no queramos terminar, pero en la que definitivamente debemos dedicar un poco de tiempo, es cuáles son algunas acciones concretas que los desarrolladores que intentan aprender los fundamentos de UI/UX, y que tienen dificultades con lo que esta persona llama habilidades creativas deficientes, que creo que es una descripción muy interesante y autodepreciativa. No sé si diferentes personas tienen esa gran escala de habilidades creativas, simplemente pueden aplicar la creatividad de diferentes maneras. Entonces, ¿cuáles son algunas acciones muy concretas que los desarrolladores que tienen dificultades para ingresar a esto podrían tomar? ¿Quieres intentarlo? Sí, seré breve, solo un par. Si eres alguien a quien le atrae el diseño, ¿verdad? Soy un desarrollador, me encanta el desarrollo, quiero seguir siendo desarrollador, pero hay algo aquí que quiero explorar. Diría que la mayoría de los cursos en línea pueden no ser la mejor opción, pero depende de tu situación laboral actual, pero tu carrera es larga y los desarrolladores de React son muy demandados en este momento, por lo que tienes mucho poder y ventaja en términos de qué trabajo quieres tener y cómo es la empresa. Trabajar en un lugar pequeño donde literalmente estés sentado al lado de un desarrollador, incluso si es de forma remota, trabajar en estrecha colaboración con ellos todos los días, es la mejor manera de aprender exactamente cómo piensan y trabajan los desarrolladores, y aprender a pensar como un diseñador y convertirte en uno mismo, porque puedes ser ambas cosas. Si puedes conseguir uno de esos puestos, es realmente valioso y probablemente la forma más efectiva de mejorar en el diseño.

Estoy contratando. Llámame. Sí, diría que gran parte del design es imaginar a otras personas y cómo las usarían. ¿Entonces ficción? Leería ficción. En realidad, es una recomendación seria. Pero sí, lo más probable es que cualquier equipo en el que estés tenga algún tipo de proceso de design, intenta formar parte de él. Incluso si eres una persona callada en la sala, involucrarte en ese proceso es cómo haces design.

Sí. Y me encanta eso, la sugerencia sobre la ficción, porque realmente se trata de empatizar con el usuario, ya sea que el usuario sea un usuario final, haciendo clic en botones en tu sitio web, o si es un desarrollador que construye con la herramienta en la que estás trabajando interna o externamente, creo que una de las cosas que quizás no hacemos lo suficiente como comunidad de desarrolladores es hablar y escuchar a nuestros usuarios reales en el mundo real, además de imaginar a nuestros posibles usuarios. Si tu equipo o tu empresa tiene a alguien que realiza investigaciones de usuario, serán una gran fuente de información sobre las cosas que han escuchado de los usuarios, las cosas que han descubierto. Si estás en una posición en la que asistes a conferencias y hablas con personas que han utilizado tu producto o tu herramienta, averigua cuál ha sido su experiencia y escucha realmente. Creo que tendemos a ponernos a la defensiva y justificar, bueno, así es como funciona, y si no tuviste una buena experiencia, es porque no leíste suficiente la documentación o lo que sea, intenta realmente escuchar, intenta comprender cuáles fueron esas dificultades, cuáles fueron esos momentos de alegría, y realmente escucha a las personas que experimentan la cosa que estás tratando de construir.

Y creo que cómo comenzó esta conversación también, los desarrolladores hoy en día tienen mucha influencia. Si el proceso de design en el lugar donde trabajas actualmente no se adapta a tus necesidades, si hay un proceso de entrega, si alguien te envía archivos de Photoshop, entonces hay oportunidades en otros lugares, y Steve está contratando. Así que habla con Steve. Pasemos a otra pregunta. Queríamos alejarnos de las herramientas, pero esta es la pregunta más solicitada, así que la haré de todos modos. ¿Dónde encaja la prueba de usuario en el proceso iterativo de diseñar la flecha perfecta, y qué tooling usarías para probar usuarios en un prototipo dinámico? Mi herramienta de investigación más efectiva es Twitter. Me doy cuenta de que eso no funcionará para todos, pero al menos en mi experiencia, construir algo de forma pública, reducirlo al tamaño de un código sandbox y poder enviarlo en pequeños GIF o lo que sea y solicitar opiniones de esa manera ha sido enormemente efectivo para mí. No sé cómo hacerlo para cada producto. Probablemente puedas hacerlo internamente. Nuevamente, si estás trabajando en algo que es pequeño, interactivo, no estás seguro de cómo se siente realmente bien, y ese es el norte al que estás persiguiendo, tener alguna forma para que otras personas, personas que no sean tú o el equipo en el que estás, te den comentarios lo antes posible, incluso si son malos. El producto, no los comentarios. Esa es la forma de hacerlo. Twitter. Twitter es realmente bueno para eso, para proyectos secundarios. A la gente le encantan los GIF. Genial. Pasemos a la siguiente pregunta. No nos queda mucho tiempo, pero creo que esta es buena para volver al ecosistema de React. Esta es una conferencia de React.

después de todo. Entonces, la pregunta aquí es qué recursos recomendarías para hablar el mismo lenguaje y pensar en componentes, reutilización, composición, etc. Y voy a ampliar esta pregunta preguntando, ¿este tipo de terminología que usamos como desarrolladores de React, es útil como el tipo de lenguaje de intercambio de ideas entre el desarrollo y el diseño o el desarrollo y la UX? ¿El enfoque del ecosistema de React en estos atributos particulares es realmente la mejor manera de modelar estas cosas o hay algún otro lenguaje que podríamos estar usando? Y estoy mirando intensamente a Maggie aquí porque creo que ella tendrá algo interesante que decir, pero cualquiera puede participar.

Espera, ¿entonces la pregunta es si el lenguaje que usamos para React es útil cuando te comunicas con los diseñadores? Sí, y creo que la pregunta aquí es qué recursos recomendarías para ayudar a hablar el mismo lenguaje, pero quería cuestionar la premisa de eso y decir, ¿es ese el lenguaje que deberíamos estar hablando?

Bueno, está bien, en cuanto a recursos tangibles, hay un enfoque de diseño llamado modelado conceptual o también llamado UX orientado a objetos que es realmente genial porque es esencialmente desarrollo pero disfrazado como algo para diseñadores. Y fue desarrollado originalmente en Xerox PARC en la primera interfaz gráfica donde las personas que la construyeron, no había distinción entre diseño y desarrollo. Eran lo mismo. También construían el hardware, lo cual es ridículo, pero tenían una visión unificada de cómo funcionaba esta computadora. Todo, desde la interfaz de usuario hasta el hardware, y desarrollaron este sistema de cómo diseñar software comenzando con componentes y relaciones y atributos y cosas que todos reconoceríamos como desarrolladores, cómo todos pensamos. Y se perdió en algún lugar de los años 90 y en todo el desorden, y ahora la gente está volviendo a él a través del modelado conceptual o incluso la arquitectura de la información toca mucho de esto. Pero si encuentras un diseñador que conoce esos términos, hablarán el mismo lenguaje que tú. Pueden tener diferentes palabras de moda, pero son literalmente los mismos conceptos. ¿Podrías repetir el nombre de la investigación? Oh, si buscas en Google modelado conceptual o UX orientado a objetos o OUX, encontrarás muchas cosas que te resultarán muy familiares.

Increíble. Nos han dado la señal de tiempo. Esta conversación ha sido tan profunda y estimulante que básicamente hemos excedido nuestro tiempo asignado. Por desgracia, no tenemos tiempo para más preguntas, pero hay un montón de preguntas aquí en Slido. Supongo que todos estarán en la sala de preguntas y respuestas de los oradores ahora en este descanso. Así que por favor, hagan más preguntas a nuestros panelistas a quienes queremos agradecer ahora por venir aquí. Así que gracias panelistas. Gracias Steve, gracias Maggie y gracias Anjana.