Creando un Sistema de Diseño para 1B+ Usuarios en la Era de la IA

Así que, sí, gracias por la introducción. Como él dijo, mi charla será más una historia que algo educativo pero espero tener algunas cosas educativas interesantes también. Así que sí, soy Noe Yamamoto, técnicamente mi título es ingeniero de interfaz de usuario, lo que realmente enfatiza el hecho de que me importa la UI y me ha importado durante mucho tiempo. Antes de trabajar en WhatsApp, estuve en Squarespace haciendo rendimiento web. Antes de eso ayudé a refactorizar la página web de marble.com, lo cual es muy genial para el nerd en mí. JavaScript fue el primer lenguaje de programación que aprendí y realmente sigue siendo el único que conozco bien, así que en ese sentido soy un especialista.

Pero, bueno, una rápida muestra de manos, ¿cuántas personas usan WhatsApp aquí? Levanten la mano, levanten la mano. Bien, eso es una buena cantidad. Siempre puedes ver a los estadounidenses en la multitud. Aquellos que no levantan la mano aún no han abordado ese mercado del todo. Ahora levanten la mano si han usado WhatsApp en las plataformas web o de escritorio. ¿Alguien? Eso es increíble. Eso es increíble. Bien. Levanten la mano si alguna vez se han encontrado con errores en el WhatsApp web. No, es broma, es broma, no hagan eso. Probablemente no sean culpa mía. Podrían ser culpa mía. Probablemente no sean culpa mía.

Pero sí, así es como se ve la aplicación hoy. Si vas a web.whatsapp.com, primero tendrás una pequeña página de inicio de sesión y luego serás recibido con este hermoso diseño. Bastante moderno, bastante limpio. Sabes, muchos colores y formas consistentes. Podría mejorarse, por supuesto, pero está a años luz de lo que solía ser. ¿Alguien usó WhatsApp web cuando se veía así? ¿Alguien? Oh, tenemos un par. Tenemos mucha gente en realidad. Eso es increíble. Así que creo que hay mucho que amar de este diseño. Sabes, tiene un encanto. Puedes enviar mensajes a tus contactos.

Puedes enviar imágenes a tus contactos, videos a tus contactos. Eso es todo. Eso es todo lo que realmente podías hacer. Sabes, tan simple como se pone. Incluso soportábamos todos los teléfonos más populares de la época. Tienes tu Windows phone, tienes tu BlackBerry 10, tu Nokia S60 ahí arriba.

En ese momento, en realidad usábamos una conexión directa a tu teléfono para ejecutar WhatsApp web. Tal vez aquellos de ustedes que estaban por ahí en ese entonces, recuerden que si su teléfono se apagaba o se ponía en modo avión o algo así, no podían usar la web más. Esa fue una gran queja, pero fue una de las cosas que se hizo difícil por el cifrado de extremo a extremo. Eventualmente encontramos una manera de solucionar eso.

Pero sí, esta versión temprana de la aplicación fue desarrollada y diseñada casi en su totalidad por una sola persona. Fue el mismo tipo que desarrolló la página de marketing de WhatsApp.com. Ese es un verdadero desarrollador 10X ahí mismo. Eso no fui yo. Fue antes de mi tiempo, pero súper impresionante. Para cuando WhatsApp web salió en 2015, así es como se veía esa página de inicio. Puedes ver tu Android genérico y iPhone justo ahí. Puedes ver los acentos muy azulados-verdes que usamos para todo. Muy cuadrado, muchos bordes afilados y tonos claros. Pero sigue siendo bastante bonito. Esta es una captura de pantalla un poco más tardía, cuando comenzamos a soportar más funciones como mensajes que desaparecen mensajes destacados, documentos. Esta es una captura de pantalla de 2021. Esto fue bastante poco después de que me uní. Aún puedes ver que es en gran medida el mismo diseño con el que comenzó. Las cosas son un poco más limpias, un poco más desarrolladas. Pero en términos del lenguaje de diseño real, no había cambiado realmente en absoluto. Y continuó de esta manera por un tiempo. Desde 2015 hasta 2024, WhatsApp web siguió siendo desarrollado. Las funciones seguían siendo lanzadas. La base de código seguía creciendo.

