Experiencia de UX consistente a gran escala: Lecciones aprendidas cuando llevé el sombrero de DesignOps

Rate this content
Bookmark

La necesidad de Sistemas de Diseño viene con la necesidad de escala, eficiencia y consistencia en el diseño. Estos han sido uno de los principales puntos de discusión en la comunidad de diseño y desarrollo front-end en los últimos años. Algunos lo aman; otros son más escépticos. En esta sesión, estoy recopilando los denominadores comunes que he notado mientras trabajaba en Sistemas de Diseño en empresas pequeñas, medianas y grandes, con un enfoque en puntos como la consistencia, la capacidad de personalización, la accesibilidad, el camino para convertir los diseños en código real y su adopción.


31 min
02 Dec, 2022

Video Summary and Transcription

La charla de hoy aborda los desafíos de implementar accesibilidad en los sistemas de diseño y la importancia de utilizar bibliotecas existentes. También enfatiza el uso de tokens de diseño y generación de código para garantizar la consistencia en diferentes bases de código. La charla explora la automatización, los webhooks y la seguridad de tipos en los sistemas de diseño, así como la importancia de medir la adopción y construir accesibilidad. Por último, sugiere establecer un equipo de DesignOps para fomentar la colaboración entre diseñadores y desarrolladores.

Available in English

1. Introducción

Short description:

Hola a todos, bienvenidos aquí. Hoy vamos a hablar sobre una experiencia de usuario consistente y cómo escalar eso, y las lecciones aprendidas que funcionaron en diferentes escalas de productos y empresas. Soy Mateus Obkerke. Puedes encontrarme en todas partes como YT Combinator, incluyendo en Twitter.

Hola a todos, bienvenidos aquí. Personalmente, me parece genial estar aquí, de vuelta en todas estas conferencias. Lo extrañé mucho, especialmente React Berlin.

Como probablemente saben, hoy vamos a estar aquí, hablando sobre una experiencia de usuario consistente y cómo escalar eso y las lecciones aprendidas que funcionaron en diferentes escalas de productos y empresas. Soy Mateus Obkerke. Puedes encontrarme en todas partes como YT Combinator, incluyendo en Twitter. Trabajo en Medaglia y también soy voluntario en TechLabs Berlin.

Básicamente, estamos guiando a las personas, enseñando programación y esas cosas. Todos los enlaces para esta sesión están disponibles aquí, así que si escanean el código QR, todo está aquí, incluyendo redes y cosas así. Tengo un descargo de responsabilidad. Hay muchos temas interesantes que tenemos que abordar en media hora. Así que, si algo parece que merece una discusión más profunda, no dudes en contactarme. Durante la conferencia, en la fiesta posterior, todo.

2. Introducción a los Desafíos del Sistema de Diseño

Short description:

Hoy, voy a hablar sobre tres temas: accesibilidad, el proceso de entrega de un sistema de diseño y comprender la adopción de tu sistema de diseño dentro de tu empresa.

Me gustaría comenzar con una pregunta. ¿Cuántos de ustedes han trabajado en un sistema de diseño? Ya sea como ingeniero, desarrollador o diseñador. ¡Genial! ¡Muchos levantadores de manos! Entonces, saben que definitivamente no es algo fácil, no es un sistema trivial. Construir y escalar eso. Por eso estoy aquí hoy. Estoy aquí para hablar sobre algunos desafíos. Algunos resultados de muchas personas trabajando juntas. Los denominadores comunes, como mencioné, que funcionaron en diferentes empresas, etc. También se trata mucho de moverse a lo largo del espectro del diseño e ingeniería. Entonces, se trata mucho de escuchar a los diseñadores, recopilar sus comentarios sobre el proceso y ese tipo de cosas. Porque no tenemos una hora o horas para discutir, tenemos que enfocarnos en algo. Entonces, hoy voy a hablar sobre estos tres temas. Accesibilidad, el proceso de entrega de un sistema de diseño y comprender un poco sobre la adopción de tu sistema de diseño dentro de tu empresa. Y luego vamos a sacar algunas conclusiones sobre eso.

3. Accesibilidad y Elección de Bibliotecas

Short description:

La accesibilidad es complicada de implementar. Las interacciones de presión requieren manejar varios escenarios y normalizar las inconsistencias entre navegadores. La implementación de área en los navegadores puede ser desafiante. En lugar de gastar tiempo en detalles de implementación, se recomienda utilizar bibliotecas existentes que proporcionen accesibilidad de forma predeterminada. Estas bibliotecas se dividen en tres capas de abstracción: primitivas de composición, componentes sin estilo y componentes completamente estilizados. La elección depende del contexto y la necesidad de personalización.

