Design Ops
Next section
Siguiente sección
Product Design Handbook
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.
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:
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.
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.
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:
Estos principios tienen también una influencia clara a lo largo de nuestro proceso productivo.
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.
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.
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.
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:
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.
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:
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.
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:
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.
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:
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.
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).
Los tokens son intermediarios entre las foundations y la aplicación de estas en la interfaz.
Ventajas de utilizar tokens
En el sistema de diseño contamos con tokens de color, tipografía, layout y estilos de objeto.
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:
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.
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.
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.
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:
Dentro de cada página o archivo los elementos se organizan por frames.
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.
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:
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:
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.
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.
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:
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.
La jerarquía que sigue Figma para crear la ruta de componentes de una librería es la siguiente:
Quedando de la siguiente forma:
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:
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.
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.
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.
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?