Todo con el mismo lenguaje de diseño heredado que recibimos de la primera versión de esta aplicación. Tienes tus bordes afilados, tu contenido cuadrado. Muy Android 5, muy teléfono Nokia, cosas de la web muy, muy tempranas. Pero con ese diseño, hicimos mucho. Teníamos más de 200 millones de usuarios en ese momento. Si hubieras mirado cualquiera de los rankings, WhatsApp web estaba entre los 10 mejores sitios web del mundo.

Pero a la escala en la que opera WhatsApp, eso sigue siendo en realidad una de las plataformas más pequeñas. Éramos en ese momento más grandes que iOS. iOS nos ha superado mucho. Pero debido a eso, teníamos aproximadamente una quinta parte de los ingenieros que tenían los clientes móviles. Y ni un solo diseñador dedicado durante todo ese tiempo. A pesar de eso, logramos aún así lograr mucho. Incluso teníamos modo oscuro, que es una de mis cosas favoritas.

No me gusta quedar cegado por mi laptop cuando solo quiero enviar algunos mensajes. Hubo muchas mejoras que se harían a la aplicación, solo como proyectos paralelos, más o menos, por ingenieros apasionados. Este es uno de mis favoritos. Este es el command palette. Levante la mano, ¿alguien ha usado este command palette en WhatsApp web? Está bien. Eso es como 1/100 de las personas que levantaron la mano antes, lo cual no les culpo, porque no fue muy bien publicitado.

Pero este es un ejemplo de algunas de las características que existían solo por la pasión de algunos de los ingenieros que trabajaban en la aplicación. Aún puedes usarlo hoy, por cierto. Command K. Alt K. Buscará cosas mucho más rápido para esos aficionados al teclado en la multitud. Pero sí, a pesar de esta falta de recursos, hicimos nuestro mejor esfuerzo para mantener la paridad de características con el móvil. Pero como no teníamos un diseñador dedicado, básicamente se nos asignaba, aquí está un diseño móvil, haz que suceda en la web.

Y en lo que se convirtió eso es en lo que me gusta llamar un sistema de diseño basado en cajones. Muchos de ustedes ya podrían estar al tanto de esto, pero muchas de nuestras características eran esencialmente solo tomar una pantalla móvil, lanzarla en un cajón. Voila, tienes WhatsApp web. Aquí hay otro ejemplo de eso, donde en mi opinión, el diseño no se traduce súper bien. Puedo decir eso porque soy quien ideó esa pantalla. No es mi mejor trabajo.

Pero sí, dado que operábamos con plazos ajustados, los ingenieros no tenían el tiempo o la confianza para rechazar diseños que no se ajustaban a la web. Así que si un modelo de característica que estábamos implementando tenía un botón con un radio de borde ligeramente cambiado o lo que sea, en lugar de simplemente usar el que teníamos, diseñaríamos uno completamente nuevo porque tenía que ajustarse al modelo de diseño que el móvil nos dio. Pero a medida que la aplicación creció, se volvió más difícil mantener el mismo lenguaje de diseño con consistencia, especialmente a medida que comenzamos a implementar muchas más características.

Las cosas obvias se arreglarían. Usábamos la aplicación todos los días como ingenieros, así que arreglábamos las cosas que nos molestaban. Pero cuando miras una pantalla durante toda tu carrera profesional, muchas cosas te vuelves ciego a ellas. Así que echa un vistazo a esta captura de pantalla básica de una versión de desarrollo de WhatsApp web a mediados de 2022. A primera vista, parece bien, ¿verdad? Sabes, tiene lo que necesitas. Estás viendo una vista de comunidad aquí con un cajón de grupos gestionados abierto, pero los ojos más agudos en diseño entre nosotros pueden ser capaces de detectar algunas inconsistencias aquí.

¿Alguien quiere simplemente gritar algo que no le guste de este diseño? ¿Alguien quiere ser valiente? Escuché algo en el fondo, pero no lo escuché. Colores. Sí, exactamente. Sabes, tienes tantos tipos diferentes de tonos aquí. ¿Cuántos verdes tienes? Vamos a ver. Tienes un verde, dos verdes, tres verdes, cuatro verdes, cinco verdes. Diferentes grises. Miremos las líneas divisorias. ¿Qué está pasando con eso? ¿Cómo es que estos grupos no tienen una línea divisoria? Estos grupos sí. Este encabezado de sección es gris y no está en mayúsculas. Este es verde y en mayúsculas por alguna razón. Estos son botones.