Entonces, comenzando con la accesibilidad, algo de lo que finalmente estamos hablando mucho en estos días. No sé ustedes, pero siempre he tenido esta reacción de que siempre pensamos, tendemos a pensar que estamos abordando suficientemente la accesibilidad. Pero luego, de repente, comenzamos a recibir, no sé, algunos tickets o problemas abiertos como, oh, este componente no funciona correctamente con el zoom, o esto no tiene el contraste adecuado, o no sé, el lector de pantalla tiene problemas para leer eso. Entonces, la accesibilidad es complicada de implementar para nosotros. Ese es el punto. Y un ejemplo es, pensemos un poco en las interacciones de presión. Las interacciones de presión pueden ocurrir en diferentes escenarios. Pueden ocurrir en clics de ratón, también pueden ocurrir en toques táctiles, pueden ocurrir cuando presionamos algunas teclas como enter o espacio, e incluso pueden ocurrir en clics virtuales realizados por algunos lectores de pantalla. Y si queremos abordarlos correctamente por nuestra cuenta, tenemos que hacer muchas cosas. Primero, tenemos que usar eventos de puntero cuando estén disponibles, y luego recurrir a eventos de ratón y táctiles. También tenemos que pensar en la selección de texto, por lo que tenemos que desactivarla en algunos escenarios, especialmente en dispositivos móviles cuando estamos presionando cosas. No solo eso, sino que también tenemos que manejar la cancelación de ellos a veces, por ejemplo, en eventos de desplazamiento. Y al final nos encontramos teniendo que normalizar muchas inconsistencias entre navegadores que todavía existen en la actualidad, y así sucesivamente. Sin mencionar el área.

Entonces, si has trabajado en accesibilidad, probablemente estés familiarizado con el área. Pero lo que sucede con el área es que proporciona principalmente semántica. Es como un contrato que debes seguir. Pero generalmente, las implementaciones que tenemos en los navegadores, en toda la plataforma web, carecen de alguna característica, o probablemente no se pueden personalizar lo suficiente, o a veces ni siquiera existe, por lo que depende de ti como desarrollador. Y esa es una tarea increíblemente difícil. Entonces, una de las primeras lecciones que aprendimos fue no gastar mucho tiempo, por ejemplo, discutiendo cómo implementar uno u otro enfoque de enfoque, o navegación por teclado, o investigando el área adecuada para algo. En su lugar, encontrar una biblioteca existente, y tenemos muchas de ellas, que brinde accesibilidad, principalmente, de forma predeterminada, y que se pueda personalizar lo suficiente para que coincida con nuestros tokens, nuestra marca, etc. Y esas bibliotecas generalmente vienen en tres sabores diferentes, o tres capas de abstracción diferentes.

Entonces, tienes primitivas de composición, como React Area y Downshift, y como sugiere el nombre, simplemente las construyes juntas, pero no ofrecen ningún estilo, o nada en absoluto. A veces viene, como Hooks de React que puedes conectar a tus componentes. Luego, tienes, un nivel por encima, los componentes sin estilo, que también se conocen, en la actualidad, como componentes headless, así que es realmente genial, y probablemente hayas oído hablar de ellos en todas partes. Entonces, tenemos Redix, ReachUI, HeadlessUI y Reakit. Y luego, tenemos los componentes completamente estilizados, por lo general, vienen con sistemas de estructura muy, muy poderosos, y tenemos un conjunto de componentes, son opinionados, pero los personalizamos para que coincidan con nuestros tokens de diseño, nuestras marcas, etc., a través de sus poderosos sistemas de estructura. Entonces, lo que debes preguntarte es, qué seguir, qué capa de abstracción o qué biblioteca entre todas estas. Realmente depende del contexto, por supuesto, de tu producto, tu empresa, etc., pero lo que debes tener en cuenta es elegir uno que tenga la accesibilidad como enfoque principal y que también se pueda tematizar y personalizar lo suficiente para que coincida con tus cosas. Por mi experiencia, generalmente he optado por primitivas de composición cuando, digamos, tenemos un sistema de diseño enorme en producción y estamos teniendo muchos problemas con la accesibilidad, tenemos mucho código que hace estilos y ese tipo de cosas.

4. Choosing Between Styled and Unstyled Components

Short description:

Al reinventar sistemas existentes, considera utilizar primitivas de composición, componentes sin estilo o componentes completamente estilizados según el contexto específico. Las pruebas automatizadas de accesibilidad son cruciales y se pueden integrar en el proceso de compilación o en CI. También es importante realizar pruebas manuales, especialmente para descubrir problemas que las pruebas automatizadas pueden pasar por alto. Las herramientas para simular discapacidades visuales pueden ayudar a identificar problemas de contraste y color. Considera las necesidades y escenarios específicos de tu aplicación al tomar decisiones de diseño y accesibilidad.

