Sistemas de diseño

Esta es la herramienta central en torno a la que gira nuestra metodología. Por ello, hemos creído oportuno dedicar un capítulo entero a explicar qué entendemos por sistema de diseño, qué principios de diseño nos guían a la hora gestionarlo y qué elementos componen nuestros sistemas a nivel morfológico.

¿Qué es un sistema de diseño?

Esta herramienta permite al equipo establecer patrones y contar con una serie de elementos que se pueden, y deben, reutilizar para crear funcionalidades. La modularidad del sistema es lo que permite crear desde una unidad mínima hasta componentes más complejos, así como establecer reglas que nos ayuden a trabajar en equipo de forma alineada a través de principios.Además, el sistema de diseño refleja el punto de unión entre el equipo de diseño y el de desarrollo. Gracias a él, conseguimos implementar un lenguaje claro y consistente a partir del cual crear y evolucionar productos.
Un sistema de diseño podría entenderse como:

  • Un lenguaje común.
  • Una balanza entre el control estricto y el caos que produce la libertad.
  • Una colección de elementos reutilizables guiados por una documentación clara.
  • Un conjunto de patrones y prácticas que se comparten dentro de un equipo de forma coherente y organizada.
  • Cada patrón describe un problema que ocurre con frecuencia y describe y propone una solución para este.

El sistema de diseño tiene que ser flexible y mantenerse vivo a largo plazo. Un sistema de diseño no es estático, sino dinámico. Evoluciona con el producto y su diseño.

¿Qué valor aporta?

Utilizar un sistema de diseño garantiza la consistencia de nuestros productos. Esto repercute de manera positiva en la experiencia de usuario y acorta significativamente los tiempos de ideación, desarrollo y elaboración de productos. Por otra parte, los sistemas de diseño son una herramienta especialmente útil para conseguir crear productos digitales capaces de escalar y crecer rápidamente de una forma controlada. Por último, pero no menos importante, permite dedicar el menor tiempo posible a detalles superfluos para pensar más y mejor en el producto.

Si bien presenta algunas similitudes, el sistema de diseño no es ni un manual de marca ni una guía de estilo, tampoco un sustituto de los mismos. Puede convivir con ellos y cada uno aporta valores distintos. La principal diferencia es que el sistema de diseño no es un documento estático de consulta que se limita a explicar cómo debe ser el aspecto de los elementos. Como ya hemos mencionado, el sistema de diseño es una entidad viva que contiene un lenguaje común, principios y herramientas que ayudan a construir productos coherentes.

Principios

A la hora de la toma decisiones relacionadas con la gestión de sistemas de diseño, nos guiamos por una serie de principios que compartimos todos los miembros del equipo. Gracias a ellos conseguimos sentar las bases de lo que consideramos un buen producto. En nuestra opinión, el diseño de sistemas debe ser:

  • Sistémico. El diseño visual se sirve de patrones y reutiliza elementos. Esto da coherencia y cohesión al producto y agiliza los procesos de creación y mantenimiento.
  • Reticular. El diseño debe utilizar un sistema de proporciones definido, para armonizar y organizar el conjunto.
  • Racional. El diseño visual se debe basar en decisiones lógicas y razonadas.
  • Estético. La calidad estética del diseño repercute directamente en la utilidad y usabilidad de los productos.
  • Comprensible. Nuestro reto es realizar productos autoexplicativos.
  • Multiplataforma. Unificar la experiencia de usuario entre las plataformas. Adaptando el producto a ellas.
  • Escalable. Una documentación clara permite que el sistema de diseño sea fácil de accionar y se adapte a nuevas situaciones y necesidades.
  • Consistente. El uso de patrones favorece la fácil adaptación de los usuarios y reduce la curva de aprendizaje.
  • Flexible. Fomenta la personalización dejando libertad para que se adapten a los objetivos finales del producto y funcionalidades.

Estos principios tienen también una influencia clara a lo largo de nuestro proceso productivo.

Principios específicos

