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 cosas educativas interesantes allí 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 marvel.com, lo cual es muy genial para el nerd que hay en mí. JavaScript fue el primer lenguaje de programación que aprendí y realmente sigue siendo el único que conozco bien, así que en cierto sentido soy un especialista.

Pero, está bien. 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, todavía no hemos 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. Ahora 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 son culpa mía. Podrían ser culpa mía.

Probablemente no son 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, ya sabes, muchos colores y formas consistentes. Podría mejorarse aún, por supuesto, pero está a años luz de cómo solía verse.

¿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 puede.

Incluso soportamos todos los teléfonos de moda 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 poder 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. Finalmente 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 persona. Fue el mismo tipo que desarrolló la página de marketing de WhatsApp.com. Ese es un verdadero desarrollador 10X. Ese no era 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 azul verdosos que usamos para todo. Muy cuadrado, muchas esquinas afiladas y tonos claros. Pero sabes, todavía es 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 pronto 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 características seguían siendo lanzadas. La base de código seguía creciendo.

Todo con el mismo lenguaje de diseño heredado que heredamos de la primera versión de esta aplicación. Tienes tus bordes afilados, tu contenido cuadrado, muy Android 5, muy teléfono Nokia, ya sabes, cosas de la web temprana, temprana. Pero con ese diseño, hicimos mucho. Teníamos más de 200 millones de usuarios en ese momento. Si mirabas cualquiera de los rankings, WhatsApp web estaba entre los 10 sitios web principales del mundo. Pero a la escala en la que opera WhatsApp, eso sigue siendo en realidad una de las plataformas más pequeñas. En un momento éramos más grandes que iOS. iOS desde entonces nos ha superado. 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 el 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. Esta es la paleta de comandos. Levante la mano, ¿alguien ha usado esta paleta de comandos en WhatsApp web? Bien. Eso es como una centésima parte de las personas que levantaron la mano antes. Lo cual no te culpo, porque no fue muy bien publicitado. Pero este es un ejemplo de, ya sabes, 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. Comando K, Alt K. Buscará cosas, ya sabes, 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 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í, como estábamos operando 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 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, ya sabes? Usábamos la aplicación todos los días como ingenieros, así que arreglaríamos 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 compilación de desarrollo de WhatsApp web a mediados de 2022. A primera vista, se ve 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 de diseño más agudos entre nosotros pueden ser capaces de detectar algunas inconsistencias aquí. ¿Alguien quiere simplemente gritar algo que no le guste de este diseño? Si alguien quiere ser valiente.

Escuché algo en la parte de atrás, pero no lo escuché. Colores. Sí, exactamente. Sabes, tienes tantos tipos diferentes de tonos aquí. ¿Cuántos verdes tienes? Veamos. 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é pasa 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 qué es realmente un elemento interactivo de esta página? Hablemos de accesibilidad. Esto es una especie de pesadilla. ¿Cómo navegas esta pantalla desde una perspectiva de teclado? Podría seguir. Hay muchas cosas. 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 construidos a lo largo de los años por los mismos ingenieros.

Avancemos unos años, y en 2024, móvil estaba planeando una gran actualización de UI. Iban a idear un nuevo lenguaje de diseño, nuevos colores, espaciado y forma consistentes, íconos renovados, incluso algunos cambios estructurales más grandes 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 ser mucho más moderna. Pasaron de, ya sabes, este tipo de diseño que teníamos en gran medida en la web a algo que se asemejaba mucho más al siglo 20. Pasaron de, sí, eso a eso en un año. Mientras tanto... 21. Mientras tanto, WhatsApp Web no obtiene exactamente esos beneficios todavía. Nosotros, afortunadamente, sin embargo, conseguimos a nuestro único diseñador que estaba súper apasionado por la web y levantó su mano unos meses después de que se lanzara la actualizació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 actualización se centró principalmente en traer el nuevo sistema de colores e íconos, pero también implementamos algunos rediseños estructurales. Esto incluyó mover la barra superior al lado, ahora dándonos mucho más espacio para otros íconos y una nueva jerarquía de navegación.

Y actualizamos el cuadro de redacción. Este, en el que trabajé, fue bastante divertido 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 móvil y logramos terminar a tiempo. Queríamos ir más allá. El primer paso fue configurar un experimento AV, ya sabes, ver cómo les gustaba realmente 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.

Bueno, 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 significaban que la base de código de la UI estaba en mal estado. Para actualizar los componentes existentes sin romper los antiguos, estábamos improvisando nuevos trabajos de pintura a los componentes existentes, bifurcando rutas de renderizado por todas partes. Este es uno de mis logros más orgullosos. Así es como se ven los tipos de elementos de lista. No sé cuántos de ustedes han trabajado 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 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á ningún error. 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 la web. Pero pasa un tiempo así, y esta cosa extraña 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 hablaban 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 podemos mejorarlo. Y una de las cosas que constantemente veíamos era 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 también será pobre. Así que 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 decirle, 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. Realmente no sería 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. Pero 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 también facilita el desarrollo para los humanos. Y así nació WDS. Contratamos a un gran diseñador, redactamos una carta del equipo, creamos una nueva biblioteca de Figma y nos lanzamos a la carrera.