Entonces, al reinventar sistemas existentes, las primitivas de composición fueron lo que funcionó. Para componentes sin estilo, generalmente cuando tienes la oportunidad de comenzar algo desde cero, y me refiero desde cero, incluso si el producto se está construyendo desde cero, no solo el sistema de diseño. Por último, pero no menos importante, los componentes completamente estilizados, generalmente cuando no tienes diseñadores a tiempo completo. Voy a mencionar algunos escenarios, o cuando las pautas de diseño coinciden.

Por ejemplo, si estás construyendo un producto que tiene un diseño de material, podría tener sentido usar Material UI, por ejemplo, porque obtendrás muchas cosas de inmediato, además de la accesibilidad. Y cuando no tienes diseñadores a tiempo completo, por ejemplo, proyectos internos de experimentación en tu empresa. Entonces, estás construyendo un panel que mostrará algunas estadísticas provenientes de CI para que otros desarrolladores las vean, por lo que no tienes muchas restricciones para todo el diseño de esta aplicación, o estás trabajando como freelance en algún proyecto pequeño, ese tipo de cosas. Pero el hecho de que estas bibliotecas generalmente incluyan accesibilidad no significa que no debas probar la accesibilidad en tus aplicaciones. Entonces, una cosa que es realmente, realmente importante, sin importar qué solución implementes, es incluir pruebas automatizadas de accesibilidad. Y esto se presenta principalmente de dos formas diferentes. Puedes incluirlo como parte de tu proceso de compilación, con herramientas como JSS Accessibility, Lighthouse, Audits, XCore es increíble. Pero también puedes tener esto en tu CI, para que incluso puedas integrarlo con tus solicitudes de extracción. Por ejemplo, el bot X-Lightner es increíble. Entonces, tendrías ese tipo de cosas donde, por ejemplo, digamos que introduje algún marcado en mi código JSX que está rompiendo alguna línea, me advertirá, porque a veces simplemente no los detectamos a simple vista. Entonces, tener ese tipo de cosas es realmente, realmente útil. Pero, aunque estemos probando con pruebas automatizadas y demás, también es importante incluir pruebas manuales, porque al final es donde ocurren muchas cosas.

Tengo un ejemplo de este ticket de accesibilidad que recibí hace un par de meses, algo así como hace 3 meses, donde básicamente las cosas no se comportaban correctamente cuando la aplicación se ampliaba al 400%. Por ejemplo, yo mismo nunca habría pensado en eso, porque tengo suerte, no tengo problemas de discapacidad visual ni problemas con el zoom. Pero estas cosas suceden con las pruebas manuales. Y este, por ejemplo, fue un momento en el que pensé, ¿qué? Nunca lo habría imaginado. Entonces, las pruebas manuales pueden surgir cuando tú, como desarrollador, utilizas diferentes herramientas para realizar verificaciones rápidas, y la mayoría de las veces las herramientas que mencioné antes hacen eso. Pero también tienes herramientas específicas para simular discapacidades visuales específicas. Por ejemplo, problemas de contraste, como contraste bajo y alto, o problemas de baja visión o algunas de las muchas variaciones que podrías tener de daltonismo. Entonces, es realmente, realmente importante hablar de eso. Y hablando de contraste, no solo de contraste, sino de muchas cosas relacionadas con el color que desempeñan un papel realmente, realmente importante en la accesibilidad. Entonces, si hacemos un ejercicio, por ejemplo, y tratamos de construir una paleta de colores con accesibilidad en mente, con el contraste en mente, digamos que tenemos un tema claro y uno oscuro, y luego tenemos nuestra escala del 0 al 9, etc. Comenzamos con el color, eligiendo un color para la longitud en la aplicación. Entonces, vamos con azul y luego vamos con el opuesto en la paleta oscura que es el tono número 4, entonces, está bien, funciona. Pero luego, para los iconos, vamos con el número 6 en el claro y luego el número 3 en el oscuro. Pero luego, después de ejecutar algunas verificaciones de contraste o incluso a veces después de pasar por los usuarios, puedes darte cuenta de que en realidad lo que quieres es lo contrario exacto, ya que es natural para nosotros ir con eso.

5. Selección de Colores y Tokens de Diseño

Short description:

Al elegir colores de acento, espera que algunos colores puedan requerir ajustes más grandes en la paleta. La cooperación entre diseñadores e ingenieros es crucial para optimizar el trabajo. La entrega de un sistema de diseño es una pregunta complicada y la fuente de verdad puede ser el código existente, la interfaz de usuario existente o la documentación y las especificaciones de diseño. Trabajar con Figma y su API REST proporciona acceso a metadatos sobre los diseños y se integra bien con el concepto de tokens de diseño. Los tokens de diseño son elementos invisibles de diseño como colores, espaciado, tipografía o escala. Se pueden ver en los estilos de color, estilos de fuente, componentes y variantes de Figma. La API REST permite la generación de código basada en los elementos recuperados y sus propiedades.

