HOW WE THINK

Behind our thoughts.

Straight from our minds to our blog to provide our audience valious insights.

scroll

¿En qué momento crear un Design System? Según la escala del proyecto

Autor: Jose Pablo Trejos
Tiempo de Lectura: 6 minutos
Contexto

Actualmente existe una gran variedad de artículos que hablan sobre distintos modelos utilizados para crear o adoptar un Design System, independientemente del proyecto en el que estemos trabajando.

 

Entre las ventajas que nos exponen de trabajar con un Design System podemos encontrar que nos brinda consistencia a lo largo del desarrollo del proyecto ya que estandarizamos elementos y esto a la vez nos permite la reutilización de componentes mediante un sistema ordenado. Y es que la finalidad de implementar un Design System radica en que equipos conformados por varios integrantes puedan trabajar con los mismos estándares, a un ritmo aceptable y con los mismos elementos, aquí hay que hacer especial énfasis ya que su correcto uso nos va a ahorrar mucho tiempo de revisiones y correcciones, pero… ¿Siempre es necesario implementarlo? 🤔

 

¿Por qué deberíamos implementar un Design System?

Ok, vamos por partes, primero me gustaría contarles el porqué es buena idea considerarlo dentro de las etapas de un proyecto, y para esto me voy a apoyar en un ejemplo que muchos diseñadores hemos vivido. Creo que a la mayoría nos ha pasado que después de algunas horas de trabajo sobre varias pantallas, nos disponemos a unificar nuestro trabajo con el resto de las pantallas que fueron elaboradas por los demás miembros del equipo y para nuestra sorpresa… la unificación resulta en algo como esto: 🤦🏻‍♀️

 

Design System

 

Para nuestros efectos podemos decir que estas imágenes son equivalentes, ya que lejos de parecer un chiste nos encontramos un archivo con múltiples estilos y no solo de botones, sino que descubrimos que se utilizó la misma tipografía, pero en diferente tamaño o que el color es muy similar pero no es idéntico… en fin, un caos dentro del archivo y muchos componentes sin estandarizar.

 

De entrada, podríamos decir que no son errores graves y que la esencia se mantiene, pero aquí es donde identificamos el segundo aspecto del porqué implementar un Design System y es que los diseñadores, en muchas ocasiones, no consideramos a los
desarrolladores y la “bomba” con la que tienen que lidiar, además del viacrucis que les planteamos con archivos o insumos tan desordenados.

 

¿Cuál color de botón debería de elegir? o ¿cuál es el tamaño adecuado de la tipografía? Estas preguntas son solo ejemplos de lo que podría pasar en el mejor de los casos donde los desarrolladores se percatan de estas diferencias, pero ¿qué pasa si no se enteran y solo toman de referencia el primer elemento que encuentran? 😱 Podríamos estar acarreando un problema que cada vez se vuelve más complicado y tedioso de corregir y nuestra deuda técnica como diseñadores aumenta. Esto repercute en la eficiencia y productividad del equipo, lo que nos lleva a un tercer punto, entre menos se tenga que corregir más tiempo podremos dedicar a mejorar otros aspectos relevantes o proyectos.

 

Tenemos claro que no solo es una cuestión de ejecución sino también de metodologías de trabajo implementadas en el equipo, pero ese es tema para otro artículo 🤓.

 

Ahora que tenemos más claro los beneficios y lo que nos puede aportar un Design System a nuestros proyectos, podemos mirar en retrospectiva y analizar si estas características se ajustan a todos ellos, pero ¿han pensado el esfuerzo que se requiere para generar estos sistemas de componentes? Y más importante aún ¿en qué momento crearlos 🤔?

 

¿Cómo y cuándo creamos nuestro Design System?

Esta pregunta no es fácil de contestar, habrá una gran cantidad de colegas que respondan a ella a partir de la teoría que se puede estudiar, pero es que la práctica en la mayoría de las ocasiones no es cien por ciento fiel a lo escrito y desde esta perspectiva es que voy a compartirles nuestra experiencia. Cada proyecto se debe abordar como un caso particular y específico, debido a sus características únicas o el área de interés que abarca. Si vemos el desarrollo del proyecto como algo lineal y sin variación sería muy difícil ubicar en algún punto la implementación del Design System, existen factores que pueden influir en su creación como por ejemplo el alcance del proyecto; en ocasiones este se limita al rediseño o ampliación de una funcionalidad específica, también puede ser que el cliente no desee este material para su proyecto, así que en estos casos no es posible la creación del sistema y no por ello quiere decir que sea un proyecto deficiente o malo. Al contrario, podríamos encontrarnos con un proyecto que por su complejidad y la cantidad de equipos involucrados demande de un sistema que ayude a mantener el orden y control.

 

MVP vs Producto posicionado

