¿Sistemas de diseño? ¡Pero si soy desarrollador!

¿Deben los developers involucrarse en los procesos de ideación y creación de productos desde el momento en el que los diseñadores comienzan a abordarlos? Es una pregunta que suena un poco a androides y ovejas eléctricas pero intentaremos darle respuesta en este post.

Por todos es conocido esa lucha subyacente en el mundo digital entre diseñadores vs. desarrolladores y las míticas batallitas de “El diseñador me puso 8 tipos de grises en la paleta de colores” o “Es que el front dice que esta animación no se puede hacer”. Han corrido ríos de tinta y saliva en artículos y charlas sobre cómo mejorar la comunicación entre ambos pilares fundamentales del desarrollo de producto durante muchos años. Y, cuando creíamos que era algo
parcialmente superado, llega un nuevo Golem a truncar todo el camino recorrido: los Design Systems.

Como desarrolladora, al principio, no entendía tanto revuelo con este nuevo trending topic en los productos digitales, porque a lo largo de mi carrera había desarrollado “Style guide” y/o “Component library” y no entendía en qué se diferenciaban de los Design Systems.

En realidad tanto una guía de estilo como las guías de componentes son sub-items de un Design Systems.

¿Qué es un Design System?

Un Design System (DS) es una visión holística del desarrollo de productos en el que se definen guidelines, principios, códigos y filosofías que conforman el propio producto. Son escalables de manera coherente en base a las necesidades de negocio.

Tal y como lo definió Nathan Curtis “A Design System isn’t a Project. It’s a Product, Serving Products”.

Lo básico que debe tener un Design System es:

• Propósitos y valores definidos.
• Principios de diseño.
• Identidad de marca y uso del lenguaje.
• Componentes y patrones.

Algunos Design System conocidos y que sirven de inspiración son Material Design, Carbon y Polaris.

¿Qué podemos aportar como desarrolladores al proceso de creación de un Design System?

Generalmente, en el proceso de trabajo de creación de un Design System, los desarrolladores entran en la última fase: transformar en código las guidelines producidas por el equipo de diseño. Pero si queremos producir un buen producto con unas bases sólidas, el equipo de desarrollo debe trabajar junto al equipo de diseño. Es algo fundamental que parece demasiado obvio, pero no es la realidad ya que aún en innumerables equipos no se trabaja de manera conjunta.

Partimos de la base de que como desarrolladores, y en mi caso como desarrolladora de interfaces (maquetadora old school), esperamos unos diseños a través de InVision, Zeplin, Avocode… o cualquier otra plataforma/formato que nosotros vamos a traducir en código y ya está. Error. No podemos estar trabajando en el desarrollo de un Design System con la metodología que hemos estado empleando hasta la irrupción de los mismos en la creación de productos.

El Design System que vamos a desarrollar es un organismo vivo y como parte del proceso evolutivo del mismo, deberíamos involucrarnos desde el mismo momento de su concepción creativa. No tanto desde las líneas de negocio a explorar, o la identidad de marca, pero sí, y sin lugar a dudas, durante el proceso de ideación de todos los componentes que conformarán el sistema e incluso de los patrones que se seguirán para iterar las primeras fases.

Como siempre, estarán presentes las reticencias típicas acerca de los procesos de diseño y el acercamiento por parte de los desarrolladores hacia estos; pero la realidad es que nuestro campo de trabajo cada vez es más complejo y especializado cuando se busca la excelencia y calidad en los resultados.

Por ello, un desarrollador de interfaces debería tener cierta sensibilidad y nociones básicas de usabilidad y diseño, de la misma manera que es capaz de instalar una nueva dependencia en su SPA para minimizar unas imágenes o aprende a lanzar queries en una base de datos para comprobar que los datos que estamos recibiendo son los correctos. Aunque bajo mi punto de vista, lo más importante es saber reconocer que ya poseemos muchas de esas nociones y que muchas de nuestras herramientas y procesos para el desarrollo son las mismas o pueden ser utilizadas por los equipos de diseño.

En nuestro día a día utilizamos el conocimiento que tenemos sobre las distintas metodologías de arquitectura CSS. ¿Por qué no transmitirlo e integrarlo en el Design System? ¿Cómo? Pues es sencillo, si durante la fase de ideación de los componentes que formarán parte del DS trabajamos en conjunto con los diseñadores para establecer una nomenclatura de componentes basada en alguna de estas arquitecturas, por ejemplo BEM, el idioma que hablemos con el diseñador a futuro respecto a estos componentes será el mismo.