Y luego, puedes tener aún más escenarios diferentes. Digamos que estás eligiendo un color de acento para algunos botones, alguna llamada a la acción, ese tipo de cosas comienzas con lo opuesto, pero luego te das cuenta de que en realidad el color que quieres está mucho más arriba en la escala. Entonces, otra lección que diría es algunos de esos colores pueden necesitar ajustes más grandes en la paleta y pueden moverse mucho. Así que, espera eso. Y siempre me gusta mencionar, por ejemplo este trabajo realizado por la gente de Stripe, que es increíble hicieron todo un estudio de caso de colores más accesibilidad y construyeron esta herramienta donde estaban experimentando, por ejemplo, con diferentes tipos de daltonismo y demás. Y, las conclusiones que obtuvieron son asombrosas y eso es el resultado del trabajo conjunto de diseñadores e ingenieros Así que, diría que para nosotros, principalmente los ingenieros de frontend aquí, supongo, es realmente, realmente importante que cooperemos con los diseñadores y que construyamos herramientas para optimizar su trabajo. Especialmente, porque al final también vamos a optimizar el nuestro. ¡Whoo!

Entonces, sí, hablemos de la entrega Porque al final planificas mucho y diseñas tu sistema de diseño, etc. Pero debe llegar a los usuarios, ¿verdad? Y debe llegar a los ingenieros que lo utilizan Por lo general, es una pregunta complicada cómo identificar la fuente de verdad de un sistema de diseño Porque podría ser el código existente, por lo que tienes los componentes y debes partir de ahí. Podría ser la interfaz de usuario existente, por lo que tienes muchos elementos existentes en la web, en las aplicaciones que se ejecutan en la web, etc. Y debes partir de ahí. O podría ser la documentación y las especificaciones de diseño y ese tipo de cosas que provienen de los ingenieros Entonces, uno de los temas que quiero abordar aquí es Convertir el diseño en código y Me gustaría hacer una pregunta. Entonces, ¿quién aquí está trabajando con Figma? Sí, me alegra que esto vaya a funcionar. Sí. Entonces, ¿quién aquí ha trabajado con la API REST de Figma? Me alegra de nuevo porque todos ustedes sabían eso así que no sería un punto. Entonces, para aquellos que no levantaron la mano en la última pregunta Figma tiene una API REST que es increíble porque utilizando esa API puedes obtener mucha información, metadatos, sobre tus diseños de Figma. Entonces, tienes todos los elementos, todos los nodos y todo sobre ellos. Y esto se integra muy bien con el concepto de tokens de diseño. Según la comunidad de estándares web design tokens son esos elementos invisibles de diseño como colores, espaciado, tipografía o escala. Y podemos verlos en Figma, por ejemplo, cuando tenemos nuestros estilos de color y los estilos de fuente. Y también podemos ver en nuestros componentes y las variantes de un componente dado. Y es realmente poderoso lo que podemos hacer con eso. Entonces, aquí en este ejemplo, estoy generando paletas tanto oscuras como claras para la marca de etiquetas de React. Entonces, puedes ver todos los tonos de azul, etc. Y con eso, puedo en la API REST, puedo escribir algún código de generación de código para la generación de código. Y sí, sé que hay muchas líneas para leer así que tendrás las diapositivas después, no te preocupes. Pero el punto es lo que está sucediendo aquí es básicamente, tengo algún código para obtener, comunicarme con la API, etc. Luego, tengo algún código para transformar los nodos que obtengo de la API. Entonces, accediendo a los elementos y obteniendo su color o el nombre que establecí para ese elemento para tener toda la información.

6. Generación de Código y Tokens de Diseño

Short description:

Estoy creando archivos TypeScript y archivos Sass con variables CSS para asegurar una fuente de verdad consistente en diferentes bases de código. Mediante la lógica de generación de código, podemos escalar este enfoque para trabajar con fuentes, iconos y más. Herramientas como SVGO y Prettier ayudan a optimizar y garantizar la conformidad del código. Además, existen herramientas de GitHub como Figment y Figma Export icons que simplifican el consumo de los recursos de Figma. El complemento Figma Tokens es una herramienta poderosa para generar diversos tokens de diseño, incluyendo colores, fuentes, espaciado y más.

