Diferencias entre Design System y UI kit
En este artículo abordaremos las complejidades de estos dos conceptos aparentemente similares, exploraremos cómo cada uno desempeña un papel crucial en el proceso de diseño y cómo pueden impactar el resultado final.
Hoy en día la innovación y la eficiencia son clave, por lo tanto comprender cómo y cuando utilizar estas herramientas -o no- de manera efectiva puede marcar la diferencia entre un diseño mediocre y uno excepcional. Nos enfocaremos en que comprendas la teoría y así puedas impulsar tu desarrollo profesional. Sin más preámbulos, vamos a ello.
Partamos por entender los conceptos de forma individual para luego compararlos.
Design system (D.S.)
¿Sabías que es un término antiguo?. Fue mencionado por primera vez en la Conferencia de Ingeniería de Software de la OTAN de 1968 por Christopher Alexander, quien más tarde publicó el libro “A Pattern Language”. En ese libro definió el concepto como:
“Sistemas que están destinados a servir como un marco de patrones interconectados que simplifican y optimizan los esfuerzos de diseño que van desde la arquitectura hasta los productos digitales como sitios web y aplicaciones”.
A medida que avanzó la tecnología y la omnicanalidad, la necesidad de sistemas y estándares se hizo más evidente; y el concepto nuevamente tomó fuerza.
El objetivo del Design System es orientar a toda la organización y agilizar la toma de decisiones para que todo el equipo vaya en la misma dirección.
¿Qué aspectos define un Design system?
Si bien todos los D.S. son adaptados a las necesidades de la empresa/producto o proyectos y no existe una regla, algunas de las cosas más comunes que suelen definirse son: estilos visuales (tipografía, paleta de colores, iconografía, espaciado), directrices de diseño (documentación detallada sobre el uso de elementos, tono y tipos de comunicación), principios de interacción (usuarios, componentes, estructura de la información), organización de la información y arquitectura de la interfaz, consideraciones de accesibilidad, entre otros.
Todo este contenido sirve como una guía integral que establece las bases para el diseño de interfaces, asegurando la consistencia en todo aspecto.
Te recomiendo revisar estos sistemas publicados por Atlassian, también puedes revisar el de Apple, Material Design de Google o el de IBM, todos estos son ejemplo de sistemas complejos, escalables y robustos.
Pero no todos los productos necesitan un D.S. tan extenso, no te presiones y pregúntate: ¿Este producto realmente necesita uno?
Implementar o no un Design system
No todas las empresas/productos o proyectos lo necesitan, ya sea porque se trata de productos muy pequeños o de bajo alcance o por tratarse de un proyecto con un deadline muy corto. Quizás sería más costoso implementarlo que no tenerlo debido a la escasez de recursos (tiempo, humanos, expertise, capital, etc).
Ya sea que elijas comenzar a crear un D.S. o no, esta decisión debe estar justificada.
Si decides crear un D.S. antes de comenzar el producto, siempre será más fácil que hacerlo sobre uno que ya está en marcha. Si tu caso es el segundo, te recomiendo comenzar explorando las similitudes presentes en todos los componentes e interfaces que ya existen, también puedes empezar a identificando patrones.
En otro artículo hablaremos a profundidad de cómo construir un D.S. básico con pocos recursos, pero si quieres comenzar ahora te recomiendo ver esta serie de videos, o leer este artículo publicado por UX en español. La comunidad de Figma también tiene muchos ejemplos y material gratuito para duplicar y revisar a detalle.
Entonces, ¿Cuándo vale la pena crear un Design system?. Simple: cuando es un proyecto a largo plazo.
¿Quiénes lo ocupan?
Los roles que utilizan un D.S. son diseñadores de interfaces de usuario, UX/UI, visuals, content, ux writer, desarrolladores front-end y equipos de producto. Que muchos roles tengan acceso a este sistema y puedan utilizarlo, es lo que garantiza que todos tomen decisiones consistentes y que el producto sea y se vea coherente.
¿Quién crea el Design system?
Dependiendo de qué tan grande es la organización pueden involucrarse muchos roles; UIs, especialistas de producto, UX writers, devs front-end, researchers, Uxs, gestores, product managers o especialistas en accesibilidad.
En un mundo ideal estos roles podrían trabajar en colaboración para crear un D.S. efectivo. Incluso en grandes empresas internacionales hay roles llamados “Design system managers” los cuales se dedican exclusivamente a la mantención y escalabilidad del mismo, ¡Qué nivel!.
Sin embargo, volviendo a Chile, lo más común es que en empresas o equipos pequeños esta misión por roles tienda a difuminarse y se involucren los que existan disponibles.
Para que todos los roles tengan acceso a este sistema, suelen publicarse en plataformas colaborativas, con frecuencia se utiliza Figma, pero existen otras como Backlight.
UI Kit (U.K.)
También conocido como Kit de Interfaz de Usuario, podría definirse como una “biblioteca de recursos visuales y funcionales”. Es una herramienta esencial para profesionales del diseño de interfaces, UX/UI, visuals y devs front-end.
¿Qué aspectos define un UI Kit?
Un U.K. por lo general incluye las definiciones de botones, íconos, tipografías, espaciados, layouts, grillas, tooltips, modales, estándar de colores, estados por componentes, alertas, mensajes de validación, estilos de color por estado, animaciones, etc. También deberían estar especificados para cada breakpoint si el proyecto considera la responsividad, también debe asegurarse su viabilidad en diferentes sistemas operativos.
¿Quiénes lo crean?
La primera etapa de un UI Kit es la co-creación conceptual y la definición de funciones, estados y características de cada elemento que aparecerá en la interfaz (por muy pequeño que sea) entre todos los responsables de su ejecución. Estos roles suelen ser diseñadores UI, UX/UI, visuals y devs front-end.
Normalmente luego de esta primera aproximación, comienza la segunda etapa en dónde los diseñadores UI construyen todo lo acordado en un software para el desarrollo de interfaces. Existen muchos, tales como Figma (este software es muy utilizado principalmente porque permite que muchos diseñadores trabajen en el mismo documento en tiempo real), AdobeXD, Sketch, Corel Vector (Gravit Designer), InVision Studio, Framer, entre otros.
La segunda etapa es importante para los diseñadores, ya que deben crear visualmente los componentes, darles nomenclatura, asignar animaciones, crear estados y variables por cada uno de ellos; para luego también reutilizarlos al momento de diseñar. Este paso va a permitir a los diseñadores agilizar también sus próximas interfaces y facilitará la elaboración de mockups de alta fidelidad coherentes con el producto final.
Si necesitas entender mejor este tema, te recomiendo visitar el canal de mi profesor online favorito, Raúl Marín. Se dedica a crear contenido para aprender Figma, aborda el UI kit y el D.S. desde el punto de vista de diseñadores (te lo recomiendo mucho; está en español).
Luego de haber ejecutado toda la segunda etapa por parte de los diseñadores UI, se puede hacer el traspaso a los roles devs Front-end. Ellos son los encargados de construirlo en el código para tangibilizarlos en el producto digital. Esta etapa de “traspaso” podría incorporar feedback y estimaciones cruzadas, también lo común es que se realicen entregas por etapas o por nivel de prioridad.
Y por último, en la tercera etapa los devs son los responsables de desarrollar y disponibilizarlos al resto de su equipo. Normalmente esta información la disponibilizan en Frameworks. Aquí puedes revisar el increíble framework de Apple.
Pese a que te muestro ese ejemplo, considera que no hace falta elaborar millones de variables por componentes, lo que importa es que funcione en la teoría y en la práctica. Para esto es fundamental que el equipo se haga cargo de las decisiones tomadas, de la construcción del mismo y de la implementación.
También pueden existir encargados del proyecto, los que deben velar por su correcta implementación.
En organizaciones rigurosas podrían incluso pasar por procesos de QA y evaluar que las animaciones funcionen correctamente en cada estado por componente; estas decisiones son tomadas por lo general en base a la madurez del equipo, los recursos disponibles y la gestión del Product con respecto al roadmap. Cada equipo tendrá sus procesos y tiempos según sea su realidad.
¿Quiénes lo ocupan?
Suelen ser los mismos roles que se dedican a su creación: diseñadores UI, visuals y desarrolladores front-end.
Novedades
También existen empresas que se dedican a crear D.S. y U.K. para venderlos o ofrecerlos gratuitamente a la comunidad.
Es decir, puedes conseguirlos en vez de construirlos.
Y si bien es muy rápido saltarse el proceso de creación, es importante considerar que si tu proyecto busca diferenciarse del mercado, resaltar, o requiere muchas funcionalidades complejas para mostrar en la interfaz, puede volverse un problema.
Ya que al adquirir estos tipos de D.S. y U.K “externos” te arriesgas a que no puedan personalizarse, es probable que tampoco puedas agregar componentes a la librería. Por lo tanto, te recomiendo que siempre antes de tomar una decisión de este tipo, pidas la opinión del equipo IT. Hará falta que los roles de desarrollo hagan las correspondientes averiguaciones de librerías más convenientes para el proyecto según el estado del código actual.
Aquí puedes revisar algunos a la venta, envatoElements, creative market, Untitled-ui, Ui8. Y acá algunos gratuitos como los de Figma community, también FDR (hay muchos más, aquí sólo te he dejado algunos ejemplos).
Concluyendo
Mientras que un sistema de diseño establece los principios y estándares generales de toda la experiencia y la estructura subyacente del diseño de interfaz, un UI kit ofrece elementos visuales y funcionales específicos que pueden ser implementados rápidamente dentro del proceso de prototipado y desarrollo.
Ambos buscan agilizar el proceso de construcción de un producto digital en todas las etapas de creación.
Te dejo esta tabla que destaca las diferencias claves entre ambos conceptos, en términos de enfoque, alcance, componentes, flexibilidad y nivel de abstracción.
Y quizás hace falta mencionar que también son distintos a las guías de estilos y manuales de marca.
No te confundas pensando que un “sistema de diseño” es lo mismo que una “guía de estilos”, ya que estas últimas se centran principalmente en la apariencia. Recuerda que un sistema de diseño va más allá, al incluir aspectos como la interacción y la experiencia de uso que forma parte de esos elementos.
Al explorar los conceptos Design System y UI kit de forma individual, queda claro que ambos desempeñan roles distintos pero complementarios. Ambos ofrecen recursos valiosos que aceleran el proceso de diseño y desarrollo de interfaces pero ambos requieren una alta inversión de tiempo, metodología y roles comprometidos.
Al principio es costoso invertir recursos para crearlos, pero luego -si todo sale bien- facilita un rápido delivery y acorta las estimaciones de esfuerzo.
Ahora ya sabes qué son, para qué sirven, los roles a cargo y quienes los utilizan, pero si te estas preguntando…
¿Cómo comienzo? ¿Puedo hacerlo sola? ¿Cómo se lo entrego al equipo de desarrollo? ¿Cómo agilizan el prototipado de los diseños? Todo eso lo responderemos en próximas entregas, quédate en la comunidad.
Si consideras que este contenido te ha ayudado, compártelo para que llegue a más personas.
Muchas gracias por leer! Bienvenida a +Mujeres en UX Chile.
Disclaimer: Este artículo presenta consejos actuales. Es probable que la mayoría de los puntos generales sigan siendo válidos durante años, pero los detalles cambiarán a medida que cambien las metologías y las tecnologías.
