Soluto Design System, desde los ojos del equipo de diseño

2020 ha sido un año raro, eso no es nada nuevo. El caso es que en marzo nos fuimos a casa y pasamos oficialmente a ser un estudio en remoto. Esta nueva realidad nos hizo pensar y reflexionar sobre nuestra forma de trabajar, las metodologías, las herramientas que utilizábamos y sobre la comunicación entre el equipo. De todas estas reflexiones una de ellas estaba bastante clara: estábamos lejos, pero habría que estar más juntos e interconectados que nunca. Por esta y otras razones decidimos repensar nuestro proceso de diseño de producto y creamos un sistema de diseño. Y además, a mitad de proceso, nos cambiamos a Figma.

Una de las razones principales de cambiar a Figma fue el hecho de que todo el equipo pudiera trabajar en un mismo archivo, diseñar de forma colaborativa y tomar decisiones en conjunto. Este cambio nos ha traído una serie de mejoras en el proceso de trabajo de diseño y una de ellas ha sido el hecho de crear un sistema de diseño. Una vez que todo el equipo estaba ya trabajando de manera colaborativa en Figma, diseñar e implementar un sistema de diseño nos ayudó no solo a colaborar aún más, sino también a pensar de la misma forma, alinear nuestras decisiones, nuestro proceso de trabajo y nuestro lenguaje. Por fin empezamos a descubrir la magia de pensar en común con los desarrolladores, y nuestro equipo se mantenía más enfocado, conectado y alineado.

Así nace Soluto, el sistema de diseño de Soluble. Nace con el objetivo de optimizar el proceso complejo que es diseñar e implementar un producto digital. Un sistema de diseño y documentación que permite que el proceso de diseño de la interfaz sea más fluido entre el equipo de diseño y el de desarrollo. Establecimos un vocabulario compartido entre los dos equipos que nos ayudó a ser más coherentes en nuestros proyectos, y descubrimos que la coherencia contribuye de forma muy positiva a la usabilidad.

Ahora que llevamos ya varios meses poniendo en práctica este sistema y diseñando en Figma, aquí van algunas reflexiones y detalles de cómo ha ido todo.

Un sistema de diseño es la base para la escalabilidad, la eficiencia y la coherencia. Aumenta la velocidad y reduce los fallos a la hora de aplicar el diseño porque es la única source of truth y documentación de los proyectos. Necesita mantenimiento y actualización: nunca se termina de diseñar, sino que siempre va evolucionando de acuerdo con las necesidades de cada proyecto.

Soluto no solo ha ayudado con la coherencia y comunicación entre el equipo de diseño y desarrollo, sino que también ha contribuido y aportado valor a la hora de empezar un nuevo proyecto para alguno de nuestros clientes.

Es un punto de partida común y es muy útil tener este archivo como “base” para modificarlo y adaptarlo a cada proyecto en el que trabajamos. Así podemos ir más rápido y de forma mucho más eficiente. En otras palabras: nos permite aumentar la velocidad y mantener la coherencia, por muy complejo que el proyecto sea.

Ya hemos hablado sobre los motivos y objetivos, ahora vamos al detalle.

Soluto se estructura de la siguiente manera:

Los estilos son el conjunto de elementos que definen la marca y el sistema de diseño de la misma. Está formado por colores, tipografía, efectos y grids. Estos son todos los elementos que ayudan a reflejar la identidad visual de cada marca.

Cuando empezamos a trabajar en un nuevo proyecto y su sistema de diseño, la incorporación de los colores de cada marca en el propio sistema es clave. Nos ayuda a que cada sistema sea único y con la personalidad de la marca en toda la interfaz.

A la hora de definir la paleta de colores es muy importante pensar en la accesibilidad. No todos los colores tienen que ser accesibles, pero la mayoría debe cumplir este requisito. Por lo tanto, debemos tener en nuestra paleta un amplio conjunto de colores accesibles para que los podamos utilizar sin problemas en textos, componentes y fondos de la interfaz.

En cada sistema de diseño agrupamos los colores según las siguientes categorías:

• Colores de la marca — Estos colores están asociados a cada marca, se nombran según su importancia (primary, secondary, tertiarty…) y son los colores que dan la personalidad de la marca al producto.
• Colores básicos — Los colores básicos están formados por una paleta que va desde el blanco hasta al negro. Lo mantenemos en cada proyecto y les llamamos Basic Colors.
• Colores de soporte — Son el grupo de colores que nos ayuda en los mensajes genéricos de un producto (success, warning, error).