Y luego, por último pero no menos importante, tengo algo de generación de código. Así que, estoy creando archivos TypeScript... Perdón, estoy creando archivos TypeScript y estoy creando archivos Sass y variables CSS porque eso es realmente importante cuando tienes diferentes bases de código construidas con diferentes tecnologías y quieres tener la misma fuente de verdad. Por ejemplo, teníamos bases de código de Angular que usaban Sass para el estilo y teníamos bases de código de React que usaban algunas estrategias de CSS y JS, por lo que queríamos que los tokens estuvieran en TypeScript, por ejemplo. Y luego, haces algo de GX atractivo sobre eso. Construyes, como, registros personalizados y algunos scripts agradables para mostrar lo que está sucediendo que puedes ejecutar localmente, puedes ejecutar en un CI. Y luego, el resultado es ese tipo de cosas. Así que, tienes todos los colores y las variantes y todo el tema definido tanto en TypeScript como en Sass para nosotros. Pero puedes agregar cualquier tipo de objetivo de compilación, para ser honesto, porque estás escribiendo la lógica de generación de código. Y esto es genial porque se escala. Así que, funciona también con fuentes. No solo colores, sino que funciona con prácticamente cualquier cosa, incluyendo iconos. Y puedes conectar muchas herramientas diferentes en todo el proceso. Por ejemplo, estábamos co-generando iconos SVG provenientes de los archivos de diseño. Así que, puedes usar SVGO para optimizar la salida SVG, para que tengas, como, el SVG más semántico y ese tipo de cosas. También puedes usar Prettier para asegurarte de que el código que se está generando, como los archivos Sass, los archivos TS e incluso, por ejemplo, estábamos co-generando componentes React para los iconos. Así que, puedes asegurarte a través de Prettier de que todo lo que se co-genera cumpla con tus reglas y tu base de código, etc. E incluso tienes otras herramientas en GitHub que te permiten no escribir mucha lógica para consumir cosas de Figma. Por ejemplo, tienes Figment y Figma Export icons. Digamos, solo estás interesado en los iconos. Alguien ha hecho el trabajo por ti. Y literalmente solo pegas tus claves de API y cosas así. Y sin mencionar que, una vez más, deberíamos construir herramientas para ayudar a los diseñadores y desarrolladores, etc. Así que, las personas están haciendo esto. Tenemos, por ejemplo, el increíble complemento Figma Tokens que genera para ti muchos tokens de diseño diferentes. No solo los que mencioné como colores y fuentes, sino también cosas complejas, espaciado, alturas de línea y muchas posibilidades. Y este es el tipo de resultado que obtienes, por ejemplo, si lo estás usando para tus tokens de color. Y tienes algo análogo para todas las demás cosas. Así que, estábamos haciendo mucha generación de código, etc. en el pasado. Pero tuvimos un momento de sorpresa cuando descubrimos que ese script que te mostré, lo estábamos ejecutando localmente, etc.

7. Automatización, Webhooks y Seguridad de Tipos

Short description:

Experimentamos con la automatización y la generación de código para agilizar el proceso de diseño. Las primeras iteraciones involucraron verificaciones de CI y versionado basado en archivos div. Luego, implementamos webhooks para actualizaciones reactivas y permitimos que los diseñadores cambien variables. Luego agregamos más automatización, como notificaciones de Slack para compilaciones fallidas e integración de complementos de Figma. Finalmente, pasamos a utilizar tokens de Figma para un mejor mapeo y seguridad de tipos. La seguridad de tipos es crucial en los sistemas de diseño, ya que ayuda a la productividad y evita hacer referencia a nombres de clases inexistentes.

Porque era una experimentación y estábamos haciendo muchas pruebas de concepto, etc. Así que queríamos automatizar las cosas pero los diseñadores aún tendrían que decir: 'Hey, acabo de hacer una actualización en la paleta de colores o algo así. ¿Puedes generarla de nuevo? Y publicar la nueva versión en npm y esas cosas'. Así que comenzamos a hacer diferentes iteraciones de generación de código y cosas así y automatización. En la primera de ellas, teníamos el CI para verificar automáticamente las actualizaciones y ese tipo de cosas. Y luego también teníamos el versionado basado en archivos div que estábamos generando. Así que compararíamos las salidas JSON y todas esas cosas y tendríamos los archivos div y, por cierto, cuando digo CI para verificar automáticamente, básicamente son ejecuciones programadas de un CI, por ejemplo, siempre al final del día o a veces ejecuciones semanales. Dependía. Y luego teníamos el registro de cambios y el versionado del paquete, por ejemplo, basado en esos archivos div. Así que teníamos, como, mucha magia para descubrir: '¿Esto es un cambio menor? ¿Es esto un parche? ¿Es esto un cambio mayor?' Ese tipo de cosas. Nunca cambios mayores, por cierto. Y luego, en la siguiente iteración, fue enorme porque básicamente comenzamos a tener webhooks. Así que, estas ejecuciones programadas en el CI se volvieron reactivas a través de webhooks. Así que, en realidad, cada vez que el diseñador publicaba cambios en el archivo de Figma, recibíamos una notificación y podíamos ejecutar cosas. Y luego llegamos al punto en el que los diseñadores podían cambiar tonos, colores, variables de fuente, todo tipo de cosas basadas en eso. Y luego, la automatización siempre requiere más automatización. Así que, básicamente, en el siguiente paso, lo que queríamos tener era, por ejemplo, notificaciones de compilaciones fallidas o nuevas versiones, ese tipo de cosas en un canal de Slack, por ejemplo, lo cual es bastante trivial de hacer. También los archivos de Figma creados por los diseñadores, para que no rompieran nuestro proceso de generación de código a través de un complemento de Figma. Nuevamente, construyendo herramientas para ayudar a los diseñadores y ayudar a nuestro servicio. Y luego pasamos a utilizar tokens de Figma porque no comenzamos con tokens de Figma, así que teníamos mucho código para mapear las cosas de Figma en nuestras cosas. Y para aquellos que no están familiarizados con la API de webhooks de Figma, se ve así. Así que tienes muchos eventos diferentes a los que puedes escuchar, creación de archivos, eliminación de archivos, actualización de archivos, ese tipo de cosas. Y Gates te proporciona mucha información adicional. Otra cosa es la seguridad de tipos. Eso es realmente importante en un sistema de diseño. Y generalmente no pensamos en ello. Pero yo mismo comencé a trabajar en esta base de código basada en SAS y me encontré con dos problemas. Primero, estaba haciendo las cosas más lentamente de lo que solía hacer, por ejemplo, al hacer CSS y JX o cualquier otra cosa que estuviera tipada. Extrañaba el autocompletado, extrañaba que el compilador me dijera: 'Oye, escribiste mal el nombre de esta clase' o algo así. Además, encontré, especialmente en una base de código enorme, muchos nombres de clases que simplemente no existían en absoluto. Así que tenías un componente haciendo referencia a un nombre de clase dado, pero esto simplemente no existía.

