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

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.

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.

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.

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.

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.

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.

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.

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