Veamos un par de ejemplos para aclarar este punto, primero imaginemos que la empresa en la que trabajamos desarrolla productos digitales propios (como Spotify, Airbnb o Netflix) y está por realizar una mejora en alguna de sus plataformas previamente desarrolladas, si no contara con un Design System podríamos enfrentarnos a todas las calamidades que mencionábamos anteriormente, que se trabajen con componentes parecidos pero no iguales a los que están en la plataforma, que el trabajo entre diseñadores y desarrolladores no sea fluido o que inclusive los patrones de diseño cambien.

 

Esto afectaría directamente a la consistencia y la percepción de marca con la que contaban sus usuarios. Lo adecuado en este caso es que si a esta altura no se cuenta con la librería de los componentes entonces se proceda a generar el Design System previo a
realizar la nueva mejora, en este punto la ventaja es que al contar con una plataforma previa la componetización se simplifica ya que los elementos se encuentran estandarizados y la tarea principal se centraría en la recopilación de estos y la generación de la librería como insumo.

 

Para muchas empresas este trabajo fue un aprendizaje empírico a través del tiempo por lo que probablemente su implementación se dio en alguna versión avanzada de la plataforma por lo que es notoria la mejora incremental.

 

Pero ahora veamos el segundo escenario, ¿sucede lo mismo cuando se trabaja un MVP o un proyecto totalmente nuevo? Podemos decir que “Aquí es donde la mula botó a Genaro” en muchos artículos hemos encontrado que el momento idóneo para la creación
del Design System es antes de iniciar el proyecto, incluso en el ejemplo anterior lo pudimos ver, pero ¿cómo se genera una librería de algo que aún no existe o que su diseño no está definido? No tiene sentido invertir tiempo y recursos en una librería que va a estar en constante cambio durante el inicio del proyecto incluso podría generar confusión, además contamos con la necesidad de generar productos con prontitud para someterlos a pruebas y aquí es donde se debe tomar una decisión basada en el contexto y las características del proyecto.

 

Para un escenario como este podemos encontrar soluciones alternativas que no necesariamente son un Design System como tal, pero funcionan de igual manera, proporcionan orden y permiten que un equipo se logre coordinar de mejor manera.

 

La primera alternativa sería contar con una librería de los elementos de navegación más comunes, pero que dichos elementos se encuentren en un estado base, que posteriormente se le pueda dar un estilo que se defina durante el proyecto, la llamamos la librería machote y la principal ventaja es que desde una etapa muy temprana permite que todo el equipo trabaje con los mismos estándares, hay que entender que esta librería no cuenta con componentes complejos, es decir podemos encontrar lo verdaderamente básico como botones primarios, inputs y dropdowns. Esta opción permite que en etapas posteriores cuando se otorgue un estilo o se agreguen componentes específicos del proyecto se trabaje sobre la librería y así lograr una actualización automática del archivo principal. La alternativa funciona especialmente cuando se trata de un equipo de varios diseñadores.

 

Design System 2

 

También existe la posibilidad de trabajar directamente en el archivo principal del proyecto y crear los elementos básicos desde ahí, aquí la recomendación o la buena práctica sería crearlos y guardarlos como símbolos, por ejemplo una herramienta como Sketch nos permite hacerlo, esto nos asegura que al trabajar con el archivo encontremos ahí mismo la estandarización y el orden necesario para trabajar con mayor fluidez, esta opción es recomendable cuando es una persona la que se encuentra desarrollando el proyecto y no un equipo, ya que al trabajar de forma local la posibilidad de compartir la librería y poder actualizarla se dificulta.

 

Las ventajas de contar con un Design System son muchas y son notorias, pero la realidad es que más allá de requerir de equipos que entiendan y logren aprovechar al máximo estas herramientas, se necesita entender que de entrada un Design System para cada proyecto desarrollado puede significar una carga de trabajo y un enfoque de esfuerzo que en un inicio no son primordiales. Con productos posicionados toda esta filosofía de trabajo cobra mucho sentido, pero cuando se trabajan proyectos tan variados, de diferentes escalas, con diferentes alcances y con diferentes presupuestos la realidad es que pueden ser más flexibles otras opciones que eventualmente en un futuro permitirá la creación de un Design System propio.

Scrum y equipos de diseño

August 18, 2020

El valor de la investigación en el desarrollo de nuevos productos

July 22, 2020

¿Cómo influye el microcopy en la experiencia de usuario?

July 9, 2020

This website uses cookies

We use cookies to personalise content and ands, to improve the usability, provide social media features and to analyse our traffic. We also share information about your use of our site with our social media, advertising and analytics parteners who may combine it with other information that you’ve provided to them or that they’ve colleted from your use of their services. You consent to our cookies if you continue to use our website.

OK SETTINGS

Cookies are small text files that can be used by websites to make a user's experience more efficient.

The law states that we can store cookies on your device if they are strictly necessary for the operation of this site. For all other types of cookies we need your permission. This site uses different types of cookies. Some cookies are placed by third party services that appear on our pages. You can at any time change or withdraw your consent from the Cookie Declaration on our website.

Learn more about who we are, how you can contact us and how we process personal data in our Privacy Policy.