Otro de los puntos clave de cada sistema de diseño es la tipografía. A través de ella, cada marca puede reflejar su personalidad y comunicarse visualmente de manera fluida.

Definir los estilos de tipografía nos ayuda a ser coherentes en cada breakpoint, aporta jerarquía y ayuda en la lectura de toda la interfaz. Solemos utilizar como máximo dos tipografías en cada proyecto y la menor cantidad de pesos/tamaños de las mismas. Pero, la verdad, esto siempre depende del tipo de proyecto y de la marca.

Uno de los puntos clave a la hora de aplicar los estilos de texto en los distintos breakpoints es que los mismos estilos entre breakpoints deben llamarse igual. Por ejemplo, un H1 en resolución 1024 debe llamarse H1 en la versión móvil. Esto facilita mucho el trabajo al equipo de desarrollo, y a la vez ayuda a la mantenibilidad y coherencia a través de las distintas resoluciones de una web o producto.

Los nombres de los estilos se nombran de la siguiente manera:

[F1] / [Breakpoint] / [Peso] / [Nombre]

Cuando hablamos de efectos nos referimos a estilos de capa presentes en el sistema de la marca que nos ayudan con la coherencia y tono de la misma. Aquí categorizamos, documentamos y definimos los efectos necesarios para conseguir diferentes “elevaciones” en botones o modales, efectos como sombras y desenfoques.

Se nombran según el efecto y siguiendo una secuencia numeral desde el más plano a lo más “elevado”. Ejemplo: shadow-01

Para que podamos diseñar en un espacio ordenado y mantener el equilibrio en los productos que hacemos, nos dejamos guiar por grids o cuadrículas.

Las categorizamos por viewport grids y space grids.

• Viewport grids — Son un conjunto de columnas que nos ayudan a ordenar el espacio horizontal y se adaptan al tamaño de cada pantalla. Esto garantiza la coherencia entre los diseños.
• Spacing grids — Se basa en una cuadrícula de 8 píxeles y nos ayuda en las medidas a lo largo de cada página. Cada elemento de una página debe ser múltiplo de 8; esto incluye márgenes y paddings tanto en los componentes como en secciones de una página. Por ejemplo, cuando el único elemento de un componente es el texto (botones) configuramos el texto en un tamaño coherente con el resto del UI y luego utilizamos el padding para determinar el tamaño del mismo componente. El padding determinará la altura y el ancho del componente. Hay una excepción en esta escala: 4px para los casos de pequeños componentes y márgenes.

Como ya indicábamos antes, Soluto está compuesto por varios elementos (o componentes). Puede haber desde algo sencillo como un botón hasta algo más complejo y detallado como una modal. Documentamos todos los componentes y al final de cada proyecto analizamos y debatimos juntamente con el equipo de desarrollo si un componente que ha sido creado para un proyecto en concreto puede añadirse a este archivo “madre” que es Soluto. Así tanto desde diseño como desde desarrollo mantenemos Soluto actualizado y coherente para ambos equipos.

Ejemplo de Design System creado/adaptado al producto de Dozen

Soluto es un sistema de diseño en constante actualización y crecimiento, pero también es el punto de partida para cada proyecto. Con él, hemos optimizado el proceso inicial de un proyecto para ser más ágiles a la hora de crear los estilos y componentes que necesitamos. Ahora invertimos nuestro tiempo en personalizar y adaptar cada sistema a su marca y nos centramos en los aspectos más creativos: a rediseñar cada componente según los atributos, personalidad y valores de cada marca. Resolvemos los estados y comportamientos de cada componente y seguimos mejorando para documentar más, mejor y con un lenguaje que sea uniforme y común a todos.

Hasta ahora, nuestros componentes más comunes suelen ser:

• Botones
• Campos de texto
• Selectores
• Barra de navegación
• Listas
• Tablas
• Iconos

Hay proyectos donde los componentes son más complejos. En esos tenemos también:

• Modales
• Avisos
• Formularios
• Cards
• Buscadores
• Galerías de imágenes

Nos esforzamos en mantener el archivo de diseño ordenado, con una estructura coherente y pantallas con el nombre correcto. ¿Por qué? Pues porque esto acelerará todo a la hora de compartir y trabajar con otros miembros del equipo. Creamos una nomenclatura desde diseño que se mantiene en la parte de desarrollo y así todo funciona mejor, ya que hablamos y trabajamos sobre un mismo lenguaje.

