Los sistemas de diseño tienen que ver con las relaciones

Los sistemas de diseño pueden ser increíblemente útiles. Proporcionan elementos reutilizables y pautas para crear una apariencia uniforme en todos los productos. Como resultado, los usuarios pueden tomar lo que aprendieron de un producto y aplicarlo a otro. De manera similar, los equipos pueden implementar patrones bien probados para la navegación o las revisiones, lo que hace que los productos sean más confiables. Los sistemas de diseño efectivos resuelven problemas aburridos de manera repetible para que los desarrolladores y diseñadores puedan concentrarse en resolver problemas novedosos.

Sin embargo, cuando alguien usa el término "sistema de diseño" en una reunión, nunca estoy seguro de qué reacción esperar. He visto curiosidad y entusiasmo por probar una nueva forma de trabajar, pero también he visto frustración y preocupación por la idea de que un sistema limite la creatividad de los diseñadores. Algunos diseñadores argumentan que los sistemas de diseño minan la creatividad, o que son soluciones en busca de un problema. Los sistemas de diseño pueden fragmentarse con el tiempo, lo que hace que los equipos dejen de usarlos.

Sin embargo, los sistemas de diseño no van a desaparecer. Solo el 15 % de las organizaciones carecían de un sistema de diseño en 2018, según una encuesta. Eso es menos que el 28% del año anterior. Algunos equipos utilizan grandes sistemas de diseño de uso general como Material Design de Google, mientras que otros utilizan sistemas más pequeños y personalizados como REI's Cedar y Mozilla's Protocol.

Los sistemas de diseño deben empoderar a los equipos, no limitarlos. Para que eso suceda, tenemos que empezar a pensar de manera más holística. Un sistema de diseño no es solo código, diseños o documentación. Son todas estas cosas, además de las relaciones entre las personas que crean el sistema y las personas que lo usan. Incluye no solo archivos CSS y documentos de Sketch, sino también confianza, comunicación y propiedad compartida. Resulta que hay todo un campo de estudio dedicado a explorar sistemas como estos.

El panorama

Un artículo de 1960 titulado "Sistemas sociotécnicos" exploró las interacciones entre la tecnología, los humanos y el entorno más amplio en el que existen. Enid Mumford explicó que los investigadores comenzaron investigando cómo construir mejores relaciones entre gerentes y empleados, pero en la década de 1980, se enfocaron en hacer que el trabajo fuera más eficiente y rentable. En 2011, Gordon Baxter e Ian Sommerville escribieron que esta investigación ayudó a inspirar el diseño centrado en el usuario y que queda mucho trabajo por hacer.

Baxter y Sommerville argumentaron que hoy en día todavía existe una tensión entre la investigación “humanística”, que se enfoca en la calidad de vida de los empleados, y la investigación “gerencial”, que se enfoca en su productividad. También explicaron que es importante considerar tanto la tecnología como las interacciones humanas: “el rendimiento del sistema se basa en la optimización conjunta de los subsistemas técnico y social”.

Yo diría que los sistemas de diseño son sistemas sociotécnicos. Implican interacciones entre las personas que crean el sistema, las personas que crean productos utilizando el sistema y los usuarios finales que interactúan con estos productos. También evocan la misma tensión entre eficiencia y humanismo que vieron Baxter y Sommerville.

Los sistemas de diseño no se componen solo de imágenes y código; involucran conversaciones entre diseñadores, desarrolladores, gerentes de productos, directores ejecutivos y personas aleatorias en GitHub. Estas interacciones ocurren en varios contextos: una empresa, una comunidad de código abierto, un hogar, y ocurren a través de culturas y límites organizacionales. Crear un equipo puede significar reunir a personas de disciplinas como la animación, el diseño de sonido, la visualización de datos, la háptica y la redacción publicitaria. La creación de un sistema de diseño exitoso requiere partes iguales de experiencia técnica y habilidades blandas.

Y, sin embargo, examine los agregadores de noticias de diseño o ingeniería y es probable que vea un enfoque distinto en ese "subsistema técnico": código y herramientas, en lugar de personas y conversaciones. ¿Qué herramienta creativa es la mejor para realizar un seguimiento de los tokens de diseño? ¿Qué tecnologías de JavaScript se deben usar para crear componentes reutilizables: React, componentes web o algo más? ¿Qué herramienta de compilación es mejor?