8. Fixing UI Bugs and Broken Builds

Short description:

A gran escala, este problema puede generar comportamientos inesperados en la interfaz de usuario. Lo solucionamos utilizando Webpack y encontrando complementos para generar tipos. Después de solucionar las compilaciones fallidas y ejecutar pruebas, recuperamos la finalización de elementos y encontramos numerosos errores.

existen. Así que ese fue un problema, no solo para nosotros, sino también para los usuarios. Porque a gran escala esto puede generar comportamientos inesperados en la interfaz de usuario. Entonces, el esfuerzo para solucionar eso fue básicamente que estábamos utilizando Webpack y etc., especialmente porque era un sistema heredado enorme y Webpack era genial en ese entonces y sí, fue bueno. Y así, tuvimos que encontrar complementos y conectar eso a nuestro proceso de generación y afortunadamente hay complementos para generar tipos para Webpack y luego tuvimos que solucionar las compilaciones fallidas y ejecutar algunas pruebas para comprobar si funcionaba como se esperaba o no y los resultados fueron básicamente que recuperé la finalización de elementos, lo cual fue genial y encontramos muchos errores. Por ejemplo, la revisión de código de esto fue increíble porque literalmente vimos cómo las compilaciones fallaban y etc., que teníamos muchos y al final fueron 96 casos de referencias a clases inexistentes. Cuando se trata de eso, también tenemos tipos literales de plantillas. Entonces, esta es una de las características más subestimadas de JavaScript y TypeScript en mi opinión. Por ejemplo, digamos que queremos construir un sistema de diseño seguro en cuanto a tipos. Entonces, tenemos, por ejemplo, el relleno CSS y queremos modelar el relleno CSS, por lo que tenemos que escribir tal vez un tipo de unión o un enum, algo así, y luego tenemos relleno izquierdo, relleno

9. Usage and Adoption of Design Systems

Short description:

Con los tipos literales de plantillas, podemos modelar direcciones y construir relleno CSS. La adopción es crucial para los sistemas de diseño, pero los desarrolladores a menudo reconstruyen componentes existentes. El uso se puede medir utilizando componentes personalizados y herramientas de análisis estático como RADIUS Tracker. Es importante saber si tu sistema de diseño está siendo adoptado y construir accesibilidad a medida que avanzas. Lo perfecto es enemigo de lo bueno, así que obtén resultados tempranos y aplica las mejores prácticas con herramientas de automatización. Los sistemas de diseño no se tratan solo de clases y definiciones de tokens; requieren herramientas, soporte y defensa.

correcto, etc. Con los tipos literales de plantillas en su lugar, podemos modelar lo que es una dirección, como izquierda, derecha, abajo, arriba, etc y luego construir relleno CSS sobre eso. Y esto es caótico porque también podemos hacer margen sobre eso y así sucesivamente

