Sistemas de diseño vs desarrollo: La unión que conforma la clave del éxito

Cuando oímos hablar de desarrollo frontend, la mayoría de las veces pensaremos en la parte puramente relacionada con la codificación, pero… ¿Qué hay de la experiencia de usuario?, ¿de la usabilidad?, ¿de ese efecto “wow!” que le queremos dar a nuestra aplicación? ¿Cómo se refleja eso en una documentación? Y lo más importante, ¿Cómo es la continua comunicación entre diseño y desarrollo?, para eso tenemos los sistemas de diseño, pero…

¿Qué es un sistema de diseño?

Un sistema de diseño es la guía que se utilizará por parte de todos los implicados en la creación de un nuevo producto (diseño, negocio y equipos de desarrollo/arquitectos) desde la fase de conceptualización hasta la de desarrollo.

Este sistema va a contener desde la guía de estilos (colores, fuentes, espaciados, iconografía, etc) hasta los componentes básicos (building blocks) con los que se podrán construir componentes más complejos.

Un sistema de diseño está basado en la metodología Atomic Design ideada por Brad Frost e inspirada a su vez en la química donde nos podemos encontrar grupos de átomos que conforman moléculas y grupos de moléculas que forman organismos. Esto, si lo trasladamos a un sistema de diseño nos encontraríamos con los componentes building blocks que serían lo equivalente a los átomos, que unidos pueden conformar componentes más complejos (moléculas) y así sucesivamente hasta tener la página que ve el usuario, el producto final.

¿Qué aporta un sistema de diseño?

  • Coherencia visual: Aunque parezca evidente, queremos que todos nuestros productos se vean igual, es más, queremos que, llegado el momento, si queremos dar un cambio de aire a nuestros productos y modificar la paleta de colores por ejemplo, nos gustaría que modificando estos colores en un solo sitio todos los productos recibiesen este cambio sin requerir ningún esfuerzo a nivel de desarrollo. Más adelante veremos cómo los design tokens pueden ayudarnos con esto.
  • Funcionalidad y usabilidad: El equipo de diseño definirá y documentará la usabilidad y la funcionalidad de todos los componentes, desde los más pequeños hasta los más complejos de tal manera que el equipo de desarrollo no tenga duda de cómo se ha de realizar la implementación de estos.
  • Componentes reutilizables: Aquí no solo hablamos de los componentes más básicos, podemos encontrarnos con componentes más complejos (moléculas u organismos) con cierta lógica de negocio y que también van a ser reutilizables. La reutilización lo que nos aporta es un ahorro en los costes de desarrollo al no tener que reimplementar partes que son comunes. Normalmente existe un catálogo de componentes que se expone mediante librerías aunque actualmente la integración de funcionalidades mediante microfrontends es cada vez más habitual.
  • Velocidad de desarrollo: Dependiendo de la madurez del sistema de diseño nos encontraremos con velocidades cada vez más altas, de hecho, cuanto más amplio sea el catálogo de componentes, más rápida será tanto la conceptualización como el desarrollo de aplicaciones.
  • Flujo de comunicación: Esta es una de las partes más importantes del sistema de diseño ya que todas las decisiones que se tomen y que puedan ser transversales deberían pasar por el equipo de diseño y quedar reflejadas en el sistema para ser posteriormente reutilizadas.

Pongamos el caso de que para un producto surge una necesidad nueva, esta necesidad tiene que pasar primero por el equipo de diseño para que decida si todo o parte de esa funcionalidad puede ser incorporada como transversal al sistema de diseño y que incluso que el desarrollo de esos componentes transversales los asuma otro equipo. Una vez se hace esto y el equipo de diseño conviene que con lo que hay en el sistema se puede desarrollar la nueva necesidad, el equipo de desarrollo ya puede comenzar con la implementación.

Elementos de un sistema de diseño

Design tokens

Si volvemos al concepto de atomic design podríamos decir que los design tokens son una especie de partículas subatómicas dentro de nuestro sistema de diseño que nos ayudan a construir el lenguaje visual y mantener la coherencia.

En base a nuestro sistema de diseño podemos construir productos para diferentes plataformas (web, iOS, Android…) y todos ellos compartirán el mismo lenguaje visual. Lo que no comparten estas plataformas es la manera en la que trasladamos al código fuente todo lo que contiene el sistema de diseño, entonces… ¿Cómo lo solucionamos?, ¿Cómo hacemos que esto sea mantenible?

Para eso tenemos nuestros design tokens, se acabó buscar y reemplazar valores “hardcodeados” en los productos!. El nombre de un token va a hacer siempre referencia a un valor que en un determinado momento puede cambiar, pero solo tenemos una parte donde vamos a modificar este valor, el sistema de diseño.

Estos tokens pueden ser almacenados en un fichero con un formato estándar como puede ser un fichero JSON para posteriormente generar los recursos que necesitemos para el lenguaje/plataforma que estemos utilizando en nuestras aplicaciones.

Digital Lover

A continuación, mostramos un ejemplo de esto utilizando Style Dictionary, donde creamos un fichero que contiene tokens de color y de tamaño que posteriormente, utilizando un cliente de su librería podemos transformar a variables en la plataforma que necesitamos, en este caso transformado a formato CSS.

Tokens en formato JSON
Tokens en formato CSS
Uso de los design tokens

Componente

Los componentes son piezas reutilizables dentro de nuestro sistema de diseño que harán que nuestros productos sean consistentes y mantenibles.

Podemos encontrarnos las piezas más básicas a las que llamaremos “Building blocks” y con las que podremos construir otras piezas más complejas, pero igualmente reutilizables.

En el siguiente ejemplo podemos ver un ejemplo del building block botón sacado del sistema de diseño de Atlassian.

En este otro ejemplo de un componente dropdown formado por átomos proveniente del mismo sistema de diseño:

Componente dropdown

Patrones

Un patrón en un sistema de diseño es una solución que se da a un problema común. Esta solución se encontrará utilizando componentes y templates del propio sistema.

Un ejemplo de patrón es el que mostramos a continuación del sistema de diseño de Atlassian mencionado anteriormente para componentes y donde se puede ver la solución encontrada para el desarrollo de formularios.

Ejemplo de patrón de un sistema de diseño

Conclusión

La inversión de tiempo en la construcción de un sistema de diseño sólido aporta grandes beneficios a los ciclos de desarrollo de software:

  • Sirve de nexo y de medio de comunicación a equipos que habitualmente están desconectados y entre los que muchas veces hay malos entendidos, como puede ser el equipo de diseño y los equipos de desarrollo.
  • Ahorra tiempo y por tanto costes en el desarrollo de productos.
  • Hace que estos productos sean mucho más mantenibles y que reaccionen más rápido a cambios en el sistema.
  • Se encarga de mantener siempre una misma apariencia, usabilidad y funcionalidad de cara a todos los usuarios.

 

 

Tags

He leído y acepto la política de privacidad
Acepto recibir emails sobre actividades de recruiting NTT DATA