Más allá de las reglas generales que nos sirven como premisa a la hora de utilizar un sistema de diseño, también dotamos a cada uno de una serie de principios particulares. Estos tienen el fin de proporcionar una personalidad única y propia al sistema. Por ejemplo, un sistema de diseño para una entidad pública podría establecer como principio la imparcialidad. Quien maneje este sistema debería ceñirse a esta máxima a la hora de crear funcionalidades que no influencien la toma de decisiones del usuario.

Cómo se forma el sistema

Cada sistema de diseño es único. Satisface las necesidades del producto que soporta. Para garantizar que el sistema de diseño funciona y cumple con sus principios y objetivos, lo entendemos como una serie de piezas que van alimentando unas a otras.

Foundations

Son los aspectos que definen el visual del sistema. En los sistemas de diseño, normalmente encontramos color, tipografía, iconografía, layout, espaciado y estilos de objeto. También pueden incluirse aspectos que definen el contenido, como tono, voz y fotografía, que nos ayudan a dotar al sistema de una identidad propia.

Las foundations representan la paleta total de recursos con los que podemos trabajar. Habrá algunos que se utilicen y otros que no. Estas alimentarán a los tokens, que serán los que finalmente se apliquen sobre la interfaz. Su objetivo es favorecer la toma de decisiones en la escalabilidad del sistema de diseño.

En 'Foundations' recogeremos escalas analizadas y estudiadas para garantizar su funcionamiento.

A continuación se recogen buenas prácticas para la definición de foundations en nuestro sistema de diseño.

Color

El color es un elemento muy importante de la comunicación visual, por ello, es necesario hacer un uso inteligente e intencional del mismo. A la hora de crear sistemas de diseño distinguimos los siguientes tipos de colores:

  • Neutral. Paleta de grises que dividimos en dos tramos, uno claro y otro oscuro. Las tonalidades que pertenecen al claro las aplicaremos sobre fondos, mientras que las que pertenecen al oscuro irán sobre elementos en primer plano, como textos e iconos. En caso de estar diseñando en modo oscuro, invertiríamos esta relación.
  • De marca. Colores normalmente asociados al branding, que definen y dan personalidad a la marca del producto*.* La función principal de estos colores es acentuar*.*
  • Tipográficos. Como mínimo se deben establecer un color oscuro y otro claro para utilizar en la tipografía. También se pueden establecer otros estilos de texto que tengan un color distinto a los mencionados.
  • Semantic: Colores que llevan asociado un significado. Estos son: rojo (negativo), naranja (advertencia) y verde (positivo).
  • Support: Colores con la riqueza suficiente como para funcionar a la hora de aplicarlos para categorización o sobre ilustraciones y fotografías.

En 'Foundations' definimos los colores por paletas de color en base al tono. Recogemos estos en base a escalas de 5 o 10 colores, dependiendo de la complejidad del sistema. Con esto queremos evitar el uso de transparencias y opacidades y fomentar el uso de colores "puros".

Para definir estas escalas, partimos, normalmente, del color central, el heredado de la paleta de color inicial, y realizamos incrementos y decrementos de Luminosity.

Ningún método sistemático puede automatizar por completo la creación de escalas de colores de forma general. Sin embargo, como punto de partida, puede funcionar subir 20 pt Luminosity para crear tonos más claros y bajar 5 pt para crear tonos más oscuros. La excepción estaría en el color más claro de la escala, para el cual cambia el valor L en 1 o 2 pt, ya que es el que se suele utilizar en las grandes masas como fondos.

Layout

Para organizar el espacio nos servimos de la retícula o grid. Esta es una herramienta de trabajo que nos ayuda a distribuir los elementos documentados en el sistema de diseño. Se debe utilizar de forma estructurada para crear los componentes funcionales que articularán el producto.