¿Por dónde empezar? 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 difusión 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, 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 fuente. Mezclamos componentes para que toda la aplicación pudiera tener un tamaño de fuente consistente, interletraje, altura de línea, etc. 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 lo más divergente y lo más utilizado. Porque queríamos priorizar de tal manera que los usuarios pudieran obtener un valor inmediato de ello. En un momento tuvimos tanto entusiasmo alrededor del proyecto que otros ingenieros se acercaban y preguntaban cómo podían ayudar.

Y eso es algo muy increíble, 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, 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 hacerlo. Pudimos obtener un montón de contribuciones de componentes, lo llamamos un Contributhathon.

Después de construir un componente, buscábamos cada versión heredada de este en el código base y añadíamos una regla de lint en contra de su uso. Obviamente, no tenía la capacidad yo mismo para migrar cada instancia, pero al añadir una regla de lint, podía estar razonablemente seguro de que con el tiempo, el uso del componente heredado disminuiría, y el uso del componente WS adecuado aumentaría. No es raro que los ingenieros que intentan cumplir con una fecha límite intenten hacer pequeños ajustes a tu componente para que se adapte 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.

Avanzando hasta hoy, más de un año después, y WS es una biblioteca madura que sirve a la gran mayoría de 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 ese, 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. Hemos comenzado a hacer eso.

Quizás algunos de ustedes han utilizado 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 muy contento con lo que pudimos 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í. 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 hacer cumplir tu sistema de diseño. Las reglas de Lynch escalan mejor que las publicaciones de lanzamiento, y recuerda la historia de la IA. Hereda tus patrones, así que haz que valga la pena heredarlos. Y sí, eso es todo lo que tenía. Así que gracias. Genial. Esto, uh, ¿crees que es posible desarrollar un sistema de diseño de abajo hacia arriba y cultivado por la comunidad 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 el tema administrativo. ¿Cómo navegas dentro de una organización enorme? 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 tienes que tener algo de eso, creo. Sí, genial. Bien, gracias. Entonces, otro es hacer que la UI esté lista para la IA. Entonces, cuando mencionabas que estás trabajando con algún tipo de barandillas allí o tratando de hacerlo funcionar, también vi una habilidad allí. ¿Quizás puedes 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 perenne, que esté actualizada sobre lo que tiene tu sistema de diseño, creo que es realmente importante. Estoy interesado en usar una especie de herramienta MCP o una herramienta CLI que la IA pueda preguntar. Así que puede decir, como, oye, quiero construir un botón y es verde. ¿Cuáles son mis opciones? Y la salida será, usa este componente exacto con estos tipos exactos, y aquí está la lista de propiedades dependiendo de lo que estás tratando de hacer. Así que creo que cuanto más puedas hablar nativamente con la IA, 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 IA aquí, ¿hay algo sobre MCP? ¿Te integras con eso? Sí, creo que acabo de responder eso. Tenemos algunas herramientas que las IAs pueden usar para eso. Creo que son principalmente solo archivos de contexto, realmente, y luego 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 verificación de etapa de revisión, donde tenemos como un revisor de diseño que será generado cada vez que llega un PR que afecta la UI, y lo juzgará en base a los criterios que le dimos. 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 equipos? También como organizacionalmente? Sí, creo que va a depender de tu organización. Yo, obviamente, siendo un ingeniero de sistemas de diseño, me gustaría un equipo. Creo que si tienes un equipo que pueda ocuparse de estas cosas a tiempo completo, especialmente con un diseñador, ese 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. Eso seguirá siendo mucho mejor que la situación en la que estábamos antes. Genial.

Sí. Así que también un poco 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 alguna guía 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. Creo que los plazos exactos van a depender de la velocidad a la que trabaje tu equipo, cuánto tiempo tienes para mejores objetivos de ingeniería, cosas así. Pero sí, puedo ver cómo eso puede ser el caso.

Entonces, cuando tienes la estrategia de migración, entonces esta primera parte, eso es principalmente sobre las reglas de lint o ¿tienes también otras piezas de la migración? No es tan simple porque muchas veces los nuevos componentes de diseño se verán diferentes a los antiguos componentes de diseño, ¿verdad? Eso es lo que lo hace difícil. En teoría, podrías simplemente ir y hacer un code mod de todo 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, está bien, necesitamos hacer este cambio en nuestro diseño, lo cual a menudo, dependiendo de la característica, requiere algunas aprobaciones, dependiendo de la organización. Así que sí, depende es la respuesta.

Sí, creo que cuando trabajas con un gran equipo, entonces tienes muchas cosas diferentes que son muchos enfoques diferentes y muchas maneras diferentes de lidiar con eso. Para el enfoque de prueba, este se trata principalmente de accesibilidad, pero sí, tal vez también el enfoque general de prueba. Sí, sí, muy enfocado en las pruebas, especialmente para componentes de sistemas de diseño. Usamos Wave. Tendremos muchas pruebas e2e, 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 de tener una persona dedicada a QA de accesibilidad que es realmente genial. Estaba trabajando con nosotros en cada componente que lanzábamos para asegurarse de que cumpliera con su alto estándar, y él es quien me enseñó mucho sobre las cosas de W3C, pero sí, sé que no es de lo que trata esta charla, pero la accesibilidad es enormemente 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. Un aplauso para Noah. Gracias.