¿Qué está pasando con el tamaño de este ícono? ¿Por qué es tan pequeño? Pero ese de allá es grande. ¿Qué es clicable aquí? ¿Es obvio solo con mirar? Eso es en realidad un elemento interactivo de esta página. Hablemos de accesibilidad. Esto es una especie de pesadilla. ¿Cómo navegas por esta pantalla desde una perspectiva de teclado? Podría seguir. Hay muchas cosas. Sabes, no hay borde aquí entre la lista de chats y el cajón, pero hay uno aquí. Así que esto es lo que obtienes cuando tienes diseños que se construyen a lo largo de los años por los mismos ingenieros.

Avancemos unos años, y en 2024, móvil estaba planeando una gran renovación de UI. Iban a crear un nuevo lenguaje de diseño, nuevos colores, espaciado consistente y forma, iconos renovados, incluso algunos cambios estructurales mayores como una nueva barra de navegación, bandeja de adjuntos, características de gestión de chats como filtros. A lo largo de un año, actualizaron la aplicación para que fuera mucho más moderna. Pasaron de este tipo de diseño que teníamos en gran medida en la web a algo que se asemejaba mucho más al siglo XX. Pasaron de eso a eso en un año.

Mientras tanto... 21st. Mientras tanto, ¿qué pasa con la web? No obtiene exactamente esos beneficios todavía. Afortunadamente, sin embargo, conseguimos que nuestro diseñador, que estaba súper apasionado por la web, levantara la mano unos meses después de que se lanzara la renovación móvil para hacerlo en la web. Así que puedes ver en esta diapositiva de propuesta inicial muchos de los mismos puntos que discutí siendo planteados.

Nuestra renovación se centró principalmente en traer el nuevo sistema de colores e iconos, pero también realizamos algunos rediseños estructurales. Esto incluyó mover la barra superior al lado. Ahora dándonos mucho más espacio para otros iconos y una nueva jerarquía de navegación. Y actualizamos el cuadro de redacción. Este en el que trabajé fue bastante divertido para hacer las animaciones y cosas así. Así que sí, después de seis meses de arduo trabajo, terminamos. La aplicación finalmente parecía algo de la década actual. Coincidía con el nuevo diseño de móvil, y logramos terminar a tiempo.

Queríamos ir más allá. El primer paso fue configurar un experimento AV. Ver cómo realmente les gustaba a los usuarios. Pasaron un par de meses, y aumentaron ligeramente los bloqueos. Eso fue principalmente el único beneficio de compromiso que pudimos ver. Cambio de métrica. Pero al menos recibimos algunos tweets agradables al respecto. Así que eso fue agradable. En la superficie, la aplicación se veía mucho más brillante y mejor que antes. La línea de tiempo rápida y el requisito de soportar ambas versiones de la aplicación por un tiempo significaron que la base de código de UI estaba en una forma difícil.

Para refrescar componentes existentes sin romper los antiguos, estábamos trabajando en nuevos trabajos de pintura para componentes existentes, bifurcando rutas de renderizado por todas partes. Este es uno de mis logros más orgullosos.

No, esto es lo que parecen los tipos de elementos de lista. No sé cuántos de ustedes han operado en bases de código heredadas antes, podrían haber visto este patrón. Estos son todos los diferentes temas que un solo componente soporta. Y esto es lo que obtienes cuando a lo largo de los años se agregan y agregan nuevas características sin que nadie se detenga y diga, espera, ¿qué está pasando con nuestro sistema de componentes de UI? Súper idiomático y comprobable, ¿verdad? Estoy seguro de que eso no tendrá errores en absoluto.

Ahora, al mismo tiempo, en otra parte de la empresa, se creó un equipo para resolver el mismo problema en móvil, se llamaba WDS. Y estaban haciendo un gran trabajo. Desafortunadamente, se centraron en móvil, no tenían los recursos para incorporar web. Pero pasa algún tiempo así y esta cosa rara llamada AI comienza a hacerse popular. No sé si alguien ha oído hablar de eso aquí. No es súper grande. Pero a principios de 2025, comenzó a hacerse popular asegurar que tu base de código estuviera lista para AI. Todos están hablando de lo que significaba estar listo para AI y cómo llegar allí. Estaba en un equipo que estaba evaluando el rendimiento de AI en nuestra base de código y cómo podíamos mejorarlo. Y una de las cosas que constantemente veíamos es que al crear UI, simplemente continuaba estos viejos patrones heredados, simplemente seguía iterando sobre componentes existentes, seguía parcheando cosas, seguía usando los componentes incorrectos en ciertos lugares. A veces creaba un componente completamente nuevo porque simplemente no podía encontrar el correcto. Y sí, esto solo empeoraba los problemas. AI repite patrones y si tus patrones son pobres, su salida será pobre también.