Esta retícula debe definirse matemáticamente proporcionando así las reglas que definen el tamaño y la posición de los elementos colocados sobre ella. De este modo, acotamos las posibilidades y agilizamos la toma de decisiones en base a un armonioso sistema de medidas proporcionales. En nuestro caso, establecemos dos variables que definen la retícula:

  • Columnas. Nos ayudan a estructurar el espacio horizontalmente. En función de las necesidades del proyecto, suele establecerse un número par de columnas, entre 2 y 12. Es necesario establecer: el ancho de cada columna, el espacio entre estas y el margen del grupo de columnas respecto a los bordes.
  • Línea base. Sirve para organizar el espacio verticalmente. Debe ser equivalente a la altura del interlineado del cuerpo de texto principal. De este modo, todos los elementos estarán alineados al mismo y transmitiremos sensación de orden.

Sizing

Si bien la unidad mínima de una retícula digital es el píxel individual, nuestro sistema se basará en una cuadrícula de incrementos verticales y horizontales de 8 píxeles. Debido a la importancia que tiene para nosotros esta forma de organizar la retícula, hemos decidido dedicarle su propio apartado.

Cada medida de la página debe ser múltiplo de 8. Eso incluye anchos de columna, márgenes, textos, iconos, imágenes, etc. Sólo procediendo rigurosamente de esta manera lograremos que todos los elementos estén perfectamente alineados.

Al aplicar la regla del 8 a la tipografía, hacemos una excepción y nos tomamos la licencia de establecer la línea base en múltiplos de 4. De este modo, ganamos versatilidad a la hora de establecer interlineados acordes al tamaño de la tipografía que generan una mancha de texto cómoda de leer. Por ejemplo, si nos ceñimos a múltiplos de 8, para una tipografía con un tamaño de 12 píxeles, 16 de interlineado podría ser insuficiente y 24 demasiado.

Hay casos puntuales en los que no es fácil tener claro cómo utilizar el grid de 8 puntos. Por ejemplo, en los elementos con una línea en el borde. En este caso, esta línea deberá estar definida de tal manera que ocupe espacio hacia el interior del botón. No contabilizaremos su grosor a la hora de medir el espaciado.

Excepciones a la regla

Hay proyectos y situaciones en las que la retícula de 8 es demasiado grande. En estos casos, el equipo estudia la posibilidad de utilizar una retícula global de 4 píxeles. De este modo, disponemos de más versatilidad a la hora de definir espaciados, proporciones y jerarquías en interfaces con mucha densidad de información.

Tipografía

Puesto que la letra escrita es la principal forma de comunicación visual, el buen uso de la tipografía es muy importante. Este buen uso facilita el proceso de lectura y hace fluida la experiencia del usuario. Además, la tipografía es una herramienta genial para dotar de una personalidad concreta a los diferentes proyectos y establece un tono comunicativo acorde a esa personalidad.

Cada tipografía tiene sus particularidades y establecer dogmas sobre los valores numéricos que deben seguir no siempre funciona. Sin embargo, unas premisas generales que nos pueden ayudar a estructurar la información y componer los textos podrían ser las siguientes:

  • Establece jerarquías bien diferenciadas entre los distintos tipos de información. Para ello, puedes valerte de diferentes tipografías, pesos, tamaños, colores, etc. Una interesante forma de definir las distintas jerarquías para un sistema es establecer, en primer lugar, los valores del cuerpo de texto, para a partir de ahí definir el resto.
  • Un interlineado entre 1,4 y 1,6 veces el tamaño de la tipografía suele funcionar para cuerpos de texto. Para destacados y titulares reducimos ese rango a 1,2-1,4.
  • Controla el largo de la línea del cuerpo de texto. Lo recomendable para una buena experiencia de lectura son entre 45 y 75 caracteres. Puedes encontrar más información sobre este tema aquí:
    Artículo
  • Cíñete a una o dos tipografías y utiliza la menor cantidad de variaciones posibles de pesos de la misma. Esto es principalmente por cuestiones de rendimiento en webs y apps.

Como punto de partida a la hora de establecer interlineados acordes al tamaño de la tipografía, contamos con una regla de incrementos para determinar los distintos tamaños y altos de línea asociados.

En 'Foundations' recogemos el catálogo de tamaños tipográficos que se pueden utilizar en la interfaz.

Iconografía

La iconografía representa de forma visual conceptos complejos que, de un vistazo, trasladan información útil al usuario. Debe ser usada con mesura y de forma clara, sin dar lugar a mensajes ambiguos.