La respuesta a estas preguntas es, por supuesto, "¡depende!" ¿Quién diseñará, construirá y utilizará el sistema? ¿Cuáles son sus necesidades? ¿Bajo qué restricciones están operando? ¿Con qué herramientas y tecnologías se sienten cómodos? ¿Qué quieren aprender?

Para responder a este tipo de preguntas, Baxter y Sommerville recomiendan dos tipos de actividades:

• Actividades de sensibilización y concienciación
  Aprender acerca de las diversas personas que crearán y participarán en el sistema, y ​​compartirán esa información por todas partes.
• Compromiso constructivo
  Comunicarse entre roles, construir prototipos y considerar las partes técnicas y sociales del sistema.

Excavando

A principios de 2019, formaba parte de un equipo, llamémoslo "equipo azul", que estaba construyendo un sistema de diseño para una gran organización. Facilité conversaciones informales con este equipo y el "equipo verde", que estaba usando el sistema de diseño para crear una aplicación web. Cada dos semanas, reuníamos a todos los desarrolladores y diseñadores alrededor de una mesa y hablábamos sobre lo que estábamos construyendo y qué problemas estábamos tratando de resolver. Estos chats fueron nuestras “actividades de sensibilización y concientización”.

No teníamos permiso para hacer público nuestro sistema de diseño, así que hicimos lo siguiente: lo tratamos como un pequeño proyecto de código abierto dentro de la organización. Pusimos el código en un repositorio al que ambos equipos podían acceder y solicitamos contribuciones. El equipo azul era responsable de revisar y aprobar estas contribuciones, pero cualquiera de los dos equipos podía contribuir. El equipo azul también estaba creando una aplicación propia, por lo que, en cierto sentido, eran usuarios y custodios del sistema de diseño.

Estas interacciones ayudaron a los equipos a crear mejores productos, pero lo que es más importante, establecieron confianza entre los equipos. El equipo azul aprendió que la gente estaba usando el sistema cuidadosamente y construyendo nuevas ideas inteligentes sobre él. El equipo verde aprendió que el sistema realmente se adaptó a sus necesidades, por lo que podían trabajar con él en lugar de contra él. Baxter y Sommerville podrían llamar a este trabajo “compromiso constructivo”.

Descubrimos que ambos equipos estaban bajo presión para aprender nuevas tecnologías y entregar un producto completo rápidamente. En otras palabras, ya estaban operando bajo una carga cognitiva bastante considerable. Como resultado, los dos equipos acordaron centrarse en hacer que el sistema sea fácil de usar. Eso significó eludir todo el debate sobre los componentes web, centrándonos principalmente en CSS y asegurándonos de que nuestra documentación fuera clara y amigable.

Poniendolo todo junto

Las organizaciones de todos los tamaños crean elementos de diseño reutilizables para ayudar a los equipos a crear aplicaciones más coherentes y elegantes. Las necesidades y dinámicas de las diferentes organizaciones se expresan en sus sistemas de diseño. Estos son solo algunos ejemplos:

• Material Design de Google tiene varias implementaciones en diferentes marcos e idiomas. Es utilizado por una variedad de personas dentro y fuera de Google, por lo que tiene una documentación completa y una variedad de kits de herramientas para diseñar aplicaciones.
• Fluent Design System de Microsoft se dirige a cuatro plataformas muy diferentes. Al igual que Material, incluye kits de herramientas para diseñadores de UX y documentación completa.
• El Protocolo de Mozilla se implementa en Sass y Vanilla JavaScript. Tiene un fuerte enfoque en la internacionalización. Alex Gibson dice que este sistema ayuda a Mozilla a “crear páginas web de marca a un ritmo más rápido con menos trabajo manual repetitivo”.
• Cedar de REI está construido con componentes Vue.js y no se puede usar con otros marcos de JavaScript. El cedro es utilizado principalmente por los desarrolladores internos de REI y está estrechamente ligado a la marca de la empresa. El código del sistema de diseño es de código abierto, pero sus fuentes no lo son.
• Lightning Design System de Salesforce es un marco CSS independiente de JavaScript. Opcionalmente, se puede usar junto con Lightning Component Framework, que incluye dos implementaciones de JavaScript: una que usa componentes web y otra que usa el marco Aura patentado de Salesforce.
• PatternFly de Red Hat se creó para brindar una experiencia de usuario consistente en todos los productos de la plataforma en la nube de la compañía, por lo que tiene una densidad de información relativamente alta e incluye una variedad de componentes de visualización de datos. El equipo de PatternFly cambió recientemente de Angular a React después de algunos experimentos con componentes web. PatternFly también incluye una implementación independiente de JavaScript usando HTML y CSS. (Divulgación completa: soy un ex Red Hatter).
• Carbon Design System de IBM ofrece implementaciones en React, Vue, Angular y Vanilla JavaScript, así como un kit de herramientas de diseño para Sketch. El equipo de Carbon está experimentando con componentes web. (Felicitaciones a Jonathan Speek por rastrear ese repositorio).