Entonces, generalmente, lo que se supone que debes hacer en casos como este es enseñarle. Se supone que debes darle archivos de contexto explícitos y decir, oye, AI, aquí está mi sistema de diseño, aquí están los componentes que usas para cada cosa, esto es lo que podría parecer una habilidad de ejemplo que podría invocar al escribir UI. Esto no es nuestro, solo algo que harías. Pero en nuestro caso, realmente no teníamos un conjunto de componentes de primera clase que pudiéramos decirle a AI que usara, ¿verdad? Si intentáramos hacer algo como esto, sería como un completo espagueti, ya sabes, usa este tipo en este caso, a menos que este no sea el caso y luego usa este otro. No sería realmente sostenible. Así que fue con este contexto y con esta energía que pude argumentar para llevar WDS a la web. Así que los sistemas de diseño son una historia de aceleración de AI. Eso es algo que recordar si estás tratando de luchar por ancho de banda y financiamiento para tus cosas. Es fundamental para crear una buena UI. Necesitas tener un sistema de diseño establecido. Tener un conjunto limpio y consistente de componentes y tokens para coincidir con todo tipo de características hace que el desarrollo sea más fácil también para los humanos. Y así nació WDS. Contratamos a un gran diseñador, escribimos una carta de equipo, creamos una nueva biblioteca de Figma y nos lanzamos a la carrera.

¿Por dónde empezar? Sabes, he escrito mucho UI en mi vida, pero nunca había escrito un sistema de diseño antes. Realmente no sabía qué hacer. Así que leí. Leí muchas cosas. Esto es solo una rápida muestra de capturas de pantalla de diferentes recursos que me gustaron. El que mencionaré aquí es la guía de prácticas de autoría de área. Si eres un poco nuevo en la creación de componentes accesibles y estás confundido sobre por dónde empezar, WDS tiene buenos recursos, pero W3C tiene su propia página de documentación que es realmente increíble. Tiene muchos buenos ejemplos de diferentes componentes y cómo hacerlos accesibles para usuarios de lectores de pantalla, para usuarios de teclado. Súper súper interesante e importante. Pero sí, ¿por dónde empezar? El primer lugar que elegimos abordar fue solidificar un sistema de tokens. Así que creamos variables para color, para forma, para espaciado, y definimos una rampa de tipos y construimos componentes de texto para que toda la aplicación pudiera tener un tamaño de fuente consistente, kerning, altura de línea, etcétera. Luego comenzamos el trabajo de componentes. Para subvertir la expectativa, no construimos el botón primero. Construimos el interruptor primero. Luego construimos el botón. Priorizamos combinando esencialmente la matriz de más divergente y más usado, porque queríamos priorizar de tal manera que los usuarios pudieran obtener un valor inmediato de ello. En un momento, teníamos tanto entusiasmo alrededor del proyecto que otros ingenieros se acercaban y preguntaban cómo podían ayudar.

Y eso es algo muy impresionante, pero también puede ser algo muy peligroso, porque si un desarrollador no tiene todo este contexto sobre cómo hacer componentes limpios, bien probados y accesibles, puedes terminar en una situación que no es mucho mejor que donde comenzaste. Así que hicimos mucho para asegurarnos de que tuvieran la orientación correcta sobre cómo hacer eso, pero pudimos obtener un montón de contribuciones de componentes. Lo llamamos un Contributhathon. Después de construir un componente, rastrearíamos cada versión heredada de este en la base de código y agregaríamos una regla de lint en contra de su uso. Obviamente, no tenía la capacidad yo mismo para migrar cada instancia, pero al agregar una regla de lint, podía estar razonablemente seguro de que con el tiempo el uso de componentes heredados disminuiría, y el uso adecuado de componentes WS aumentaría. No es raro que los ingenieros tratando de cumplir con una fecha límite intenten hacer pequeños ajustes a tu componente para que se adapten a su caso de uso. Pero como ingeniero de diseño en una gran empresa, tienes que ser un poco defensivo. Esto es algo que aprendí. No puedes decir sí a todos. Tienes que tomar una posición y saber que tienes la autoridad para decir no a ciertos diseños y decir sí a otros. Hasta cierto punto, tienes que ser un árbitro de eso como ingeniero de sistemas de diseño.