Y el último tema es la adopción. Entonces, al final, un sistema de diseño tiene que ser utilizado activamente para mejorar la experiencia del desarrollador y del usuario, etc., porque de lo contrario es un desperdicio de esfuerzo. Pero lo que sucede es que los desarrolladores tendemos mucho a reconstruir cosas incluso cuando ya existen. Así que tendemos a crear nuestros propios componentes incluso cuando el sistema de diseño que tenemos ya los proporciona y demás. Entonces, ¿cómo pensamos en el uso? ¿Cómo definimos el uso de un sistema de diseño? Para esto, tenemos un concepto muy interesante que se llama componentes personalizados. Básicamente, los componentes personalizados son aquellos construidos a partir de primitivas, como botones, divs, etc. Y, los componentes no personalizados son básicamente cuando compones otros componentes personalizados para tener un componente. Y son importantes porque si quieres ver cuánto se utiliza un sistema de diseño, entonces tienes que encontrar los componentes personalizados existentes, luego tienes que encontrar los componentes provenientes del sistema de diseño, y luego tienes que recopilar el uso de ambos, etc. Tienes que calcular la proporción y luego por último, pero no menos importante, tienes que hacer eso a lo largo de la historia del proyecto para ver si está aumentando o disminuyendo. Pero lo que sucede es que calcular la proporción de uso es realmente, realmente complicado, porque digamos que tenemos un componente pero podemos tener diferentes variaciones. Por ejemplo, podemos cambiar el nombre de este componente o podemos pasarlo como una propiedad o podemos mejorarlo con un componente de orden superior o podemos cambiarle el nombre al importarlo. Así que hay muchas cosas diferentes que pueden suceder y esto nos lleva a comprender que el uso es un concepto complejo. Por lo tanto, es complicado calcularlo, etc. Tienes que encontrar una herramienta que haga este trabajo de medición, una herramienta de análisis estático, y encontré una llamada RADIUS Tracker de Rangel y hay un estudio de caso realmente interesante que hicieron con Grafana UI, que es un kit de diseño de código abierto donde rastrean los números absolutos de uso a lo largo del tiempo y obtienen cosas realmente interesantes como la participación del sistema de diseño. Entonces puedes ver la participación a lo largo del tiempo, etc., y eso es realmente asombroso porque lo que buscas es tener una participación que crezca, no que disminuya. Así que algunas conclusiones sobre eso para que todavía tengamos espacio para preguntas. Es importante saber si tu sistema de diseño está siendo adoptado y en el momento en que comiences a hacer esto, verás que el evangelismo es realmente difícil y especialmente internamente en tu empresa. La segunda cosa es que deberías construir la accesibilidad a medida que avanzas porque al final si lo piensas a nivel de componente, verás que lo obtendrás de forma gratuita. No tendrás que hacer muchos refactorizaciones y cosas así. El tercer punto es que lo perfecto es enemigo de lo bueno y eso es un cliché, pero es verdad, así que cuanto antes obtengas resultados, antes podrás obtener retroalimentación, etc. Aplica todas esas cosas a través de herramientas de automatización, etc., y documenta lo que estás aplicando. Y tendemos a pensar que los sistemas de diseño se tratan mucho de clases, definiciones de tokens, tipografías, etc. Pero se trata mucho de herramientas, soporte activo y defensa. Por último, me encanta esta cita que básicamente dice que en Dios confiamos, todos los demás deben aportar datos. Estas son cosas que funcionan en mi contexto. Sí, siempre piensa, siempre experimenta y siempre intenta obtener tus datos. Y eso es todo. Gracias.

10. Q&A and Collaboration

Short description:

Por falta de tiempo, se omitirá la sesión de preguntas y respuestas. A menudo se olvida el soporte de ARIA en los sistemas de diseño internos, pero se puede hacer cumplir mediante herramientas como linters y bots. El uso de bibliotecas de componentes sin estilo en sistemas de diseño existentes puede ser sin problemas, ya que proporcionan ganchos y funciones de utilidad sin introducir estilos. Para fomentar la colaboración entre diseñadores y desarrolladores, considera establecer un equipo de DesignOps dentro de tu empresa.

Muchas gracias a todos. Por falta de tiempo, creo que tendremos que omitir la sesión de preguntas y respuestas. Cinco minutos, dos minutos de preguntas y respuestas. Dos minutos de preguntas y respuestas. Únete a mí para algunas preguntas y respuestas. Excelente, y hubo muchas preguntas absolutamente fantásticas, pero solo un recordatorio de que seguramente no podremos responder a todas. Pero después de esta sesión puedes hablar con Matthias en la sala de preguntas y respuestas de los ponentes y dejaré las preguntas no respondidas en Slido por un tiempo como base para las discusiones que ocurran en esa sala. Hola. Hola. Muchas gracias. Voy a ir directamente al grano. ¿Cómo podemos ayudar a los ingenieros a recordar el soporte de ARIA al usar un sistema de diseño interno? Por lo general, el soporte de ARIA es opcional y se olvida durante el desarrollo. Así que estoy un poco sesgado en esto porque lo que he visto recientemente, especialmente en la empresa en la que trabajo, es que nuestros clientes nos recuerdan constantemente el soporte de ARIA porque tienen que cumplir con algunas regulaciones algo así, por ejemplo, los clientes en los Estados Unidos o grandes empresas como Google, Apple, etc. Tienen que cumplir con cosas de ARIA, especialmente porque hay leyes. Así que para nosotros lo que está sucediendo últimamente es que recibimos tickets diciendo que tenemos este problema y antes de lanzar esta nueva versión de tu producto tienes que solucionarlo. Así que para nosotros es un esfuerzo reactivo Pero si no es un esfuerzo reactivo en tu empresa, entonces asegúralo mediante herramientas como linters, bots como los que mostré que verifiquen ARs y ese tipo de cosas. Ese sería mi consejo.

