# Guía de Sistemas de Diseño By Far Co ![](https://3589795035-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MQEMIjbz11E6fFLsabr%2F-MQEN2PQDeHE6ak3z1AT%2F-MQENcCg6TFGnHTZmuR4%2FFarCo_Image.jpg?alt=media\&token=448e8864-7348-4392-a8b1-dec8da4268d8) ¡Hola! Qué bien tenerte por aquí. Antes que nada, deja que nos presentemos. Somos [Far Co](http://thefar.co/), un estudio de diseño con oficinas en Atlanta y Madrid. Nuestro foco está en el diseño de productos digitales desde un prisma de calidad e innovación y en el desarrollo de sistemas de diseño que permitan que esos productos escalen bien dentro de la organización.\ \ Este 'playbook' es la guía que solemos usar para ayudar a nuestros clientes a construir sistemas de diseño potentes, tanto a nivel de escalabilidad como de flexibilidad, creatividad o a nivel funcional. Hemos ido refinando este proceso a lo largo de muchos proyectos con grandes organizaciones globales como **BBVA** o **Repsol** (ayudándolas en su proceso de transformación digital) así como diferentes start ups y scale ups como **Dokify**, en una búsqueda constante de construir productos increíbles de forma eficiente. {% hint style="info" %} [Aquí](https://www.linkedin.com/pulse/launching-oxygen-our-digital-design-system-energy-gonzalez-bermejo/?trackingId=8YuGXeUyROWvCcchnEFngA%3D%3D) puedes ver más acerca de el [sistema de diseño de Repsol (Oxygen)](https://www.linkedin.com/pulse/launching-oxygen-our-digital-design-system-energy-gonzalez-bermejo/?trackingId=8YuGXeUyROWvCcchnEFngA%3D%3D), lanzando hace poco (en Dicimebre 2020) y en el que en la actualidad estamos colaborando activamente. {% endhint %} Hemos escrito esta guía pensando en un documento que pueda servir de ayuda a muchos perfiles diferentes, independientemente de su nivel de expertise. Siéntete libre de saltar las partes que te resulten más familiares y, si así lo deseas, vete directamente a lo que más valioso sea en este punto para ti y para tu equipo.\ \ Creemos mucho en nuestra visión y metodología tras muchos años de experiencia construyendo productos digitales. Sin embargo, este 'playbook' es un documento vivo, e irá evolucionando a lo largo del tiempo en función de nuevos aprendizajes, feedback recibido o nuevas experiencias vividas.\ \ Para cualquier pregunta o comentario, puedes escribir directamente a . \ \ ¡Y eso es todo! Bienvenidos una vez más, y disfrutad de la lectura. Esperamos de veras que os ayude.\ \ El equipo de Far Co # Sistemas de diseño Antes de empezar a hablar de los sistemas de diseño aplicados al mundo digital y cómo pueden ayudar a tu producto o empresa, vamos a dar un pequeño paso atrás. Hablemos antes de qué es eso de 'sistemas de diseño' o qué es el diseño sistemático, ya no en entornos digitales, si no en nuestro día a día. Así seguro que el aterrizaje es más suave y vamos a entender mucho mejor lo que viene después. Mira tu casa por ejemplo. Seguramente tengas algún mueble de IKEA por ahí, ¿no? Bueno, pues IKEA es un ejemplo increíble de qué son los sistemas de diseño. Para explicarlo mejor, vayamos a un ejemplo más concreto: la estantería Billy. A todos nos encanta y muchos la tenemos en casa. ¿Qué tiene de especial? Pues que todas las diferentes Billy's se pueden combinar de muchas formas distintas para cubrir funcionalidades muy diferentes. Todas ellas encajan genial entre sí y permiten una gran libertad partiendo de unos patrones muy claros. ![](https://3589795035-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MQEMIjbz11E6fFLsabr%2F-MQEXPodXqKp5g_QXrHm%2F-MQEY4sBPYdQu6w9AiGG%2Fbilly.jpg?alt=media\&token=de028bd6-873e-4432-88bc-9cd567f31040) Otro ejemplo, antes de profundizar más en los por qués. Vamos con uno muy típico y con el que todos hemos jugado alguna vez de niños (y no tan niños). Los Legos. Sí, incluso algo que parece un juguete infantil realmente esconce un sistema de diseño increíblemente bien pensado. ![](https://3589795035-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MQEMIjbz11E6fFLsabr%2F-MQEXPodXqKp5g_QXrHm%2F-MQEYeJCGwqK3QP2z4pY%2Flego.jpg?alt=media\&token=9bf02bd2-4078-418c-a36c-de2e34737851) Vale, pero...¿por qué estos son grandes ejemplos de sistemas de diseño en nuestro día a día? Pues porque... * **Son versátiles.** Puedes combinar diferentes elementos (tanto en el caso de la Billy o los Legos) y crear algo único partiendo de la combinación de esas partes más pequeñas. * **Están estandarizados.** Ambos, IKEA o LEGO, usan medidas concretas (tamaño, dimensión...) siguiendo una serie de patrones que hacen que puedan cumplir su propósito pero que además, sean perfectamente combinables entre sí. ¿No es genial cuando compras varias Billys y la altura de la pequeña queda justo a la altura de un estante concreto de la grande, y cuando las combinas parece que fuesen un todo concebido así desde el principio? * **Están creados pensando en la eficiencia para negocio.** IKEA diseña todos sus muebles siguiendo una serie de patrones que repiten en muchos muebles, permitiendo ahorrar costes en la producción y en transporte, igual que LEGO para la producción y el almacenamiento. **Podríamos seguir pensando ejemplos y hablando de esto todo el día. Los ejemplos en nuestro día a día son infinitos. Los sistemas de diseño están por todas partes.** Vas viendo un poco por donde vamos, ¿no? Un sistema de diseño es un grupo de elementos interelacionados que juntos forman un todo. Y los patrones y reglas que los definen y que comparten entre sí, tienen unos enormes beneficios a nivel de consistencia, eficiencia o coste. Vale, pues ahora vamos a llevarnos este concepto al mundo digital. Es hora de hablar de sistemas de diseño en un producto digital. # Sistemas en el mundo digital Un sistema de diseño es una herramienta que permite a los equipos establecer patrones de uso para construir productos digitales. Estos patrones son elementos o prácticas reutilizables a lo largo de todo el ecosistema de productos y cuya reutilización tiene un impacto enorme en la consistencia y la eficiencia. Los sistemas parten de una premisa modular, permitiendo que los elementos escalen para dar soporte desde las funcionalidades más básicas a las más complejas (igual que una Billy podía combinarse para formar un todo más grande y dar soporte a funcionalidades muy diversas). {% hint style="info" %} #### **Un sistema de diseño en un conjunto de patrones interconectados y de prácticas compartidas, todo ello organizado coherentemente al servicio del propósito de un producto digital.** {% endhint %} ## Características de un sistema de diseño Un sistema de diseño crea un lenguaje común entre los equipos de diseño y desarrollo, definiendo reglas que se cimientan en unos principios muy claros. ![](https://3589795035-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MQEMIjbz11E6fFLsabr%2F-MQHSfUCrOyN588QVUfZ%2F-MQYPEzVcSbBpgYebWDA%2Fdestacados2.jpg?alt=media\&token=93889136-e1f6-4435-8b0c-0fbe98fcd79c) Las soluciones deben funcionar tanto para proyectos y equipos pequeños, como para los más grandes. ![](https://3589795035-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MQEMIjbz11E6fFLsabr%2F-MQHSfUCrOyN588QVUfZ%2F-MQYPIR6W81V-HRKIq64%2Fdestacados5.jpg?alt=media\&token=2f78ab34-0f10-4a60-a355-b5ea346bbf5d) Los patrones comunes a lo largo del sistema son lo que hacen que sea tan eficiente y que la calidad no se pierda conforme van surgiendo más y más proyectos. ![](https://3589795035-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MQEMIjbz11E6fFLsabr%2F-MQHSfUCrOyN588QVUfZ%2F-MQYPMLTnV0lSJ0vHTkh%2Fdestacados1.jpg?alt=media\&token=4d437248-62a6-48e5-8207-6a5dadc0b2f6) Las guías de uso que vamos a generar son claras sin que eso suponga limitar las posibilidades de innovación (¡esto último es importante y muchas veces se deja de lado!) ![](https://3589795035-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MQEMIjbz11E6fFLsabr%2F-MQHSfUCrOyN588QVUfZ%2F-MQYPPLK1Hqlw1vrG83x%2Fdestacados4.jpg?alt=media\&token=c0527d5a-df47-4638-be9a-93a10081b475) Las decisiones se deben tomar pensando en la cultura de la compañía y el ecosistema digital completo. ![](https://3589795035-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MQEMIjbz11E6fFLsabr%2F-MQHSfUCrOyN588QVUfZ%2F-MQYPSGOb0uoTvAW8Dl5%2Fdestacados3.jpg?alt=media\&token=a740e7be-6c1a-4fd3-bf8f-ffca47e3130a) El uso y el rendimiento del sistema de diseño pueden ser medidos con sumo detalle de forma que podamos probar su valor y retorno con datos reales. ## Una herramienta escalable y dinámica Un sistema de diseño (como hemos visto) es flexible y continúa evolucionando a lo largo del tiempo, en función de los objetivos de negocio, los diferentes test de usuario que se vayan haciendo o incluso las tendencias del sector y los espacios para innovar dentro del propio sistema. Una de las principales diferencias entre un sistema de diseño y una guía de estilo es esa precisamente — un sistema de diseño es escalable y dinámico. A diferencia de lo que antaño era entregar una guía de estilo en un momento concreto del proyecto, en un sistema de diseño la colaboración entre diseñadores y desarrolladores es contínua. Por eso, recomendamos encarecidamente que **el sistema de diseño sea tratado como un producto** **y no como un proyecto** dentro de tu empresa. Los sistemas de diseño están siendo adoptados cada vez por más equipos que trabajan en entornos ágiles, permitiendo a las empresas **construir productos más rápido y ahorrar muchísimo tiempo y dinero.** {% hint style="info" %} Siempre recomendamos que un sistema de diseño sea tratado **como un** **producto** en constante evolución y **no como un proyecto** con un principio y un fin dentro de tu empresa. {% endhint %} # ¿Qué beneficios tienen? Usar un sistema de diseño y los patrones que definamos aseguran la consistencia entre todos nuestros productos y entre todos los equipos involucrados, ya sean de diseño o desarrollo y ya sean internos o externos. | Patrones |

