Nomenclaturas específicas y flexibles
Profundizamos en cómo plantear la nomenclatura de design tokens dependiendo de nuestro caso, si es un único producto, o varios con diferentes modos.
Hola de nuevo! Hoy regresamos con más artículos después de unas semanas sin publicar. No hemos desaparecido, hemos bajado el ritmo de publicación para preparar algunas novedades que esperemos que pronto os podamos contar!
Yendo al lío, hoy hablaremos sobre los diferentes enfoques de nomenclatura.
La forma en que nombramos nuestros tokens puede cambiar completamente su uso y eficacia y, como vimos hace unos posts sobre los design tokens para sistemas sin marca, si este es nuestro caso la importancia de una buena nomenclatura será fundamental.
Nomenclatura genérica vs específica
Una nomenclatura genérica se basa en crear tokens que pueden ser aplicables en cualquier punto de la interfaz que requiera este valor. Por ejemplo:
$color-ui-green: #1DB954;
$color-black-primary: #000000;
$color-white-primary: #FFFFFF;Esta abstracción tiene la ventaja de ser muy fácil de aplicar para interfaces simples, que no requieran de una complejidad muy grande.
Una nomenclatura específica, en cambio, será aquella que define un token para cada caso concreto de uso. Por ejemplo, diferenciar colores según su uso en fondos, textos, bordes, etc.
$color-background-button: #1DB954;
$color-text-primary: #000000;
$color-background-primary: #FFFFFF;Estos dos planteamientos tienen sus ventajas y desventajas. Una nomenclatura genérica será más fácil de plantear en un primer momento, mientras que la específica nos permitirá controlar mejor la interfaz.
Esto le ocurrió al equipo de Spotify, que nos cuenta en su blog cómo plantearon en un primer momento una nomenclatura genérica que acabó evolucionando a una más específica.
Primero, llamaron a su color de marca “UI Green”. Esta decisión les limitaba, ya que no tenían mapeado dónde aplicaba de forma específica, por lo que hacer grandes cambios les suponía un problema.
Por mejoras de contraste, el equipo quería cambiar este verde en los textos, pero no tenían forma de hacerlo desde los tokens, ya que el “UI Green” se usaba en fondos, textos o cualquier elemento de la interfaz.
La solución fue replantear su nomenclatura para hacerla más específica, creando una diferenciación por uso de su color verde en “Accent Background” y “Accent text”.
Cuanta más específica sea nuestra nomenclatura, más control tendremos sobre la interfaz.
Una vez que consideremos si nuestros tokens tienen que ser genéricos o específicos según la complejidad de nuestra interfaz, tenemos que tener en cuenta su flexibilidad, según queramos que sean extrapolables para otras marcas o temas.
Nomenclatura rígida vs flexible
Una nomenclatura rígida es aquella que crea una estructura de tokens en base a los casos específicos de una interfaz. Puede tener un gran valor para cubrir casos particulares, pero según cómo se plantee, puede que no sea extrapolable a otras interfaces.
Si nuestra interfaz crea combinaciones particulares, usamos diferentes estilos de componentes según la pantalla, si los colores varían dependiendo de sus combinaciones, etc.
Es normal que las interfaces tiendan a resolver casos de formas muy específicas, pero esto llevado a tokens, podrá complejizar nuestra arquitectura.
En contrapunto, una nomenclatura flexible se enfocará en intentar mapear la interfaz de la forma más genérica posible, para que estos tokens se puedan aplicar en otros productos o temas.
Cuanto más flexibles sean nuestros tokens, más fácil será reutilizarlos en otras marcas y crear diferentes modos
Teniendo en cuenta cómo las interfaces tienden a tener una estructura similar, podemos partir de una base como la que propone en su twitter Dmitry Belyaev y adaptarla a nuestro caso.
Así, nos aseguramos que nuestra nomenclatura tenga la flexibilidad para adaptarse a otros temas:
Conclusión
Cada enfoque tiene sus ventajas y desventajas y la elección dependerá de las necesidades específicas del proyecto y su complejidad.
Encontrar el equilibrio entre los diferentes puntos de vista será clave para garantizar que los tokens sean útiles en cada caso.
Tenemos beta de token studio 2.0 🙌
Parece que el equipo de token studio está a punto de lanzar su nueva actualización y están dando acceso a la beta para recibir feedback y terminar de pulirlo.
Principalmente trae soporte al sistema de la W3C DTCG, mejora la exportación de tokens a variables de Figma y da soporte a Bitbucket 🚀
Si queréis trastearla, podéis entrar a su slack en el canal #_beta-v2-open y veréis los pasos a seguir con toda la información
¡Contadnos si lo probáis qué os parece!
¡Gracias por leernos!
¡No olvides suscribirte para más contenido sobre design tokens en español!