Pero sí, avanzando rápido hasta hoy, más de un año después, y WS es una biblioteca madura que sirve a la gran mayoría de los servicios en la aplicación, utilizada en más del 60% de los archivos frontend. El viaje solo está al 1% terminado. Todavía hay grandes componentes que nos gustaría construir, como el elemento de lista. Aún no hemos abordado eso, pero emocionémonos por ello. Y patrones de UI que nos gustaría reexaminar. Todavía nos gustaría refactorizar muchas cosas para alejarnos de ese sistema de diseño basado en cajones y realmente utilizar la gran pantalla que tenemos. Comenzamos a hacer eso. Tal vez algunos de ustedes hayan usado el nuevo centro de medios que tenemos en la aplicación donde pueden ver todos los medios que han enviado a través de toda la aplicación. Ese es un ejemplo de eso. Pero sí, estoy súper feliz con lo que hemos podido lograr. Y para cerrar, sí, cuidado con la muerte por mil pequeños ajustes cuando tienes una base de código tan grande y tan antigua como la nuestra. Si no hay alguien manteniendo el estándar de calidad, la calidad no existirá. Todos quieren una base de código más limpia. Solo muéstrales cómo llegar allí, ¿sabes? Muchas personas saben que la situación de la base de código no es excelente, pero están presionadas para hacer características. Están presionadas para entregar cosas en una fecha límite. No necesariamente tienen el tiempo para ir y reexaminar todas estas cosas. No tengas miedo de aplicar tu sistema de diseño. Las reglas de lint escalan mejor que los posts de lanzamiento. Y recuerda la historia de AI.

Hereda tu patrón, así que haz que valga la pena heredarlo.

Y sí, eso es todo lo que tenía. Así que gracias. Genial.

¿Crees que es posible desarrollar un sistema de diseño desde abajo hacia arriba y con crecimiento comunitario cuando hay una falta de gobernanza dentro de una empresa? Es más administrativo. Sí. Sí. Creo que esa es una muy buena pregunta. Mucho de lo que he aprendido en este proceso es sobre el tema administrativo. ¿Cómo navegas dentro de una organización enorme? En cuanto a la pregunta de si es posible, creo que sí lo es. Creo que tienes que tener suficiente influencia, sin embargo. Tienes que estar en una posición donde la gente respete tu opinión de diseño y tu comprensión de la base de código. Y es un poco una cuerda floja para navegar porque no quieres ser visto como el líder técnico excesivamente estricto que no deja pasar nada a menos que pase su barra súper alta. Pero creo que tienes que tener algo de eso. Sí. Genial. Bien. Gracias.

Entonces, otro es hacer que la UI esté lista para AI. Entonces, cuando mencionabas que estabas trabajando con algún tipo de límites allí o tratando de hacerlo funcionar, también vi una habilidad allí. Tal vez puedas hablar un poco sobre eso. Sí. Sí. Tengo mucho que decir sobre esto. Creo que es un tema realmente grande. Creo que fundamentalmente tener un archivo de contexto, una habilidad o incluso una regla que el LLM pueda leer que sea siempre vigente, que esté actualizada sobre lo que tiene tu sistema de diseño, creo que es realmente importante. Estoy anticipado con el uso de una especie de herramienta MCP o una herramienta CLI que la AI pueda preguntar. Así que puede decir algo como, oye, quiero construir un botón y es verde. ¿Cuáles son mis opciones? Y la salida será usar este componente exacto con estos tipos exactos. Y aquí está la lista de props dependiendo de lo que estés tratando de hacer.

Así que creo que cuanto más puedas hablar AI de manera nativa, mejor resultado tendrás. Y la otra cosa sobre eso es la verificación de UI. No entraré en eso aquí, pero asegúrate de que tu agente pueda ver la aplicación en la que está trabajando.

Sí, genial. Bien. Entonces, en el mismo espacio de AI, ¿hay algo sobre MCP con lo que te integres o? Sí, creo que ya respondí eso. Tenemos algunas herramientas que las AIs pueden usar para eso. Creo que son principalmente archivos de contexto, realmente. Y luego, como entender esos archivos de contexto en términos de características y herramientas más ricas, sería la verificación de UI.