Dentro del sistema de diseño, agrupamos los iconos en función de su tamaño. Partimos de unas medidas mínimas de 16 px y escalamos hacia arriba en múltiplos de 8 px en función de las necesidades de cada sistema. Para asegurar que todos los iconos de un tamaño determinado tienen las mismas proporciones, los insertamos sobre un fondo cuadrado transparente con esas medidas totales.

Es importante definir las propiedades formales de los iconos para que exista un código de unidad visual entre ellos. Pueden existir tanto iconos a línea como creados a partir de formas sólidas. Ambos comparten propiedades visuales que se pueden definir por:

  • Grosor de línea. Es importante establecer un grosor estandarizado para todo el grupo de iconos. Incluso aquellos creados a partir de formas sólidas podrían llegar a hacer uso de líneas en algún momento.
  • Terminaciones. Por norma general, pueden ser rectangulares o redondeadas.
  • Esquinas. Normalmente pueden ser: angulares, redondeadas o con bisel.

Estilos de capa

Clasificamos dentro de este apartado ciertas características que, por su naturaleza global, están presentes en muchas de las piezas que componen el sistema y ayudan a dotar al mismo de un tono y una voz propia.

En esta categoría encontramos una miscelánea de valores que podemos aplicar, como, por ejemplo, la redondez de los bordes de las formas, sombras que proyectan, desenfoques, etc.

Tokens

Los tokens son las variables que se asocian a foundations para dotar al sistema de consistencia y flexibilidad visual. La nomenclatura de los tokens es agnóstica a sus valores, ya que estos pueden cambiar o ser dinámicos (theming).

El proceso de tokenización consiste en sustituir elementos sensibles con su equivalente no sensible.

Los tokens son intermediarios entre las foundations y la aplicación de estas en la interfaz.

Ventajas de utilizar tokens

  • Será más fácil mantener la consistencia.
  • Facilitan la toma de decisiones.
  • Fomentan la escalabilidad.
  • Propagación automática de cambios.
  • Optimización de recursos.

En el sistema de diseño contamos con tokens de color, tipografía, layout y estilos de objeto.

Components

Por definición, todo sistema está compuesto de elementos que lo articulan y le dan sentido. Para hacer viable el trabajo en equipo con los sistemas de diseño es indispensable utilizar un lenguaje común y autoexplicativo para nombrar los distintos elementos. Basándonos en su naturaleza, nosotros proponemos la siguiente clasificación:

  • Action
  • Content
  • Input
  • Navigation
  • Feedback
  • Overlay

Esta agrupación, según el uso, acción o problema que resuelve el componente en el sistema de diseño, facilita el uso y consumo del sistema de diseño en Figma, así como su documentación.

Patterns

Los patterns o patrones son soluciones que, mediante el uso de componentes, resuelven necesidades recurrentes en los productos.

Ejemplo: Un campo de texto permite introducir datos (tiene sentido por sí mismo), pero en el momento de combinarse con otros datos, botones, etc., puede generar un módulo que adquiere una función más global, como un formulario de registro.

Otro ejemplo sería un pie de página. A menudo, se conforma de enlaces que en sí mismos tienen sentido, como links a otras páginas, pero en su unión adoptan una funcionalidad más global, que es la de navegación.

Nomenclatura y documentación

Para que un sistema de diseño tenga sentido en sí mismo debe tener una documentación clara que recoja la información suficiente para que pueda ser utilizada. Esta debe satisfacer las necesidades de todas las personas que trabajen y consuman el sistema de diseño: diseñadores, desarrolladores, product owners y product managers... Por tanto, no existe una documentación ni nomenclatura global que sirva para todos los sistemas de diseño, sino que esta debe adaptarse a las necesidades del producto al que da soporte.

A continuación, se recogen una serie de recomendaciones para documentar y nombrar los elementos que conforman el sistema. Esta guía se basa en cómo se han construido y se mantienen los sistemas de diseño de Inditex, BNEXT o Repsol, entre otros.

