A estas alturas, si trabajas como diseñador/a digital estarás cansado/a de escuchar el término “sistema de diseño”, y es que ha sido la palabra de moda de los diseñadores en los últimos años, protagonizando cientos de artículos, conferencias, libros y podcasts.
Existen infinidad de webs que explican sus bondades y recopilan ejemplos, cursos para diseñarlos y manuales sobre cómo implementarlos. Por lo tanto, no quiero que éste sea otro artículo más sobre lo que es y para qué sirve un sistema de diseño, ya que no aprenderías nada que no hayas visto en cualquier otro sitio. Lo que sí me gustaría es compartir nuestra experiencia en marketgoo a la hora de desarrollar nuestro propio sistema, al que hemos bautizado con el nombre de “Ola”.
En nuestro caso, la creación de un sistema de diseño estaba más que justificada, ya que estábamos teniendo bastantes problemas para escalar y diversificar nuestro producto manteniendo una cierta coherencia. marketgoo ya no consiste solo en una aplicación web, sino que está evolucionando hacia una plataforma con muchas ramificaciones, como por ejemplo APIs o un plugin para WordPress. Y por si fuera poco, también ofrecemos la modalidad white label, por lo que es necesaria la posibilidad de añadir cierta personalización de estilos de otros brandings.
Puestos a crear un sistema de diseño, hemos querido aprovechar la oportunidad para repensar algunas cosas, no solo a nivel de forma, sino de fondo: cómo queremos ser, cómo queremos que nos vean y cómo queremos relacionarnos con nuestros usuarios. Y para ello empezamos por definir unos principios de diseño que nos ayuden a enfocarnos en aquello en lo que somos o queremos ser, y no desviarnos de ese objetivo cada vez que tengamos que tomar una decisión de cualquier índole. Estos principios están compartidos y asimilados por todas las personas que conformamos marketgoo, no solo la parte de diseño, sino también desarrollo, growth, success, marketing, etc. Queremos darle al diseño la importancia que se merece y apostar por él como un factor estratégico y clave en el futuro de nuestro producto.
Otra acción significativa fue la de ponerle un nombre al sistema. Parece una cosa menor, pero de repente deja de ser “esa cosa”, ese conjunto de estilos y diseños y pasa a tener una entidad propia, a ganar importancia y ser tratado como una herramienta más dentro de nuestro workflow diario. Los desarrolladores lo nombran al igual que nombran otras herramientas como React, Webpack o Docker.
Tener un nombre le da ese estatus, da igual el que escojas, lo importante es que tenga uno, y que la gente lo use. En nuestro caso queríamos que tuviese algún tipo de relación con el mar, ya que siempre estuvo muy presente en la la imaginería de marketgoo (a pesar de ser una empresa creada en Madrid), y de ahí surgió el nombre de “ola”.
Otra clave muy importante fue conseguir que todo el mundo viese claro su potencial y le diese prioridad. Implementar un sistema de diseño no es solo responsabilidad del equipo de diseño, sino que es algo que incumbe a todos los equipos y todos debemos remar en la misma dirección. El hecho de que tanto nuestro CEO como el equipo de desarrollo, producto o growth supieran ver su valor estratégico, otorgándole la máxima prioridad, es algo que no pasa en todas las empresas y (otro) motivo para sentirse orgulloso de trabajar en marketgoo, rodeado de gente profesional y responsable.
ola es un sistema vivo, es decir, irá evolucionando y mejorando continuamente. No quisimos abarcar demasiadas cosas juntas por varias razones. La primera: debido a los recursos de los que disponemos, ya que somos un equipo pequeño, entre ellos solo un diseñador y 5 desarrolladores. La segunda es que mientras que diseñamos e implementamos el sistema, la máquina debe seguir funcionando. No nos podemos permitir el lujo (ni tampoco sería recomendable aunque pudiéramos hacerlo) de pararla para dedicar unos meses a rehacer todo. Por lo tanto, es mucho mejor trabajar por fases, haciendo cambios y mejoras poco a poco e intentar que no se nos rompa nada por el camino.
En esta primera fase, los cambios y mejoras en los que estamos trabajando están enfocados en dos direcciones. A nivel de desarrollo, eliminar gran parte del “spaguetti code” de frontend, cambiándolo por componentes reutilizables y desacoplados, permitiéndonos ir mucho más rápido en un futuro. Y a nivel de diseño e interfaz, corregir muchos problemas de usabilidad y accesibilidad básicos: texto demasiado pequeño y con poco contraste que dificulta la legibilidad, estilos para estados como focus o active, mejora de navegación con el teclado, formularios más usables, consistencia, etc.
Incluso hemos cambiado nuestro color corporativo, oscureciéndolo un poco para mejorar el contraste y que cumpliese con el nivel AA del estándar de WCAG. Un claro ejemplo del nivel de compromiso adquirido hacia nuestros principios de diseño y el objetivo de ser más accesibles e inclusivos.
Aún nos queda mucho trabajo por delante. Como dije antes, estamos en la primera fase y hemos dedicamos tanto o más tiempo a pensar y tomar decisiones (y rectificar algunas después) que en hacer cosas. No queremos reinventar la pólvora, consideramos que el mejor diseño es el que tiene el sentido común como ingrediente principal, pero sí que queremos que nuestro sistema madure al mismo tiempo que lo hacemos nosotros, y que sea el sistema el que se adapte a nuestro producto y no al revés.
Todo este proceso está siendo muy enriquecedor para todos. Cabe resaltar que aunque todo el mundo está aportando y dando feedback, el proyecto está liderado por un diseñador que sabe escribir código y un programador con experiencia previa como diseñador (Pedro Parra). Poder contar con perfiles híbridos diseño/desarrollo ayuda enormemente a generar sinergias y al buen entendimiento para alcanzar un fin común.
Como herramientas, estamos usando zeroheight para documentar. Nuestra idea es ir actualizando la documentación, no solo con nuevos componentes o estilos, sino también añadiendo links a artículos y estudios que avalen las decisiones que vamos tomando. Mantener un sistema de diseño es una tarea ardua y compleja, por lo que preferimos hablar poco, mostrar mucho y apoyarnos en la medida de lo posible con links a artículos externos.
Por supuesto, también usamos software de diseño, en nuestro caso Sketch,* aprovechándonos de todas sus funcionalidades como la sincronización con zeroheight, librerías, prototipos navegables, etc.
Ya hemos desarrollado varios componentes en javascript que están documentados usando Storybook y nuestra idea es liberarlos como open source cuando nos sintamos lo suficientemente cómodos con el resultado. Pero de ese proceso, mejor os hablará Pedro en otro post.
Mientras tanto, os mantendremos informados.
* Actualización 2022
Con el tiempo, el sistema ha ido creciendo no solo en número de componentes sino también en las diferentes áreas que cubre.
Hemos incluido ilustraciones cuyos colores se pueden personalizar para la marca blanca y una guía de estilo para los textos.
En cuanto a los textos, hemos diseñado un flujo de trabajo para sincronizar mejor el trabajo de redactores, diseñadores y desarrolladores. Este flujo de trabajo conecta una hoja de Google, donde trabajan los redactores, con Figma (gracias a un plugin que desarrollamos internamente) y algunos scripts para que los desarrolladores obtengan la última versión de las copias automáticamente, lo que garantiza que cualquier actualización se reflejará automáticamente en los prototipos Figma y el desarrollo frontend.
Cuando estábamos en las fases iniciales de implementar Ola, manifestamos nuestras intenciones de que sea un sistema de diseño open source, y ahora podemos decir que lo es.
*Al momento de publicar este post, usábamos Sketch, pero a partir de la última edición, usamos Figma.