Otra ventaja es que si pasaran a formar parte del equipo nuevas personas, tanto en la parte de diseño como en la de desarrollo, les sería más sencillo desde un primer momento la comunicación y entendimiento del sistema de componentes.

También podemos aportar nuestro granito de arena en cuanto a la nomenclatura y definición de elementos tipográficos o de color que se incluyan en el DS con la visión puesta en la escalabilidad y mantenimiento del proyecto a futuro. O en relación al del grid que se vaya a usar junto con sus distintas variaciones, se pueden empezar a establecer bases para grid-templates de grid-layout y añadir más versatilidad a los componentes que vayan a crearse.

La performance del producto, la compatibilidad con navegadores, incluso el uso de animaciones css vs animaciones con svg… Son puntos en los que hablando de tú a tú con el equipo de diseño se pueden trabajar conjuntamente para que, a la hora de ejecutar, aquello termine formando el grueso de la UI del Design System.

También a nivel de implementación de lógica de negocio que pueda impactar en cómo se idee el DS: si desarrollo apoya y complementa en este punto del proceso con una visión más técnica teniendo en cuenta el desarrollo futuro es un paso que ya llevamos ganado.

¿Qué herramientas podemos utilizar para el proyecto de creación de un Design Systems?

El listado de herramientas para una mejor comunicación entre diseño y desarrollo (y también el resto de stakeholders de un producto) es bastante amplio a día de hoy y el uso de una u otra dependerá siempre de las decisiones que se tomen en el conjunto del equipo, pero algunas de nuestras favoritas son las siguientes:

• Figma: es una herramienta de diseño colaborativo que permite la interacción a tiempo real de varios integrantes del equipo. Además es multiplataforma ya que es una herramienta que se ejecuta en el navegador y no son necesarias licencias ni la instalación de software propietario (y además permite la importación de proyectos de Sketch :) ).
• Framer X: es un software propietario con una interfaz muy similar a Sketch cuya base convierte los diseños en código con base en React. Es útil para proyectos que vayan a desarrollarse usando este framework ya que la creación es bidireccional: se puede generar código desde el diseño y diseño desde el código, mejorando así el diálogo entre equipos.
• Bit: herramienta open source con base en Git y NPM que permite compartir componentes entre proyectos.

¿Qué herramientas podemos utilizar como desarrolladores de un Design Systems?

Las herramientas utilizadas en la etapa de desarrollo dependen siempre de las especificaciones del producto final pero hay algunas herramientas que nos pueden servir para el desarrollo de un Design System que nos permitan plasmar todo el potencial que representan en la etapa de desarrollo:

Orientados a web components:

• Stenciljs: basado en el estándar de web components. Utiliza Typescript y es agnóstico de framework.
• Lit-element: también basado en el estándar de web components.

Orientadas a documentación y visualización por equipos:

• ReactStyleguides: Permite crear una guía de estilo visual y simple a partir de un proyecto de React.
• SassDocs: Mejora la documentación de los estilos, pudiendo volcar parte de los principios del sistema de diseño en la estructura del CSS.
• Storybook: sirve para web components así como para componentes generados con cualquier framework, también con vanillaJS&HTML simple. Storybook tiene una muy buena documentación en la que desgrana el desarrollo de un DS utilizándolo de herramienta.

Conclusión

¿Deben los developers involucrarse en los procesos de ideación y creación de productos desde el momento en el que los diseñadores comienzan a abordarlos? Claramente: Sí.

Los Design System son una pieza fundamental de la creación de un producto con consistencia visual y funcional compuesto por componentes vivos que permiten crear todo un ecosistema que favorece y simplifica la evolución del mismo desde el punto de vista de desarrollo.

Desde el lado de desarrollo podemos brindar herramientas a los distintos equipos implicados en el proceso de creación, como diseñadores, producto y el resto stakeholders, creando una experiencia de trabajo colaborativo mucho más enriquecedora y productiva.

Es hora de dejar a un lado de manera definitiva esas viejas rencillas entre los distintos equipos porque todos tenemos un objetivo común y porque en base a mi experiencia puedo asegurar que cuando todos los integrantes de un equipo están alineados y hay una comunicación fluída, el crecimiento personal y profesional es inmenso y sientes que tendrías que haber empezado antes a trabajar así. Sobre todo cuando descubres que ya no vuelves a tener jaquecas por el “enésimo gris que ha metido diseño”.