Dependiendo de la complejidad del producto y del sistema de diseño, los elementos convivirán o no dentro del mismo archivo o, por defecto, librería de Figma.

Si el sistema de diseño es pequeño y su complejidad es baja, es recomendable mantener el sistema de diseño en un mismo archivo con el fin de facilitar su uso, diferenciando los elementos en páginas.

  • Foundations y tokens.
  • Components.
  • Patterns.

Sin embargo, si un sistema de diseño es complejo, la mejor opción es diferenciar los elementos que veíamos anteriormente en 'Archivos', en lugar de por páginas.

¿Cuándo tiene sentido hacer la diferenciación por archivos?

A continuación se recogen dos ejemplos de esta situación:

  • El sistema de diseño da soporte a múltiples plataformas: Web, iOS, Android.
  • El sistema de diseño tiene muchos componentes y patrones porque da solución a múltiples casuísticas.

Dentro de cada página o archivo los elementos se organizan por frames.

Foundations y tokens

En nuestros sistemas de diseño distinguimos entre 'Globales' y 'Específicos', siendo globales las foundations y específicos los tokens, que se aplicarán sobre la interfaz final.

Color

El frame de 'Color global' lo estructuramos mediante escalas de color, nombrando estos por su propia naturaleza. Por ejemplo: rojo, azul, gris.

Global / [Color] / [Número]

El número hace referencia a su posición en la escala. En una escala de 10, tendríamos: Color 10, Color 20, Color 30, Color 40, Color 50, Color 60, Color 70, Color 80, Color 90 y Color 100. Si tenemos una escala de 5, solemos mantener esta numeración, quedando: Color 10, Color 30, Color 60, Color 70 y Color 80. Esto es así por dos motivos:

  • Permite añadir más colores a posteriori y que la nomenclatura utilizada siga siendo válida.
  • Están más acordes a lo que sería una escala de 10.

Un ejemplo sería: Global / Rojo / 20

El frame de Color Específico lo estructuramos y nombramos mediante usos que tiene el color. Distinguiendo normalmente los siguientes usos:

  • Content.
    Colores que se utilizan sobre textos.
  • Border.
    Colores que se aplican sobre bordes.
  • Semantic.
    Colores que llevan asociado un significado. Como por ejemplo son rojo (negativo), naranja (advertencia) y verde (positivo).
  • Support.
    Colores con la riqueza suficiente como para funcionar a la hora de aplicarlos para categorización o sobre ilustraciones y fotografías.

De cada uno de estos podemos sacar su grupo state que nos permiten definir cómo se comportaría el color ante un estado como hover, pressed, focus.

Specific / [Uso] / [Distintivo]

Como distintivo se pueden utilizar números o cualquier particularidad que caracterice al uso.

Un ejemplo sería: Specific / Content / 1

Otro ejemplo: Specific / Semantic / Danger

Tipográfico

Para la tipografía también contemplamos un frame 'Global' y otro 'Específico'. En el primero, recogemos una guía de familia, pesos, interletrados y tamaños permitidos. Mientras que, en el segundo, especificamos qué combinación de estos se utilizará para cada uso. Para la nomenclatura de tokens de tipografía seguimos la misma lógica que para los tokens de color.

Specific / [Uso]

Un ejemplo sería: Specific / Title 1

Además, podremos contar con tipografías dinámicas, es decir, que se adapten en función de la resolución. Para documentarlas, añadiremos el nombre de la resolución antes del uso, de la siguiente manera:

Specific [Nombre resolución] / [Uso]

Un ejemplo sería: Specific M / Title 1

Esta lógica se aplicará para todas las foundations y tokens que contenga el sistema.

Para documentar foundations y tokens utilizamos la siguiente plantilla.

Nomenclatura de componentes

Importante a tener en cuenta sobre Figma

La jerarquía que sigue Figma para crear la ruta de componentes de una librería es la siguiente:

  1. Nombre de la librería.
  2. Nombre de página donde residen los componentes*.
  3. Nombre del frame donde se sitúan los componentes*.
  4. Nombre del componente.