Sistemas como estos son consistentes y confiables porque personas de diferentes equipos y roles trabajaron juntas para construirlos. Estos sistemas resuelven problemas reales. No son el resultado de que los desarrolladores intenten imponer su voluntad a los diseñadores o viceversa.

Josh Mateo y Brendon Manwaring explican que los diseñadores de Spotify "ven su papel como contribuyentes principales y coautores de un sistema compartido , del que son dueños". Mina Markham se describe a sí misma como “la traductora entre ingeniería y diseño” en el sistema de diseño Pantsuit. Jina Anne profundiza en la dinámica del equipo y la investigación de los usuarios detrás de los sistemas de diseño: “¡Alerta de spoiler! Vas a necesitar algo más que diseñadores”.

¡Construyamos algunas cosas!

Ahora que hemos realizado investigaciones y algunos ejemplos, hablemos sobre cómo construir un nuevo sistema de diseño. Comience hablando con la gente. Averigüe quién usará y contribuirá a su sistema de diseño. Estas personas probablemente abarcarán una variedad de disciplinas: diseño, desarrollo, gestión de productos, negocios y similares. Conozca las necesidades y los objetivos de las personas y pídales que compartan en qué están trabajando. Considere planificar una reunión informal con refrigerios, café o té para crear un ambiente acogedor. Establezca una comunicación regular con estas personas. Eso podría significar unirse a una sala de chat compartida o programar reuniones periódicas. Mantén el tono casual y amigable, y concéntrate en escuchar.

Mientras habla sobre lo que está trabajando, busque problemas y objetivos comunes. Es posible que los equipos necesiten mostrar grandes cantidades de datos, por lo que están investigando herramientas para mostrar tablas y generar informes. Priorizar las soluciones para estos problemas.

Busque también patrones repetidos y variaciones sobre temas similares. Es posible que encuentre que los botones y los formularios de inicio de sesión se ven un poco diferentes entre los equipos. ¿Cuál es el significado de estas variaciones? ¿Qué variaciones son intencionales (por ejemplo, un botón principal versus un botón secundario) y qué variaciones han ocurrido por accidente? Su sistema de diseño puede nombrar y catalogar los patrones y variaciones intencionales, y puede eliminar las variaciones “accidentales”.

El objetivo aquí es establecer un ciclo de retroalimentación rápido con las personas que utilizan el sistema de diseño. La retroalimentación más rápida y las iteraciones más pequeñas pueden ayudar a evitar ir demasiado lejos en la dirección equivocada y tener que cambiar drásticamente el rumbo. PJ Onori llama a estos cambios grandes y repentinos "thrash". Él dice que algo de thrash es bueno, es una señal de que estás aprendiendo y respondiendo al cambio, pero que demasiado puede ser disruptivo. “No debes temer al thrash”, dice, “pero debes saber cuándo es útil y cómo ayudar a mitigar sus inconvenientes. Una de las mejores [formas] de mitigar las desventajas del thrash es comenzar poco a poco, con todo ”.

Considere comenzar poco a poco configurando algunos elementos básicos:

• Un sistema de control de versiones para almacenar su código. GitHub, GitLab y Bitbucket son excelentes opciones aquí. Asegúrese de que todos los que usan el sistema puedan acceder al código y proponer cambios. Si es posible, considere hacer que el código sea de código abierto para llegar a la audiencia más amplia posible.
• Código CSS para implementar el sistema. Use variables de Sass o propiedades personalizadas de CSS para almacenar "tokens de diseño", valores comunes como anchos y colores.
• Un archivo package.json que define cómo las aplicaciones pueden compilar e instalar el sistema de diseño.
• Documentación HTML que demuestre cómo usar el sistema de diseño, idealmente usando el propio CSS del sistema.