Excelente. Siguiente pregunta. ¿Cuáles son los problemas de usar bibliotecas de componentes sin estilo en sistemas de diseño existentes? En realidad, no hay tal problema. Cuando mencioné eso, fue principalmente desde mi experiencia, no sé, simplemente sucedió tal vez debido al tamaño de la base de código que estábamos tratando de migrar y aunque los componentes sin estilo no agregan ningún estilo pero están un poco optimizados a nivel de componente y ni siquiera necesitábamos eso. Literalmente queríamos algunos ganchos y algunas funciones de utilidad que pudiéramos conectar en nuestros componentes existentes. Pero no es que haya un problema. Es solo que las primitivas simplemente funcionaron mejor. Sí, esa fue la aproximación sensata. Creo que haremos una más, que es ¿hay alguna forma sencilla de hacer que los diseñadores colaboren en GitHub o viceversa, que los desarrolladores se unan a las herramientas de diseño para evitar la desviación de Figma y el producto? Esa es una pregunta realmente interesante. Eso es lo que deberías hacer el título de la charla cuando llevaba el sombrero de DesignOps Últimamente hemos tenido esto digamos de DesignOps, que generalmente las personas que lo hacen son diseñadores que tienden a ir hacia la ingeniería o viceversa Ingenieros que tienden a ir hacia el diseño. Así que diría que intenta ver si tu empresa, especialmente las grandes empresas, ya tienen a alguien en DesignOps Pero si no lo tienen y estás dispuesto a impulsarlo comienza a colaborar con los diseñadores e incluso tal vez encuentres algo que comience con dos personas y luego tres personas un equipo de DesignOps. GitHub tiene un caso realmente interesante de construir un equipo de DesignOps desde cero hace un par de años Sí, intentaré encontrar eso. Hay una charla interesante al respecto intentaré proporcionar el enlace. Pero sí, por lo general, si no tienes un DesignOps persona o equipo y estás dispuesto a impulsarlo. No es lo ideal pero deberías ser esa persona. Excelente, muchas gracias Un aplauso más para Matthias

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Vue.js London 2023Vue.js London 2023
14 min
Domain Driven Design with Vue Applications
Introduction to Domain Driven Design- What is DDD?- Key principles of DDD- Benefits of using DDD in web application developmentDomain Modeling in Vue 3 Applications- How to design and implement domain models in Vue 3- Strategies for integrating domain logic with Vue's reactive data model and component-based architectureBest Practices for Implementing DDD in Vue 3- Strategies for organizing code in a way that follows DDD principles- Techniques for reducing coupling between domain and application logic- Tips for testing and debugging domain logic in Vue 3 applications
Vue.js London 2023Vue.js London 2023
20 min
Proven Pinia Patterns
With Vue's new-and-improved state management library, Pinia, we gain a much more modular tool. While being more flexible, leaner, and lacking the Mutations of Vuex, Pinia presents us with more opportunities to be creative, for better or worse, with our app architecture and how state management is conducted and organized within it.This talk explores some @posva-approved best practices and architectural design patterns to consider when using Pinia in production.
Vue.js London 2023Vue.js London 2023
18 min
Component Design Patterns
How do you write a good component? In this talk we’ll explore several different patterns for writing better components. We’ll look at techniques for simplifying our components, making them easier to understand, and getting more out of the components we’ve already got.
React Advanced Conference 2022React Advanced Conference 2022
19 min
Building Figma’s Widget Code Generator
Widgets are custom, interactive objects you place in a Figma or Figjam file to extend functionality and make everything a bit more fun. They are written in a declarative style similar to React components, which gets translated to become a node on the canvas. So can you go the other way, from canvas to code? Yes! We’ll discuss how we used the public Figma plugin API to generate widget code from a design file, and make a working widget together using this.
JS GameDev Summit 2022JS GameDev Summit 2022
30 min
So You Want to be an Indie Game Developer?
So you want to be an indie game developer? You probably have an idea of what indie game development is like. My job is to assure you that you are wrong. I'm going to talk about misconceptions around indie game development and all you need to know before getting into it.