Quedando de la siguiente forma:

[1] / [2] / [3] / [4]

Si el nombre del componente incluye "/", Figma lo contemplará como un nivel adicional.

*Si en el archivo solo hay una página que contiene componentes (Master Components), Figma omitirá este nivel.

*Si dentro de la página se sitúan todos los componentes en el mismo frame, Figma omitirá este nivel.

Teniendo en cuenta cómo gestiona Figma los niveles, el nombre que le damos al componente seguirá la siguiente estructura:

[Nombre] / [Variante] / [Estado] / [...]

Un ejemplo sería: Button / Primary / 01 Default

Se pueden añadir propiedades adicionales separadas por "/". Si queremos que los componentes se muestren en un orden determinado al utilizar la librería es importante que le añadamos una numeración al inicio de la propiedad, como ocurre en el ejemplo anterior con la propiedad Estado.

Para que nos forme la ruta correcta y cumpla con la función de facilitar la toma de decisiones y el uso y consumo del sistema de diseño, documentamos los componentes en frames. Contaremos con los siguientes frames como base e iremos metiendo los componentes dentro de estos.

  • Action.
  • Content.
  • Input.
  • Navigation.
  • Feedback.
  • Overlay.

Es importante acompañar a los componentes de una guía de uso. Esta la realizaremos sobre los propios frames donde dejamos documentados los componentes. Es imprescindible comunicar al equipo las decisiones tomadas detrás de un componente de cara a la implementación, al uso y a futuras decisiones que se lleven a cabo. A continuación, se propone un checklist a tener en cuenta al realizar la documentación de un componente.

  • Estados. Default, Active, Focus, Error, Disabled.
  • Escalable. Está construido de forma que el componente pueda escalar, ya sea con el contenido o manualmente (autolayout y constraints).
  • Variaciones. ¿Puede presentar alguna variación? Documentar cuándo hay que utilizar cada una de las variaciones y, si en función de ello, cambia algún aspecto más (when to use, posicionamiento, action...).
  • Posicionamiento. ¿El elemento se debe situar en algún sitio en concreto de la vista? Si es así, debería contemplarse en el sistema.
  • Behavior. Animaciones, transiciones, orden de aparición...
  • Anatomy and content. Si hablamos de los componentes o elementos que forman parte de un componente, detallarlos para que quien consuma el sistema de diseño pueda ir directamente a su documentación y conocer su comportamiento. También es importante tener en cuenta si los elementos que lo forman se pueden sustituir por otros (variaciones).
  • Overflow content. Este es el aspecto más presente a tener en cuenta a la hora de detallar un componente porque se dará siempre que haya texto. ¿Cómo crece el contenido, el texto?¿Está ligado a alguno de los aspectos anteriores (anatomy, posicionamiento...)?
  • Action. ¿El componente siempre va ligado a la misma acción? Ejemplo: Close Modal ❌ puede guardar los datos, no guardarlos, tener que lanzar un aviso de que se perderán los datos; el submit button siempre lleva a la misma vista, guarda los datos, lanza una acción concreta.
  • When to use para componentes que no son "básicos", sino que se utilizan por alguna particularidad. Ejemplo:
    Sheets

El objetivo de este checklist es facilitar la toma de decisiones a todas las partes que trabajen con el sistema. Desde los diseñadores que utilicen el sistema hasta los desarrolladores que se encarguen de su implementación.

Para que el comportamiento específico del componente, en caso de que lo tuviera, llegue al trabajador que está trabajando con el sistema, es recomendable incluirlo en la descripción del componente. El objetivo es llegar a quien utiliza el sistema. Un ejemplo de esto sería: posicionamiento, text overflow, número máximo de líneas, etc.

La misma lógica que utilizamos con los componentes la podemos aplicar para documentar patterns.

Authors and co-editors

Autores y colaboradores

Patricia Pérez

Head of People

Alvaro Bajo

Design Systems Lead
Design Ops
Next section
Siguiente sección

Let’s talk

We help your business thrive through strategy and design. And while we’re at it, we have fun doing it. How can we help you?

Anterior
Anterior