Nombre de las páginas y orden de los archivos. Hemos desarrollado un sistema de nomenclatura que nos permite ser coherentes en cada archivo y nos permite que todos los elementos, artboards y pages estén ordenados, sean fáciles de encontrar por cualquier persona.

Igual que tenemos Soluto para el sistema de diseño (que nos sirve como punto de partida de cada proyecto), también tenemos un archivo template que estará conectado con el sistema de diseño de cada marca. Este archivo es el Soluble — Design File Template y lo duplicamos al principio de cada proyecto. En él es donde estarán diseñadas todas las pantallas de un producto y contiene 4 páginas principales:

• 📷 Cover — Es la forma más inmediata para que todo el equipo pueda tener una visión general sobre el estado en que está cada proyecto. Actualizamos el thumbnail siempre que el proyecto cambia de fase.
• 💡 Exploration — Todas las exploraciones realizadas para encontrar el camino que nos conducirá al diseño final.
• ✅ Design Ready — Pantallas/flujos ordenados por versión.
• ↳ [FASE]-[breakpoint]-[Versión] — Estas subpáginas están ordenadas por versiones para ayudar a mantener un control de versiones y marcar las entregas a cliente. Con frecuencia añadimos el emoji 🚧 para señalar las páginas donde estamos trabajando antes de compartirlo con el cliente. Y, por supuesto, una vez que lo compartimos, el emoji de WIP desaparece.
• 🤖 Dev Ready — Pantallas preparadas y documentadas para la fase de desarrollo. Go!

Nombre de las pantallas: Archivo organizado y con los nombres que tocan. Pero, además, tenemos unas reglas definidas a la hora de nombrar cada artboard de un diseño. Todas las artboards deben seguir esta nomenclatura, desde la fase de UX hasta exportaciones y entregables. Todo debe tener un nombre coherente y debe seguir el siguiente patrón:

[01.screen]/[01.status]

01.home/01.nav-bar-open

• Sin mayúsculas
• Las palabras deben estar separadas con solo un guion
• Puede o no haber status (dependerá de si el artboard en cuestión tiene o no varios estados)
• Los números nos ayudan a entender el flujo del producto y los estados que tiene cada artboard

Todas estas reglas han sido resultado de iteraciones que hemos hecho y probado en los últimos meses. Puede que vayamos cambiando a partir de ahora según nuestras necesidades, pero por ahora esto nos funciona.

En este punto es donde estamos aun mejorando y probando lo que nos resulta mejor en cada proyecto y situación. Está claro que documentamos más que ayer, pero esperamos que menos que la semana que viene.

Hasta ahora nuestro proceso es el siguiente:

• Organizamos los componentes en diferentes artboards para que podamos tener una visión global y a la vez todo ordenado y fácil de utilizar.
• Aparte de esta organización y documentación más visual, también hacemos una documentación más detallada cuando un componente o flujo necesitan atención. Por un lado, en el archivo de sistema de diseño de cada marca, donde documentamos comportamientos, micro-interacciones y estados. Por otro lado, en el archivo de diseño donde se encuentran todas las pantallas y flujos; aquí intentamos dejar descripciones, notas de uso y comportamiento cuando algo exige más detalle.

Nos gusta ser minuciosos en este proceso de documentación para que nuestro equipo de desarrollo pueda ir directamente al grano y hacer nuestros diseños reales y “usables”. Entendemos el diseño de producto como algo dinámico y no como algo estático. Y por eso es muy importante que cuando pasemos nuestros diseños a programación todo esté bien detallado para que pueda comportarse tal y como habíamos imaginado. Desde diseño somos los creadores de los productos, los que tenemos toda la información. Si no la pasamos bien a nuestro equipo tech el resultado que esperamos tardará más en llegar y daremos demasiadas vueltas en este proceso. Nadie quiere eso, ¿verdad?

Gracias por leer hasta aquí y por ayudarnos a dar la bienvenida a Soluto.

Maria Martins, UI Designer

PD: Esto ha sido todo sobre Soluto, desde el punto de vista de diseño de interfaz. Estamos reflexionando sobre el sistema de diseño desde la perspectiva de desarrollo. Seguiremos informando