La documentación de node-sass para el marco CSS Bulma describe estos pasos con un poco más de detalle. Puede omitir la instalación e importación de Bulma si desea comenzar desde cero, o puede incluirlo si desea comenzar con algunos de los conceptos básicos en su lugar.

Es posible que haya notado que no mencioné nada sobre JavaScript aquí. Es posible que desee agregar este elemento eventualmente, pero no lo necesita para comenzar. Es fácil meterse en la madriguera del conejo investigando las mejores y más nuevas herramientas de JavaScript, y perderse en esta investigación puede dificultar el comienzo. Por ejemplo, "5 razones por las que los componentes web son perfectos para los sistemas de diseño" y "Por qué no uso componentes web" son puntos válidos, pero solo usted puede decidir qué herramientas son adecuadas para su sistema. Comenzar solo con CSS y HTML le permite recopilar comentarios del mundo real que lo ayudarán a tomar esta decisión cuando llegue el momento.

A medida que lanza nuevas versiones del sistema, actualice el número de versión de su sistema para indicar qué ha cambiado. Utilice el control de versiones semántico para indicar qué ha cambiado con un número como "1.4.0". Incremente el último número para las correcciones de errores, el número del medio para las nuevas funciones y el primer número para los cambios grandes y disruptivos. Siga comunicándose con las personas que usan el sistema de diseño, solicite comentarios y contribuciones, y realice pequeñas mejoras sobre la marcha. Esta forma de trabajo colaborativa e iterativa puede ayudar a minimizar el "desplazamiento" y establecer un sentido de propiedad compartida.

Finalmente, considere publicar su sistema de diseño como un paquete en npm para que los desarrolladores puedan usarlo ejecutando el comando npm install your-design-system . De forma predeterminada, los paquetes de npm son públicos, pero también puede publicar un paquete privado, publicar el paquete en un registro privado o solicitar a los desarrolladores que instalen el paquete directamente desde un sistema de control de versiones. El uso de un repositorio de paquetes facilitará la detección e instalación de actualizaciones, pero la instalación directa desde el control de versiones puede ser una solución fácil a corto plazo para ayudar a los equipos a comenzar.

Si está interesado en aprender más sobre el lado de la ingeniería, Building Your Design System de Katie Sylor-Miller ofrece una inmersión profunda fantástica. (Divulgación completa: he trabajado con Katie).

Terminando

Los sistemas de diseño se componen de código, diseños y documentación, así como de relaciones, comunicación y confianza mutua. En otras palabras, son sistemas sociotécnicos. Para construir un sistema de diseño, no comience escribiendo código y eligiendo herramientas; Comience hablando con las personas que utilizarán el sistema. Conozca sus necesidades y limitaciones, y ayúdelos a resolver problemas. Al tomar decisiones técnicas, de diseño o estratégicas, tenga en cuenta las necesidades de estas personas por encima de la "mejor" forma teórica de hacer las cosas. Comience poco a poco, repita y comuníquese sobre la marcha. Mantenga su sistema lo más simple posible para minimizar la sobrecarga e invite a recibir comentarios y contribuciones para establecer un sentido de propiedad compartida.

Al dar el mismo peso a las consideraciones interpersonales y de ingeniería, podemos obtener los beneficios de los sistemas de diseño y evitar las trampas. Podemos trabajar de manera eficiente y humana; no tenemos que elegir uno sobre el otro. Podemos empoderar a los equipos en lugar de limitarlos. En última instancia, los equipos empoderados nos ayudan a servir mejor a nuestros usuarios, que, después de todo, es la razón por la que estamos aquí en primer lugar.

Lectura adicional en SmashingMag:

• Consejos para gestionar sistemas de diseño
• Incluir animación en su sistema de diseño
• Más allá de las herramientas: cómo crear un sistema de diseño puede mejorar su forma de trabajar
• Construcción de un sistema de diseño a gran escala para el gobierno de EE. UU. (estudio de caso)