Equipos de diseño
internos/externos

|

Equipos de desarrollo
internos/externos

| | ---------------- | --------------------------------------------- | ------------------------------------------------- | | Marca | ✔️ | ✔️ | | UX | ✔️ | ✔️ | | UI | ✔️ | ✔️ | | Animación | ✔️ | ✔️ | | Desarrollo Front | ✔️ | ✔️ | Esto mejora la experiencia de usuario (el usuario no tiene que reaprender a hacer algo cada vez que pasa de tu app a tu web, por ejemplo) y acorta de forma significativa el **time to market** y el **tiempo que tardas en corregir un error** (si todo está formado por piezas, es más fácil localizar en qué pieza está fallando algo). Los sistemas de diseño son esenciales para **escalar productos de forma eficiente** entre diferentes equipos y unidades de negocio. Y lo que es más importante: todo esto significa que puedes invertir más tiempo en innovación y **ahorrar mucho dinero por el camino.** ## Principales beneficios de tener un sistema de diseño El más evidente es la eficiencia, que se traduce en **tiempo y dinero.** Pero un sistema de diseño también ayudará a tu producto o tu empresa a: * Asegurar que tu producto sea accesible * Potenciar la autonomía de los equipos * Escalar tu producto * Reducir riesgos * Tomar decisiones basadas en datos * Hacer el onboarding a nuevos miembros * Ser innovador (sí, ¡los sistemas de diseño deben serlo!) * Gestionar la deuda técnica que tengas * Asegurar la consistencia entre productos * Tener un lenguaje común entre equipos # Retorno: casos de éxito ## Lloyd's Bank / Constellation ![](https://3589795035-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MQEMIjbz11E6fFLsabr%2F-MUxpL7WhGKMBJeBoAIB%2F-MUxpVyrcCn741q5mB09%2FScreenshot%202021-03-04%20at%2016.12.49.png?alt=media\&token=9d8e3d3f-b05b-4c9b-8701-13faa8e9ff69) A través del uso de su sistema de diseño Constellation, Lloyd's Bank ha reducido su time-to-market por mitad y ha calculado **un ahorro de costes de £190.000** cada proyecto. ## IBM / Carbon Design System ![](https://3589795035-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MQEMIjbz11E6fFLsabr%2F-MQEfrrerBorUfKYk-xL%2F-MQEgmPEo-xCSUFTRUWr%2Fcarbon.jpg?alt=media\&token=6b24b1e6-46d6-45b6-8fb4-4c1f58acbada) En el core de la metodología de Design Thinking de IBM, está su sistema de diseño: Carbon. Forrester concluyó que tuvo un impacto financiero enorme en 3 años: 48,4 millones de dólares de beneficio vs un coste de 12 millones, lo que se traduce en un valor de 36,4 millones de dólares y un ROI (retorno de la inversión) del 301%. {% hint style="info" %} Los sistemas de diseño **ahorran tiempo y dinero**. Un ejemplo rápido: sólo eliminando el código redundante en programación, se puede liberar más del 20% del tiempo de los desarrolladores. Para un equipo de 100 desarrolladores, **esto se traduce en unos 2 millones de dólares al año.** {% endhint %} ## Sipgate / Unsere ![](https://3589795035-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MQEMIjbz11E6fFLsabr%2F-MUxpL7WhGKMBJeBoAIB%2F-MVQgi01HGH5mmNLzQOu%2FScreenshot%202021-03-04%20at%2016.19.43.png?alt=media\&token=d3c50a2c-f29e-4023-aadc-211053ffe2dd) "Tener una librería de patrones en Sipgate nos ha permitido **construir paginas 10-20 veces más rápido** de lo que nos lleva construir aquellos productos que no están conectadas a la librería." Tobias Ritterbach, Experience Owner # ¿A quién hay que involucrar? Para conseguir el mejor resultado posible, es importante empezar pensando en la gente que debe estar involucrada en la creación del sistema. Al principio, lo más obvio es pensar en incluir a diseñadores y desarrolladores. Y sí, sin duda esos deben estar fuertemente involucrados. Pero en nuestra experiencia (especialmente con empresas muy grandes) es importante incluir a otros perfiles (como personas claves de negocio) al comienzo del proceso. ## **Perfiles recomendados del equipo de diseño** * UX/UI Designers * Desarrolladores * Content Strategists (para partes como el tono y la voz del sistema, por ejemplo) * Researchers (para testar el sistema y obtener insights valiosos) Para nosotros, **todos estos perfiles son parte del equipo de diseño.** Si tu equipo tiene una estructura diferente no hay problema, pero a lo largo de esta guía hablaremos mucho de 'equipo de diseño', y cuando lo hagamos, que sepas que no hablaremos sólo de diseñadores visuales, si no de todos los perfiles involucrados en el diseño del producto. Al final, un equipo de diseño es mucho más amplio de los que a veces podemos pensar. ## **Stakeholders adicionales (e importantes)** * Leaders (VP's y dirección, para defender y alinear la visión en toda la empresa, incluido el C-level) * Equipos de negocio * Equipos de marca * Equipos de producto **No te asustes. No tienes que incluir a toda esta gente desde el principio.** Que esto no sea una barrera en este punto. Tan sólo queremos que tengas en mente que un sistema de diseño no es sólo cosa de diseñadores o desarrolladores. Va a haber mucha más gente que se va a beneficiar de tener un sistema de diseño en la compañía, o que puede aportar mucho para lograr un resultado increíble. Así que lo dicho, no te olvides de incluirles cuando sea el momento adecuado. # Empezando el sistema ## Cosas que debes tener en cuenta al empezar * Ten claros cuáles van a ser tus **KPI's** a corto y a largo plazo. * Cerciórate de que entiendes la **cultura** de la compañía y de que entiendes cómo los diferentes equipos construyen el producto. * Asigna un equipo de diseñadores y desarrolladores para que empiecen a trabajar en esto **juntos**. * **Elige un producto** para construir las librerías iniciales. Uno que sea importante para la estrategia de la compañía. Empieza con algo pequeño, crea algo increíble y crece desde ahí. * Define el ecosistema de productos de tu compañía para entender cuál va a ser el **alcance** del sistema de diseño. * **Documenta** todas las decisiones que se vayan tomando y todo lo que vayas generando para que el sistema se pueda compartir y entender fácilmente. {% hint style="info" %} Elige un producto concreto para construir las librerías iniciales. Uno que sea importante para la estrategia de la compañía. Empieza con algo pequeño, crea algo increíble y crece desde ahí. **No crees el sistema y luego el producto.** Crea el sistema y las normas a partir de un producto increíble que hayas diseñado. {% endhint %} Los patrones de diseño que vayas generando se compartirán y se usarán a lo largo de todos los productos digitales de la compañía, convirtiéndose en el estándar de calidad de tu UX/UI. Si estás buscando elevar la calidad del diseño de tu compañía, tienes ante ti una oportunidad increíble mientras creas el sistema de diseño. **No añadas nada al sistema que no quieras que se reutilice en el resto de productos de la compañía.** ## **Un sistema de sistemas** Como decíamos más atrás, el objetivo es desarrollar una solución que pueda escalar a todos los touchpoints (es decir, web, app, etc) de tu compañía. Por eso, es importante tener clara la cantidad de puntos de contacto que el sistema necesita cubrir. Por ejemplo, si tu producto tiene presencia en web, móvil o TV entonces vas a necesitar pensar en tu sistema como una familia de sistemas de diseño (uno para cada touchpoint o punto de contacto) todas ellas unidas a un core (Foundation). ![](https://3589795035-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MQEMIjbz11E6fFLsabr%2F-MQYWTovIDsNnzkdQAMX%2F-MQYYSddz3KmFzbT2sM_%2Fgraphic2.jpg?alt=media\&token=064c0e8a-d483-42bc-8868-2a377c923bb8) ### **Tier 1. Principios de Diseño y el Foundation System** El sistema parte de unos cimientos globales que se reflejan en la librería de Foundations y que define los patrones que todos los equipos deben usar. Esta librería incluye patrones globales como los colores de marca, tipografía, uso de la animación, espaciado, copys (tono de voz) o accesibilidad. Aquí es donde definiremos los 'design tokens'. Lo veremos más adelante. Esta base es algo que todo el mundo debería usar y es el mínimo que todo producto debería cumplir para salir a la luz. ### **Tier 2. Un sistema (materializado en librerías) por cada 'touchpoint'** Cada touchpoint (web, app, etc) puede tener sus propias librerías que comparten componentes y normas. Estas librerías deben estar compartidas con todos los equipos. Por ejemplo: **Un sistema web** define de todas los elementos que te encuentras en una web: botones, cuadros de diálogo, formularios, etc. Este sistema para la parte web se traduce en una librería de componentes y prácticas compartidas que pueda ser usado en cualquier producto que sea una web, desde una web-app a la página corporativa de la compañía, por ejemplo. Y aparte de todo lo específico que tiene el sistema en la parte web, también usaremos todo lo incluído en la librería de Foundations. Los componentes se construyen con tokens (como el color o la tipografía) y estos componentes siguen los patrones definidos en el Foundation System. Así, se crea un sistema conectado. Y en otro ejemplo, **un sistema app** es el lugar donde están todos los componentes y prácticas compartidas por todos las apps de la compañía (tanto móvil y tablet como iOS y Android). Y de nuevo, utilizaremos aparte todo lo que ya estaba en la librería de Foundations del sistema. ### **Tier 3. Librerías locales** Un touchpoint también puede tener librerías locales que tengan elementos creados a medida para un producto concreto o un público específico. Estas librerías sólo se comparten con los equipos que trabajan en esos productos. Si alguno de estos patrones creados ad-hoc para un caso local se considera que puede ser reutilizable de forma global por el resto de productos web/app/TV, etc, entonces se migrará de la librería local Tier 3 a la librería Tier 2 global de ese touchpoint.\ \ Ejemplo: un componente de card de noticia diseñado para un proyecto editorial concreto, puede tener sentido moverlo desde la librería del proyecto a la librería Web (Tier 2) para que todo el resto de proyectos web de la compañía puedan usarlo. ## Acciones {% hint style="success" %} 1. Define qué miembros van a trabajar en el sistema de diseño, de todos los equipos involucrados. 2. Empieza a convocar los primeros workshops para definir la misión/visión, roles, responsabilidades, alcance, workflow, herramientas a utilizar, KPI's y (muy importante) con qué proyecto vais a empezar. 3. Vete documentado todo para irlo compartiendo con todo el equipo. {% endhint %} ## # Principios de diseño Antes de ponerte a definir componentes y otros patrones del sistema, necesitas unos principios de diseño fuertes: son la base de cualquier sistema de diseño. Es la mejor manera de asegurarte que el propósito de tu producto o compañía se reflejan en el diseño que estás creando. El enfoque de estos principios varía mucho dependiendo de la compañía: algunas tienen principios de diseño muy focalizados en la cultura de la empresa, otras los focalizan más en la marca, otras en el proceso de diseño... Pero entonces...¿qué son los principios de diseño? Son algo abstractos, pero podríamos decir que **los principios de diseño son leyes, directrices y consideraciones de diseño de amplia aplicación, que apoyan el propósito del producto y ayudan a que tenga un carácter distintivo.** Luego veremos algunos ejemplos conforme vayamos explicando qué características deben tener. Las compañías más grandes a veces tienen principios separados para cada área: UX tiene los suyos, marca los suyos, marketing los suyos, producto lo mismo, etc. Esto puede que funcione para algunas compañías, sin embargo, nuestra recomendación es tener un conjunto de principios común a todos los equipos, para no empezar creando un sistema ya fragmentado desde el principio. {% hint style="info" %} 'Sólo hay un sistema. Y los principios están ahí para conectar los puntos.'\ \- **Jurgen Spangl, Head of Design en Atlassian** {% endhint %} ## **Cualidades de unos buenos principios de diseño** ### Son auténticos y únicos Lo que hará que tus principios de diseño sean útiles es saber exactamente qué significan esas palabras para ti, para tu equipo o tu compañía. Por tanto, cuanto más concretos y únicos sean, más fácil será interpretarlos, sentirse representado por ellos y ponerlos en práctica. {% hint style="info" %} 'Simple, útil, divertido'. No tienen nada de único, ¿no? ¿Te imaginas un producto con principios como 'complicado, inútil y aburrido'? Intenta ir más allá y piensa en aquello que haga realmente especial a tu equipo, tu producto o tu empresa. {% endhint %} ### Son prácticos y accionables Unos buenos principios de diseño deben ofrecer algo de guía a la hora de tomar decisiones o resolver problemas. Piensa en ellos como algo que te da consejos a la hora de construir tu producto. {% hint style="info" %} Por ejemplo, uno de los principios de diseño de **TED** es **'Se atemporal, no vanguardista'.** Esto ayuda a los diseñadores a tomar decisiones en el día a día. {% endhint %} ### Te ayudan a priorizar Los principios de diseño te ayudan a priorizar unas cosas sobre otras cuando hay decisiones difíciles que tomar. Por ejemplo...¿esta página debe ser más visual o más funcional? ¿Esta sección tiene que ser más seria o más divertida? Los buenos principios de diseño te ayudan a priorizar, a balancear, especialmente cuando entran en conflicto diferentes factores. {% hint style="info" %} **Salesforce** tiene sus 4 principios de diseño ordenados por prioridad. **'Claridad. Eficiencia. Consistencia. Belleza'.** Esto significa que, para ellos, la claridad es más importante que la consistencia, por ejemplo. Ordenar tus principios es una forma genial de recordar este tipo de cosas. {% endhint %} ### Son memorables y fáciles de contar El número de principios y como los redactas es muy importante, pues tiene un impacto directo en lo fácil que será acordarse de ellos. Para ser recordados, tienes que usarlos constantemente. Tienen que estar en tu día, en tus conversaciones con el equipo, en tus presentaciones o incluso en las paredes si fuese necesario. Intenta tener entre 3 y 5 principios de diseño. ¡La memoria humana es limitada! {% hint style="info" %} **Spotify** por ejemplo usa un acrónimo para ayudar al equipo a recordar sus 4 principios de diseño. **'T.O.N.E.'**, que significa 'Tone, Usable, Necessary, Emotive.' Este tipo de juegos son geniales para asegurarte que tu equipo se acuerda de tus principios de diseño. {% endhint %} ## Acciones {% hint style="success" %} 1. Empieza pensando en el propósito de tu compañía o tu producto. 2. Organiza un workshop con miembros clave que representen a diferentes equipos y proyectos para alinearos sobre qué principios representan de verdad a tu marca, tu producto y tu equipo. 3. Céntrate en quién los va a usar y redáctalos con ese tipo de perfil en mente. Tu usuario ahora no es el cliente de tu producto, es tu propio equipo. 4. Téstalos en el día a día y sigue evolucionándolos. No te preocupes mucho con definir unos principios perfectos a la primera; empieza teniendo un buen conjunto, observa si te ayudan y vete cambiándolos si es necesario. {% endhint %} # Foundations La librería de Foundations incluye cosas como los colores de marca, grids, estilos tipográficos, iconografía, animación, tono de voz, accesibilidad...Aquí es donde definiremos los **design tokens.** Estos **'**Foundations' son las cosas que todo el mundo debería usar y es el mínimo que cualquier producto debería cumplir para tener un OK desde el punto de vista de diseño. ## Design Tokens > "Los Design Tokens son una metodología, arquitectura y proceso independientes de la tecnología para escalar el diseño entre herramientas, dispositivos y plataformas". - **Design Tokens W3C Community Group.** La definición oficial es un poco confusa, ¿verdad? Quédate con que los Design Tokens manejan en cierto modo las variables del sistema, como el color o la tipografía, y se pueden aplicar a cualquier componente. Ahora iremos haciendo un repaso por los más comunes. Además, los Design Tokens son útiles para generar la estructura de nombres del sistema, reemplazando elementos variables (como un hexadecimal de un color) con su equivalente no variable (por ejemplo, el nombre que le damos al color en el sistema). Así, un botón estará formado por varios tokens que describen sus propiedades (color de fondo, estilo de texto, etc.) sin hablar de valores (# 49a4e6), sino que hacen referencia a su propiedad global (Global-Blue-50). De esa forma, el color de fondo del botón siempre será una variable independiente del valor que represente. El valor puede cambiar (el hexadecimal) pero la propiedad (Global Blue 50) seguirá siendo la misma. ![](https://3589795035-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MQEMIjbz11E6fFLsabr%2F-MQdEdX7v-6F80p-ujEj%2F-MQdGQur-J24Zjdx6dkX%2Ftoken.jpg?alt=media\&token=cb4e68b2-0891-42e0-b07d-7b79088d1c84) Esto permite que los equipos de diseño hagan actualizaciones globales en el sistema en un sitio y automáticamente se aplique en todos lados. Además, también aseguran la consistencia mientras el sistema va creciendo y evolucionando. ## Foundation Styles ### 1. **Color** Agrupamos los colores en 3 categorías dependiendo de la importancia que tengan para la marca y su uso: primarios, secundarios y terciarios. Una cosa importante: para asegurar que cubran los suficientes casos de uso, es importante que cada color tenga al menos **5 tonos** para potenciales estados de interacción (estado por defecto, hover, click, seleccionado y activo). También recomendamos tener al menos un tono oscuro y uno muy claro en cada color para posibilitar composiciones en las que poder jugar con más jerarquía de color. ![](https://3589795035-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MQEMIjbz11E6fFLsabr%2F-MQdGS3HX5VZ4upe_DBX%2F-MQdHCOGrO0bXLbh-Wm-%2Fcolors.jpg?alt=media\&token=654fc148-549e-4ac8-9c50-d43c2a198d8d) ### 2. Grid Para definir los espacios entre los elementos del sistema, usamos un **grid (retícula) responsive**. Es un conjunto de columnas y filas que nos ayudarán a componer nuestros diseños. El grid responsive de Bootstrap es una buena base para espacios horizontales pero falla en los ritmos verticales. Nuestra recomendación es usar un grid de 8 píxeles que aproveche la base de Bootstrap pero que añada sinergías verticales. #### **8−pixel grid** Todo elemento de la interfaz (UI) debe estar alineado al grid de 8 píxeles, **tanto horizontal como verticalmente**. Ajustar los elementos al píxel garantiza que todos se visualicen perfectamente en todos los dispositivos. Además también permite a los diseñadores y desarrolladores tener el mismo modelo de caja (en que cada caja como los textos ocupan los mismos píxeles) minimizando la toma decisiones y evitando muchos más errores. ![](https://3589795035-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MQEMIjbz11E6fFLsabr%2F-MTv7WV3xG9BBFHxrrP9%2F-MU888xTaVdvLHXjhfTD%2FScreenshot%202021-02-22%20at%2010.48.55.png?alt=media\&token=d305f1cc-974a-47d8-bb3d-34492573a2a0) #### **Línea base de texto y espaciado de línea** Tener controlados los tamaños de las cajas de texto es importante para conseguir una buena coherencia vertical en tus diseños. Al cuadrar cajas y grid vertical, podemos conseguir que todos los elementos de la interfaz tengan un ritmo vertical armonioso. ![](https://3589795035-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MQEMIjbz11E6fFLsabr%2F-MTv7WV3xG9BBFHxrrP9%2F-MU88Ex60p1jySLpbB4p%2FScreenshot%202021-02-22%20at%2010.45.52.png?alt=media\&token=20e74332-8cfe-4d07-9ee3-6048b9a90c72) Hay veces en las que hacemos una **excepción** a la regla del grid de 8 píxels, y es cuando decidimos el tamaño de la tipografía. Añadir cierta flexibilidad y permitir añadir múltiplos de 4 da a los diseñadores la libertad que elegir el tamaño de texto que nos da la mejor legibilidad. El punto aquí es que el interlineado (espacio entre líneas del texto) sea siempre múltiplo de 8 para alinearse al grid (por ejemplo, un texto de 20 px podría tener un interlineado de 32px). ![](https://3589795035-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MQEMIjbz11E6fFLsabr%2F-MTv7WV3xG9BBFHxrrP9%2F-MU88eRtgksaKQB1kA_r%2FScreenshot%202021-02-22%20at%2010.51.15.png?alt=media\&token=2f77c4a3-98a2-4b3a-9caf-a3027926e9fc) Estos son **casos específicos** donde es difícil seguir el grid de 8 píxels. Pasa mucho por ejemplo en visualización de datos. En ese caso por ejemplo, nosotros usamos de nuevo una caja que se alinea al grid de 8 píxels y que permite que lo que haya dentro de esa caja tenga mayor flexibilidad para representar de la mejor forma los datos. #### Ejemplo de grid y puntos de corte | Nombre | Punto de corte (en px) | Columnas | Margen | Gutter | | ------ | ---------------------- | -------- | ------ | ------ | | XS | 0-719 | 4 | 20 | 16 | | S | 720-1023 | 8 | 40 | 16 | | M | 1024-1439 | 12 | 44 | 24 | | L | 1440-1919 | 12 | 88 | 32 | | XL | +1920 | 12 | Auto | 32 | ## 3. Tipografía En un producto digital, es importante que la tipografía sea accesible, flexible y que funcione bien en este contexto. Las guías de uso nos ayudarán a definir los tamaños mínimos (tanto para mayúsculas como para minúsculas) para que los equipos creen experiencias accesibles para cualquier usuario. Además, una tipografía flexible que renderice bien en muchos tamaños diferentes también ayudará a que los diseñadores tengan más armas a la hora de crear una buena jerarquía visual en sus composiciones. Como recomendación, es bueno limitar el número de tipografías, sus pesos y tener unas pocas variantes para estar seguros de que el rendimiento de la web o la app no se vea afectado. #### Ejemplos de tamaños tipográficos | Nombre | Hasta punto de corte S | Desde punto de corte M | | ------------- | ---------------------- | ---------------------- | | Caption | 12 | 12 | | Body 1 | 14 | 14 | | Body 2 | 16 | 16 | | Action Button | 18 | 16 | | Button | 18 | 16 | | Small Button | 16 | 14 | | Title 1 | 18 | 20 | | Title 2 | 16 | 16 | | Subheadline | 24 | 24 | | Headline 1 | 48 | 64 | | Headline 2 | 40 | 48 | | Headline 3 | 28 | 40 | ## 4. Elementos gráficos Cuando pensamos en elementos gráficos que apoyan la experiencia, la escala es muy importante. Por eso, solemos trabajar con **iconos, microilustraciones e ilustraciones**, que ayudarán a crear en cada caso la composición que mejor funcione. Es importante que estos elementos gráficos estén bien definidos y ejecutados para que el producto digital funcione lo mejor posible. Como normal general, recomendamos usar iconos entre 16 y 24px, después pasar a microilustraciones desde 32 hasta 320px, y por último, usar ilustraciones completas a partir de ahí, para tamaños más grandes. El punto exacto para empezar a usar una u otra puede variar dependiendo del estilo que tengan los elementos gráficos de tu marca (esto pasa especialmente en microilustraciones e ilustraciones) pero lo importante es que te quedes con la idea de definir claramente estos tamaños de uso y que se lo comuniques correctamente a los equipos. ![](https://3589795035-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MQEMIjbz11E6fFLsabr%2F-MQdNA29weG_kSDGIOsX%2F-MQdQ251ByQ0yqsc-yu1%2Fgraphic3.jpg?alt=media\&token=7cd8d2bb-3fc2-417c-93fd-927136769313) La ejecución de estos elementos gráficos también es importante para el desarrollo y el rendimiento de un producto digital. Presta especial atención a detalles como las cajas que los contienen (para asegurar que todos los elementos de una familia tengan el mismo tamaño), fondos transparentes, grosores de línea, etc para intentar que el margen de error sea lo más pequeño posible. ## 5. **Elevación** Cuando hablamos de elevación, nos referimos a cómo jugando con sombras podemos generar diferentes sensaciones de volumen o altura de los elementos. Este concepto de elevación es útil definirlo a nivel global porque es un elemento visual que, aunque sútil, se va a usar muy a menudo a lo largo de todo el sistema, en componentes como cards, modales o hovers. Así, seguiremos haciendo fuerza en la búsqueda de una consistencia visual muy fuerte en todo el ecosistema de productos digitales. ![](https://3589795035-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MQEMIjbz11E6fFLsabr%2F-MQdNA29weG_kSDGIOsX%2F-MQdRvaee5ZPiKHU09sG%2Fsombras.jpg?alt=media\&token=786b65dc-96b8-41c3-bb69-a553fc1d8ddd) ## 6. Tono de voz Otra 'foundation' muy importante a definir en un sistema de diseño es el tono y la voz. Más allá de hablar de instrucciones o mensajes informativos, el tono de voz define las guías que ayudarán a los equipos a redactar contenido de forma clara y consistente a lo largo de todos los productos y canales. Un gran ejemplo de ejemplo que puede servir de inspiración, es el manual de tono de voz de Mailchimp. {% embed url="" %} ## 7. Animación La animación es también muy importante en un sistema de diseño, pues tiene un gran impacto tanto en la experiencia de usuario como en negocio. Igual que pasa con la tipografía o el color, la animación tiene mucho que decir acerca de tu producto y su personalidad. La animación, y particularmente la interacción, combina forma y función y ayuda a captar la atención del usuario, mejora el feedback que el sistema le da conforme interactúa, ayuda a que se oriente mejor, genera emociones y ayuda a contar mejores historias a lo largo de la experiencia. Un gran ejemplo de guía de animación es Material Design, de Google. {% embed url="" %} ## Acciones {% hint style="success" %} 1. Agenda workshops con equipos de diseño y desarrollo para alinear posturas respecto al grid, la tipografía y los nombres de los tokens. 2. Trabaja de la mano con el equipo de marca definiendo colores, tonos, iconos y estilo de ilustración. 3. Empieza a crear la librería de Foundations. 4. Documenta todo para que se pueda ir compartiendo con los equipos. {% endhint %} # Platform System Los diferentes touchpoints (como web o app) tienen sus propias librerías que comparten elementos comunes para ese touchpoint concreto y que están compartidas con todos los equipos. **Recomendamos empezar con un touchpoint** y un producto que sea muy importante para tu estrategia de negocio y que pueda representar los mejores patrones de UX y UI. Estos patrones de diseño se compartirán y se usarán a lo largo de todos tus productos digitales y serán la referencia en cuanto a calidad de diseño de tu compañía. Si necesitas elevar la calidad de diseño, esta es la mejor oportunidad para conseguirlo, al empezar a generar el sistema de diseño. **Importante: no añadas nada al sistema que no quieras ver reutilizado por todos los productos de la compañía.** Crea las primeras librerías usando este primer producto, uniendo los diseños al Foundation System usando los Design Tokens. ## Tipos de elementos Como mencionábamos al principio, los sistemas están compuestos por diferentes elementos que, combinados, solucionan un problema concreto. Para que haya un flujo de trabajo claro y eficiente entre equipos, es crítico que haya una nomenglatura y un entendimiento común de los diferentes tipos de elementos que usaremos en el sistema. En función del propósito que tienen, nosotros proponemos la siguiente distribución: **fragmentos, componentes, módulos y templates.** ![](https://3589795035-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MQEMIjbz11E6fFLsabr%2F-MQdWAH2NX6Nsj-QxJH3%2F-MQdYyzkSbtmLTT-c_aN%2FtypeElements.jpg?alt=media\&token=a4767ae6-a672-487c-b403-74745917c60e) ### Fragmentos (o átomos) Un fragmento (también conocido como átomo) es un elemento que sólo tiene sentido cuando se une a algo más y entonces, consigue un propósito o un significado. Por ejemplo, un fragmento podría ser un icono en un tool tip que acompaña a un título o a un copy. Nunca irá sólo porque sin un texto que lo apoye no tiene significado y solo generaría confusión. Otro ejemplo podrían ser elementos que son parte de un conjunto más grande y que nunca se deberían usar por separado. Links de una barra de navegación, por ejemplo. Así, los siguientes elementos podrían ser parte de este grupo de fragmentos: * Iconos * Links de un header * (...) ### Componentes Un componente es un elemento que por sí mismo tiene propósito y significado y que cumple una función concreta. Tiene sentido aunque lo aisles de otros elementos con los que conviva. Como ejemplo, podríamos poner uno de los más usados en cualquier producto digital: un botón. Un botón tiene una función específica y puede colocarse en cualquier composición sin otros elementos que lo acompañen. Algunos ejemplos de componentes dentro del sistema son: * Botones * Bloques de texto * Links * Listas * Selectores * Imágenes * Ilustraciones * Campos de texto * Pestañas * Tablas * (...) ### Módulos Un módulo es un grupo de componentes que se agrupan para cumplir una función concreta. Un ejemplo podría ser un formulario de contacto. Los componentes individuales (campos de texto, botones, etc) se juntan para crear algo más grande y cumplir un propósito concreto dentro de la experiencia. Otro ejemplo podría ser una card comercial. Normalmente este módulo tiene componentes individuales (headlines, botones, fondos...) que, agrupados, crean el módulo. Otros ejemplos de módulos podrían son: * Cards * Formularios * Modales * Barras de búsqueda * Calendarios * Galerías * (...) ## Nombrando componentes A medida que los sistemas de diseño crecen para ir dando cabida a un espectro cada vez más amplio de componentes y plataformas, los design tokens — y sus nombres — son cada vez más importantes. Que tengamos una estructura a la hora de nombrar las cosas crea un lenguaje común entre todos los equipos conforme va evolucionando el sistema (y esto es importantísimo). Para crear una estructura de nombres que sea sostenible en el tiempo, una propuesta es organizar el naming en 4 niveles, por ejemplo: **nombre del espacio, objeto, base y modificador**. Es raro que un sistema o un componente use los 4 niveles, pero es una buena base para asegurar que esta estructura de nombres sea escalable. Debajo tienes un ejemplo de cómo creamos una estructura de nombres usando esta metodología para un cliente con 2 target diferentes — retail y corporate. ![](https://3589795035-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MQEMIjbz11E6fFLsabr%2F-MQdavaSb1si9LsmL8CV%2F-MQdb7ew_yTFp6hrhAEh%2Fnaming.jpg?alt=media\&token=7e8c7686-d455-4f02-8504-f02fb7a629a3) * **Nombre del espacio** es una combinación del *sistema* (`material`), *theme/subbrand* (`nikeSB`), o el *dominio* (`retail`). * **Objeto** se refiere a *componente* (`button`), *elemento* dentro de un componente (`left-icon`), o *grupo de componentes* (`forms`). * **Base** es la columna vertebral de los tokens que combina *categoría* (`color`), *concepto* (`action`) y *propiedad* (`size`) * **Modificador** se refiere a una o más *variantes* (`primary`), *estados* (`hover`), *escala* (`100`), y *modo* (`on-dark`). Como ves, estas estructuras de nombres se pueden volver enormes — y algo abrumadoras, sí, lo sabemos — pero no te agobies, quédate con la idea de que existe un gran abanico de posibilidades para definir tu estructura según el alcance de tu sistema. No hay una estructura fija recomendada. Para que te hagas una idea, nosotros trabajamos con cada cliente para entender sus necesidades, ecosistema y objetivos y así poder crear la estructura que mejor encaja para su caso. ## Acciones {% hint style="success" %} 1. Define qué proyecto va a ser la punta de lanza para construir la base de las librerías del sistema. 2. Si necesitas elevar la calidad de diseño de tu compañía, aprovecha esta oportunidad para rediseñar el touchpoint conforme vas construyendo el sistema de diseño. 3. Trabaja de la mano entre diseño y desarrollo para alinear posturas respecto a la estructura de nombres. 4. Construye la librería en Figma/Sketch usando esa estructura de nombres. 5. Documenta todo para compartirlo con el equipo. {% endhint %} # Gobierno En nuestra experiencia desarrollando sistemas de diseño para grandes organizaciones, tenemos claro que definir el modelo de gobierno del sistema es clave para permitir que el sistema **escale** de forma sensata, **manteniendo la consistencia** y pero **dejando espacio también para la innovación y la creatividad**. Es fundamental tener claro cómo va a ser este gobierno antes de lanzar el sistema. Antes de entrar a ver el método que usamos para estandarizar el workflow, veamos un par de cosas claves para que este proceso tenga éxito: ### Digital System Team El Digital System Team (DST) es un equipo formado por diseñadores y desarrolladores que analizan los nuevos componentes que se van añadiendo al sistema. Tendrán que ser perfiles diversos que representen los diferentes canales, touchpoints y unidades de negocio. Este equipo deberá tener reuniones frecuentes con los equipos de cada proyecto para revisar los diseños y los componentes que están usando y generando. **Su trabajo no es aprobar el diseño,** sino proporcionar una visión holística del sistema y su uso a todos los equipos. ### Canal para feedback Un canal de comunicación al que sea fácil acceder es crucial para que los equipos puedan recibir feedback sobre nuevos componentes. Este canal puede ser una página de contacto en la web del sistema, una dirección de mail, un canal de Slack...sea cual sea, debería ser fácilmente accesible y su existencia debe estar bien comunicada a todos los equipos que trabajan en el sistema. ### **Formulario para nuevos componentes** Este formulario estandarizará el proceso de los equipos de diseño a la hora de sugerir nuevos componentes para el sistema en función de sus necesidades. Para lograr que el Digital System Team sea capaz de revisar y responder a todas las peticiones de forma eficiente, lo mejor es que todas ellas sigan la misma plantilla e incluyan los siguientes elementos: * Equipo y proyecto * Touch point (web, app, unidad de negocio) * Necesidad de nuevo componente explicada * El diseño del nuevo componente * Cualquier información o contexto adicional que ayude a analizar el componente (para qué lo necesitan, el componente usado en una página completa, un user flow si el componente impacta en UX, etc) * Fecha de entrega del sprint ### La comunicación del sistema de diseño Una newsletter bi-semanal a todos los equipos de producto permite tener una conexión constante entre todos los equipos involucrados en el sistema y aporta información adicional como: * Actualizaciones del sistema (nuevos componentes) * Próximas actualizaciones o componentes, con fechas * Guías de uso * Recordatorios importantes ## Workflow ### Petición de nuevo componente ![](https://3589795035-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MQEMIjbz11E6fFLsabr%2F-MQgXK3_AtZtdbzgbqqA%2F-MQg_DwuXFODiH31DgAf%2FGovernance7.jpg?alt=media\&token=2f9124d9-158b-4a44-a02a-f8c248b7ca5e) Es muy probable que, conforme pasa el tiempo, los equipos de producto vayan identificando nuevas necesidades de componentes que todavía no estén cubiertas por el sistema. Aquí podemos tener 2 escenarios: * **Ya existe un componente similar.** La librería actual ya tiene un componente que cubre esa necesidad (o uno muy similar) y por tanto, deberían utilizarlo. * **La librería no tiene ningún componente que cubra esa necesidad** y por ello, hace falta crear uno nuevo. En este caso, el equipo de diseño de producto debería seguir los pasos que explicaremos a continuación. ### Pasos para crear un nuevo componente 1. Diseñar este "suggested new component" (SNC) usando las guías del sistema. 2. Enviar este SNC al Digital System Team rellenando el formulario de nuevo componente y enviándolo a través del canal oficial de feedback que hayáis definido. 3. Si es un grupo de componentes o si es un componente muy complejo, es recomendable una reunión (presencial o en remoto) entre el equipo del proyecto y el Digital System Team para poder hablar sobre el ello y poder dar más contexto, resolver dudas in situ y llegar a una solución final. Una vez que el nuevo componente ha sido revisado, el equipo del sistema (DST) podrá determinar en que Tier va a colocar este nuevo componente (es decir, si es un un componente que estará Tier 2 como librería global para ese touchpoint, y que por tanto podrán reutilizar muchos otros equipos, o si no merece la pena porque es un caso muy concreto y entonces se queda en el Tier 3 de la app o web local). Para tomar esta decisión, deberían tener en mente: * Lo reutilizable que es este componente para otras herramientas o productos * El impacto que tendría este componente en el sistema de diseño * La complejidad técnica de este componente ### Versionado Como ya hemos ido comentando varias veces a lo largo de esta guía, un sistema de diseño está vivo y deberá irse actualizando constantemente. El DST (design system team) deberá crear y comunicar las nuevas versiones del sistema de forma constante. Para hacer esto de forma controlada y efectiva, sugerimos el siguiente flujo: ![](https://3589795035-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MQEMIjbz11E6fFLsabr%2F-MQga25Iffj1-rvgM1Tc%2F-MQgdGinVGbp8BPi8sVf%2FGovernance5.jpg?alt=media\&token=c9aadebe-5ee0-4820-9fb9-65c6eadfc95a) 1. **Definir los objetivos:** cuáles son los objetivos y prioridades de esta nueva versión y qué necesidades se están cubriendo. 2. **Ejecutar los cambios**: añade nuevos componentes, modifica estilos o componentes ya existentes en función de datos o test que hayas hecho o elimina componentes que ya no se usen o que no estén funcionando como deberían. 3. **Valida todo**: cada nueva actualización debe cumplir con los criterios definidos para garantizar usabilidad, coherencia y calidad (es decir, estados, comportamientos, acciones, escalabilidad...) 4. **Cierra la versión**: publica la nueva versión en Figma/Sketch y empieza a implementar estos cambios en la plataforma del sistema de diseño. Es importante documentar qué cambios se han hecho en cada versión que se cierra. Hay pluggins que pueden extraer esta información de forma automática y crear un 'change log' para que los diseñadores y desarrolladores tengan una referencia rápida de todo, o hay herramientas que ya te dan esta información directamente. ## Acciones {% hint style="success" %} 1. Crear un DST (Design System Team) que sea multidisciplinar. 2. Definir la forma en que cualquier persona puede ponerse en contacto con el equipo del sistema de diseño, tanto para preguntar dudas como para solicitar un nuevo componente. 3. Definir y comunicar el modelo de gobierno y el workflow de versionado. Todo el mundo debe conocer ambas cosas. {% endhint %} # Documentación ![](https://3589795035-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MQEMIjbz11E6fFLsabr%2F-MQdfFEbESEl0geUsUdF%2F-MQdfZzwCodl_UbqZMkN%2FfarCo%20\(1\).jpg?alt=media\&token=9d9f6a3f-be39-4d91-a9ee-19d533194b16) La forma en que documentamos un sistema de diseño es muy importante. Por eso, estamos todavía afinando esta sección y pronto estará lista. ¡Vuelve pronto para consultarla! Mientras, puedes continuar con las secciones de 'Onboarding de equipos' y 'Midiendo el retorno'. # Onboarding de equipos Para asegurar un buen onboarding a los nuevos miembros y ayudar en el primer uso del sistema de diseño, creemos que tanto los siguientes materiales como buenas prácticas pueden ayudar muchísimo. ## **La primera comunicación** La primera toma de contacto con el sistema se puede hacer perfectamente vía mail. Sin embargo, la idea es que este mail sea distinto y tenga cierta relevancia para la persona: sin duda es un mail al que debería prestar atención. Para ello, puedes crear un mail específico al DST (digital system team) y, si puedes, un conjunto de plantillas. Esto nos va ayudar a lograr que todas las comunicaciones sean consistentes y tengan más impacto. ¿Qué contenido podemos incluir? Algunas sugerencias: * Bienvenida * Links al sistema de diseño * Noticias y actualizaciones * Qué es lo siguiente que viene * (...) ## **Starter kit** Un starter kit es lo primero que tendrá en sus manos la persona que entre y le será de gran ayuda a la hora de entender el sistema antes de empezar a utilizarlo. Generalmente incluye los principios de diseño, guías generales, la Foundation Library e información acerca de los canales de comunicación. **Un Starter Kit, si está bien trabajado, es una forma rápida y fácil** de que la nueva persona del equipo tenga la información necesaria para empezar a usar el sistema además de saber cómo resolver dudas o a quién y cómo preguntarlas. ## Tutoriales Los tutoriales en vídeo, tanto **en directo** como vídeos **pregrabados**, son una forma muy efectiva (y visual) de explicar toda la información relacionada con el sistema, desde detalles técnicos de cómo acceder al contenido o usar una herramienta específica, a una guía de 'do's y don'ts' del sistema. Además, tienen otras cosa buena. Estas píldoras, que se irán actualizando constantemente, fomentan que la gente vuelva a la página del sistema a menudo y así estén siempre informados de nuevos assets o features. ## **Guías técnicas** Las guías técnicas se podrán acceder o **desde la página del sistema** o desde el archivo de diseño de la librería. Estas incluirán toda la información técnica necesaria, desde el grid al tamaño de los componentes, espaciados, etc. Esta información incluye toda la lógica de la que es necesario 'empaparse' para usar los diferentes elementos del sistema. ## **Practicar** Una de las mejores cosas que puede hacer un nuevo miembro del equipo para irse familiarizando con el sistema es...**¡empezar a usarlo!** Una vez que hayan analizado el starter kit, se hayan visto los tutoriales y demás, es genial si pueden empezar a crear sus primeros borradores usando el sistema. Un ejercicio maravilloso es intentar replicar páginas que ya estén creadas con el sistema y contar con la ayuda y supervisión de alguien que esté muy familiarizado con él, para servir de guía en estos primeros pasos y poder resolver cualquier duda. ## Acciones {% hint style="success" %} 1. Crea el stater kit que pueda ser fácilmente accesible y descargable desde la página principal del sistema. 2. Define los canales de comunicación que vas a utilizar tanto para comunicar las actualizaciones del sistema como para resolver dudas o recoger feedback. 3. Empieza creando los primeros videotutoriales que expliquen las diferentes partes del sistema. 4. Define el framework para todas las guías técnicas y que así estén todas presentadas de la misma forma y estén en el mismo lugar. 5. Redacta el mail de primera toma de contacto para invitar a los nuevos miembros a unirse al sistema. {% endhint %} # Midiendo valor y retorno Conseguir medir el valor y el retorno que está dando un sistema de diseño es unas de las labores más importantes que tiene por delante un equipo de diseño. La idea es conseguir saber el rendimiento que está teniendo el sistema, y para ello vamos a necesitar datos que nos permitan conocer su estado y así valorar si tiene sentido seguir invirtiendo en él. En Far Co tenemos un plan de medición para evaluar el éxito que está teniendo un sistema. ¿Qué significa que tenga éxito? Aumento de la productividad y la velocidad a la hora de construir un producto. Este plan lo dividimos en 2 partes: 1. **La salud del sistema:** Métricas relacionadas al uso del sistema, uso de los componentes, etc. Esto nos ayudará a entender mejor qué está funcionando y qué cosas necesitamos actualizar, siempre basándonos en datos reales de uso. 2. **El ROI del sistema:** Métricas basadas en objetivos de negocio y los KPI's que tenga el sistema. Estos son los datos que presentaremos a las capas más altas de la organización para demostrar el valor que aporta el sistema y conseguir que se siga invirtiendo en él. **Por poner un ejemplo, hemos visto un ahorró en torno a 10.000 horas y 280.000€ en un Q, en 1 proyecto, usando el sistema de diseño. El método que usamos para medir este retorno lo presentamos más abajo.** ![](https://3589795035-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MQEMIjbz11E6fFLsabr%2F-MQgq7qzVic0pGxgXb1G%2F-MQgrpHTzestl8_Rn4kt%2Fmoney2.jpg?alt=media\&token=3721a7fc-aa6c-4b15-b7d0-0c2cb5c71c66) ## Midiendo la salud del sistema Vamos a contaros el framework que usamos, basado en métricas, KPI's y objetivos para medir el sistema de diseño. Te recomendamos empezar definiendo los objetivos de tu sistema, luego los KPI's que te dirán si tiene éxito o no y finalmente las métricas que usarás para valorarlo. Un par de cosillas a tener en mente: * **Revisa periódicamente las métricas**. Es buena práctica ir revisando las métricas semanalmente, para así poder tener una comparativa semana a semana y ver si el sistema está mejorando o no. Elige un día y cíñete a él. Los periodos de tiempo tienen que ser siempre los mismos. * **Dashboard de datos**. Un dashboard en la web del sistema así como datos reales en un Google Sheet ayudan mucho y deberían estar accesibles para todos los equipos. Aquí os dejamos un par de ejemplos en relación a la salud del sistema: ### **Objetivo 1 /** Incrementar el uso del sistema de diseño #### KPI's * Número de equipos usando el sistema de diseño * Número de equipos / proyectos en total * % de equipos que usan el sistema * Número de librerías que se están utilizando ### **Objetivo 2 /** Incrementar la implementación de archivos en producción #### KPI's * Número de componentes en producción * Componentes totales en el sistema * % de componentes en producción * Número de componentes con errores * % de componentes que funcionan ### **Objetivo 3 /** Mejorar la efectividad de los canales de feedback #### KPI's * Número de peticiones de feedback * Días que se tarda en resolver una petición ## Midiendo el retorno en tiempo y dinero Vamos a ver ahora el cálculo que usamos, el cuál se puede aplicar en cualquier sistema de diseño para medir **cuánto** **tiempo** ahorramos y, por lo tanto, también **cuánto** **dinero** ahorramos mediante el uso del sistema. A continuación, os contamos paso a paso cómo lo hacemos. {% hint style="danger" %} Este proceso mide el valor del sistema durante la fase de diseño. No estamos incluyendo la parte de desarrollo, así que el ahorro en tiempo y dinero será aún mayor. {% endhint %} ## Paso 1. Definiendo el valor por componente. Vamos a empezar definiendo el valor de un componente en términos de tiempo (horas) y coste (euros €): **Tiempo (horas)** = tiempo desde que recibes los requisitos hasta que obtienes la aprobación final y lo subes al sistema.\ **Coste (euros €)** = media del coste por hora de un diseñador x el número de horas empleadas. ### Ejemplo: un componente **7 horas** = tiempo desde que recibíamos los requisitos hasta que obteníamos la aprobación final y lo subíamos al sistema.\ **196€** = 28€ x 7 horas (52.500€ salario medio de los diseñadores de la compañía ➗ 1.840 horas en un año = 28€ hora) ## Paso 2. Definiendo el número de componentes únicos Ahora, vamos a definir el número de componentes únicos en un archivo de diseño entregado a desarrollo. {% hint style="danger" %} **Cuenta sólo componentes únicos:** ojo, sólo deberías medir los componentes únicos del archivo. Si un componente se repite muchas veces y cuentas esas repeticiones, al final lo que tendrás será un cálculo inflado y bastante lejos de la realidad. **Haz el cálculo cuando entregues el archivo de diseño:** haz el cálculo sólo después de que el archivo de diseño esté aprobado y se haya entregado a equipo de desarrollo. Usar un archivo 'work in progress' para medir también te dará un cálculo inflado y no real. {% endhint %} ### Ejemplo: Feature simple 35 componentes únicos = el promedio en un feature simple\ **245 horas** = 35 x 7 horas\ **6,860€** = 28€/hr x 245 horas ### Ejemplo: Feature más complejo 72 componentes únicos = el promedio en un feature más complejo\ **504 horas** = 72 x 7 horas\ **14,112€** = 28€/hr x 504 horas ## Paso 3. Features entregados en un Q (Quarter) Añade todos los features que hayas entregado en un Q entre todos los productos para tener una foto clara de las horas que has ahorrado y el ahorro en dinero. ### Ejemplo: Una unidad de negocio en un Q 5 proyectos diferentes entregaron 26 features a desarrollo\ **10.015 horas ahorradas**\ **280.410 € ahorrados** ![](https://3589795035-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MQEMIjbz11E6fFLsabr%2F-MQgq7qzVic0pGxgXb1G%2F-MQgrmwsgwrGf6HFMcKB%2Fmoney2.jpg?alt=media\&token=2e847736-a220-4fb6-9681-cdecb33c2f07) ## Paso 4. Pronósticos Por último, puedes calcular la cantidad promedio de features entregados en un Q por proyecto y la cantidad promedio de componentes únicos en los archivos de diseño entregados para ese proyecto. {% hint style="danger" %} **Promedio de features entregados:** Trabaja con el Project Manager en definir este promedio basado en pasados Qs. \ \ **Promedio de componentes únicos:** promedio basado features simples y complejos sobre Qs anteriores. {% endhint %} ### Ejemplo: Un feature "Loyalty App" 18 features de media entregados por Q\ 53,5 componentes únicos de media por feature por Q (simple 35 + complejo 72 / 2) **374.5 horas** = 53,5 x 7 horas\ **10.486€** = 28€/hr x 374.5 horas ### Pronóstico total por Q, Loyalty App **6.933 horas ahorradas** = 374.5 x 18 features\ **194.140€ ahorrados** = 10.486€ x 18 features ![](https://3589795035-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MQEMIjbz11E6fFLsabr%2F-MQgq7qzVic0pGxgXb1G%2F-MQgrjVwKkOs1Wmv5bYv%2Fmoney3.jpg?alt=media\&token=6e9d8335-12ad-4b25-952a-20e76d099f1f) # Referencias Aquí tienes un listado de algunos sistemas de diseño increíbles, que esperamos te sirvan como guía o inspiración. ## Polaris by Shopify {% embed url="" %} ## Atlassian Design System {% embed url="" %} ## Airbnb Design System {% embed url="" %} ## Lexicon by Liferay {% embed url="" %} ## Carbon by IBM {% embed url="" %} ## Material Design by Google {% embed url="" %} ## Fluent by Microsoft {% embed url="" %} ## Oxygen by Repsol {% embed url="" %} ## Lighting by Salesforce {% embed url="" %} ## Solid by Buzzfeed {% embed url="" %} ## Mailchimp Design System {% embed url="" %} ## Audi Design System {% embed url="" %} # Contacto Esperamos que esta guía esté siendo de ayuda para ti y para tu equipo. Han sido muchos años hasta llegar a tener todo este conocimiento, ayudando a compañías de todos los tamaños a comenzar, construir, lanzar y demostrar el éxito de su sistema de diseño. Si estás buscando un partner que te ayude y te guíe durante este proceso, estaremos encantados de ayudarte. Y si eres parte de la comunidad digital y quieres darnos feedback, comentar cualquier cosa acerca de esta guía, te apetece que hablemos sobre esto en algún evento o en tu propia empresa o simplemente quieres saludar, ¡nos encantará conocerte también!