También hay una etapa de revisión donde tenemos como un revisor de diseño que se activará cada vez que llegue un PR que afecte a la UI. Y lo juzgará en base a los criterios que le dimos. Así que. Genial.

Y para el equipo del sistema de diseño, ¿hay como un equipo dedicado para eso o hay algún tipo de propiedad compartida entre los equipos? ¿También como organizacional? Sí, creo que va a depender de tu organización. Obviamente, siendo un ingeniero de sistemas de diseño, me gustaría un equipo. Sabes, creo que si tienes un equipo que puede ocuparse de estas cosas a tiempo completo, especialmente con un diseñador, ese va a ser el mejor resultado. Pero no siempre tienes el financiamiento para eso. No siempre tienes el alcance para eso. Y en esos casos, todavía creo que vale la pena construir un sistema de diseño y abogar por él. Incluso si son solo un par de proyectos paralelos de ingenieros, sabes, eso todavía va a ser mucho mejor que la situación en la que estábamos antes.

Genial. Bien. Sí. Así que también en el aspecto organizacional, quiero decir, estabas hablando de reglas de Lint y cómo hacer cumplir que la gente use estos sistemas de diseño. Alguien estaba preguntando cuáles son las hojas de ruta de deprecación. Entonces, ¿cómo lidias realmente con eso cuando quieres eliminar el antiguo y adoptar el nuevo? ¿Tienes realmente algo que sean directrices sobre eso? Sí, esa es una buena pregunta. He cometido errores aquí. Primero comencé con un error y luego hice que mucha gente se molestara conmigo porque introduje miles de nuevos errores en nuestra base de código. Así que no hagas eso. Definitivamente deberías comenzar con una advertencia. Y si tienes el tiempo, deberías dedicar el esfuerzo para migrar tanto de la base de código como puedas tú mismo. Ahora, eso no siempre va a ser posible, pero esa es obviamente la mejor situación. A partir de ahí, creo que los plazos exactos van a depender de la velocidad a la que trabaje tu equipo, cuánto tiempo tienes para objetivos de ingeniería mejores, cosas así. Pero sí, sí. Puedo ver cómo eso puede ser el caso.

Entonces, cuando tienes la estrategia de migración, así que este primer punto allí, eso es principalmente sobre las reglas de Lint. ¿O tienes también otras piezas de la migración? Sí, no es tan simple, porque muchas veces los nuevos componentes de diseño se verán diferentes a los antiguos componentes de diseño. Correcto. Como, eso es lo que lo hace difícil. En teoría, podrías simplemente ir y modificar todo el código y tener todo migrado desde el primer día. Pero cuando la funcionalidad difiere entre lo que el antiguo componente sobrecargado soporta y lo que tu nuevo soporta, necesitas un humano en el proceso para ir y decir, OK, necesitamos hacer este cambio en nuestro diseño, lo cual a menudo, dependiendo del futuro, requiere algunas aprobaciones dependiendo de tu organización. Así que sí, depende, es la respuesta. Sí.

Sí. Creo que cuando estás trabajando con un equipo grande, entonces puedes tener muchas cosas diferentes que son muchos enfoques diferentes y muchas maneras diferentes de lidiar con eso para el enfoque de prueba. Así que este se trata principalmente de accesibilidad. Pero sí, tal vez también el enfoque general de pruebas. Sí. Sí. Sí. Muy enfocado en las pruebas, especialmente para los componentes del sistema de diseño. Usamos Wave. Tendremos muchas pruebas, más o menos pruebas de captura de pantalla, todo ese tipo de cosas para tratar de hacer cumplir eso. También tuvimos la suerte durante un par de años, durante un par de años de tener una persona dedicada a la accesibilidad QA que es realmente genial. Estaba trabajando con nosotros, cada componente que enviamos para asegurarse de que cumpliera con su estándar realmente alto. Y él es quien me enseñó mucho sobre el tipo de cosas de W3C. Pero sí, sé de qué trata esta charla, pero la accesibilidad es extremadamente importante, especialmente para los sistemas de diseño.

Genial. Creo que eso es todo el tiempo que tenemos para hoy. Pero sí, muchas gracias a Noah. Denle un aplauso a Noah. Gracias.