El objetivo de este artículo es sacar a la luz conceptos como Design Systems o Pattern Libraries. Explicar y aclarar qué son, porqué es tan necesario usarlos, herramientas para gestionarlos y dar a conocer una faceta más del front-end designer.
Llevo más de un mes sin poder escribir este artículo porque es un tema que hace que me salga de mi zona de confort. Hace un mes me incorporé a un nuevo equipo de trabajo y esto me llevó a querer saber más sobre mi nuevo role y cuestionarme qué se supone que tengo que ofrecer a mi equipo. Quería descubrir qué parte de mis responsabilidades tenía más floja e intentar mejorarla. Quería estudiar y ponerme al día en temas relacionados con puestos de front-end designers para poder dar un paso más y así mostrar una propuesta de valor.
Ser diseñador-maquetador abarca un entorno muy amplio y ambiguo a la vez, que requiere conocimientos de muchos palos aparte de saber photoshop y controlar la cascada de estilos. Brad Frost explica muy bien en este artículo qué engloba este perfil tan desconocido:
“A frontend designer...lives in a sort of purgatory between worlds”.
Toda esta reflexión de mirar, leer, preguntar… me ha llevado a la conclusión de que hay un mundo entero por trabajar en lo que se refiere a los Design Systems, Pattern Libraries, Style Guides... Son temas que conocía muy por encima y nunca me propuse profundizar demasiado porque, para ser sincera, me aburrían un poco. Pero cuando empiezas a rascar el interés crece y las ganas de saber ganan.
Presuponiendo que una gran parte de mis seguidores de twitter tienen un perfil técnico lancé esta pregunta a modo de globo sonda: ¿Usáis un pattern library en vuestra empresa/proyecto?
Sin querer sacar las cosas de contexto y admitiendo que quizá la pregunta no está del todo bien formulada, está claro que no se entendía ni lo que se estaba preguntando. Es cierto que hay veces que lo que no controlamos son los términos en sí y en realidad sí se trabajan estos campos en los equipos de diseño/desarrollo. Pero eso me preocupa quizá incluso más, porque quiere decir que no nos hemos preocupado de saber cómo se llaman las cosas. Y si no sabemos cómo nombrar lo que hacemos difícilmente podemos abrir un foro de debate para comentarlo.
Aclarando términos
Imitando el famoso concepto del diseño atómico de Brad Frost que consiste en dividir la creación de páginas web en componentes cada vez más simples hasta llegar al átomo, voy a intentar aclarar los términos relacionados con el Design System del más pequeño al más compuesto, ya que uno lleva al otro: Design tokens, diseño de componentes, Pattern Libraries y Design Systems.
Design Tokens
Los Design Tokens básicamente son átomos del diseño visual compuestos por propiedad y valor.
En realidad no se consideran como una declaración de variables como tal, sino un paso de abstracción más, entre la variable y la constante.
Esto hace que para estilar un botón tengamos esta estructura de código CSS:
Las variables no contienen constantes como valor, sino tokens. Utilizar estos tokens previene que los cambios de valores creen problemas en cascada y añade una capa más de seguridad. Así mismo favorece templatizar los estilos ya que las variables están aisladas del código y son fáciles de localizar y modificar.
Los de @eightshapes van a allá y tokenizan todo su sistema (no sólo colores) haciendo de estos el cimiento de su pirámide. Extienden un único sistema centralizado de tokens a todos sus productos web, Android e IOS. En este artículo explican cómo lo hacen.
Con esto consiguen coherencia en todos sus productos y que todos los equipos estén trabajando de la misma manera mirando en la misma dirección, con una robusta base de arquitectura del diseño.
Diseño de componentes
El siguiente eslabón es el componente y la importancia de tener estos bien identificados y nombrados, con la intención de conseguir unidades reutilizables y crear un producto consistente y mantenible.
Intentando diseñar los proyectos orientados a componentes he descubierto Sketch y he de decir que no lo cambio por nada del mundo. Es una herramienta para diseñar apps/webs al vuelo. Se pueden diseñar todos los símbolos que necesitemos, desde el átomo/molécula/componente e instanciarlos en nuestros diseños. Diseño reutilizable. Gol. El flujo de trabajo se acelera de una manera increible.
Además es una herramienta a la que se pueden añadir plugins open source desde github. No me digáis que no es ♡.
Fuera el photoshop para diseñar layouts. Photoshop es un editor de imágenes y recursos gráficos, punto.
Dos palabras para explicar las convenciones de nombrado. Hay que conocerlos y usarlos. Si no sabéis de qué hablo mirad: BEM, BEMIT, SuitCSS, semanticUI...
Mi cabeza está más cómoda trabajando con SemanticUI, más ligera y semántica pero parece que en proyectos potentes todos se decantan por BEM. Estoy haciendo un esfuerzo para cambiar de uno a otro.
Pattern Libraries
A estas alturas de la película tenemos la base de nuestro trabajo bien hecho y estructurado. Los componentes definidos, sus maquetaciones y estilados escritos, layouts establecidos.
Si recopilamos todos estos datos en una librería ya tenemos una Pattern Library. Esta metodología es muy necesaria para departamentos grandes pero hasta cuando el equipo es pequeño este conocimiento tiene que estar bien organizado y accesible para que la coherencia y calidad del código no se resienta.
Y ahora llegan las preguntas. ¿Cómo gestionamos toda esta información? ¿Dónde la colgamos para que esté accesible por el equipo? ¿Cómo administramos todo este conocimiento? ¿Quién es el responsable de mantenerlo vivo y útil? Estas son las preguntas que cada equipo tiene que hacer y solucionar.
En una Pattern Library no sólo se recopilan los colores, tipografias... también el HTML y el CSS utilizado de cada componente. Si se utiliza un preprocesador, también se incluirán estos snippets.
Tengo pendiente probar atomicdocs.io como plataforma de creación del library.
El Style Guide o guía de estilos, concepto que se conoce desde siempre heredado del mundo offline, es algo parecido a lo antes mencionado, pero en una Pattern Library se incluye mucho más que en una guía de estilos, que sólo se enfoca en los aspectos visuales.
Design Systems
En el FOWA 2013 de Londres, Mark Otto en su charla “Build your own bootstrap” describió un Design System como “everything that makes up your product”, entendiendo “everything” desde tipografía, layouts, grids, colores, iconos, maquetación de componentes, los estilos de cada componente, convenciones de código, la guía de estilos, la convención de nombrado, tokens de diseño… todo.
En resumen el Design System es un ecosistema vivo que engloba todo lo relacionado con el diseño y ofrece al equipo esta información haciendo que se involucre en la construcción de un producto coherente ganando claridad, eficiencia, consistencia y belleza.
Mark va más allá en su exposición y anima a que estos Design Systems se trabajen como proyectos open source para poder ayudar a otros equipos a mejorar sus propios sistemas de diseño.
Los frameworks como Bootstrap, Ionic o SuitCSS son Design Systems también, pero aparte de los grandes frameworks que todos conocemos, existen librerías publicadas que podemos utilizar para ver cómo lo hacen otros como Codepen, Mailchimp, Salesforce, A list apart, Atlassian, Github, Google, IBM, Origami...
Jina Bolton referente en la evangelización sobre Design Systems, explica en este vídeo cómo lo hacen ellos en Salesforce y todas las ventajas que ofrece esta manera de trabajar. (Slides)
Su Lightning Design System es el que yo actualmente uso como guía en mi trabajo.
Para quien quiera profundizar en el tema os paso:
Canal de Slack creado por Jina Bolton sobre Design Systems.
Jina Bolton en el podcast sobre style guides dirigido por Brad Frost.
Nathan Curtis en el podcast sobre style guides dirigido por Brad Frost.
Conclusiones
El conocimiento de todos estos conceptos son importantes para un front-end designer pero el reto está en aplicarlo en entornos pequeños o medianos que justo justo llega a cumplir sus deadlines y no tienen ni tiempo ni recursos para dedicarle a esto. Mi objetivo a medio plazo es demostrar que se puede mantener una Pattern Library incluso en equipos reducidos, sin comprometer los tiempos de desarrollo, y mejorar los procesos de diseño.
Esto requerirá de mucho estudio del diseño, innumerables refactors, planificación del proceso en el tiempo y comunicación del conocimiento con los compañeros implicados.
Quizá sólo quiera demostrar una utopía, ya veremos.
Agradecimientos
Agradecimientos al grupo de Frontaneros que me habéis informado e inspirado tanto y en especial a @jaicab_ y @danifornells por vuestro interés en ayudarme. A @gorkalaucirica y @benatespina de Lin3s por compartir vuestro código y entusiasmo por vuestro trabajo.
Mil gracias a @flodar por contar conmigo un año más y su comprensión aunque le haga sufrir al enviarle el artículo al filo del abismo. Mil perdones.