Últimamente he escuchado mucho sobre tokens de diseño y, aunque nunca he tenido que trabajar en un proyecto que los necesite, creo que son muy interesantes y vale la pena tomar algunas notas. Según tengo entendido, la idea general es la siguiente: los tokens de diseño son una forma agnóstica de almacenar variables como la tipografía, el color y el espaciado para que su sistema de diseño se pueda compartir en plataformas como iOS, Android y sitios web habituales.
Los tokens de diseño están comenzando a ganar un poco de impulso en la comunidad de sistemas de diseño, pero no son un concepto completamente nuevo. Hay una gran charla con Jina Anne y Jon Levine de 2016 donde hablan sobre cómo se usan los tokens de diseño en el Lightning Design System en Salesforce. Describen la complejidad del mundo en el que vivimos, donde una sola organización que está creando múltiples aplicaciones web y aplicaciones nativas necesita sentirse y verse iguales sin ralentizar al equipo de desarrollo. Jina también ha realizado un curso de video en profundidad sobre tokens de diseño y en la vista previa para eso escribe:
Con los tokens de diseño, puede capturar valores de bajo nivel y luego usarlos para crear los estilos para su producto o aplicación. Puede mantener un sistema visual escalable y coherente para el desarrollo de la interfaz de usuario.
Tomemos solo un ejemplo: probablemente tenga una escala tipográfica que desee que sea idéntica en varias plataformas. En lugar de almacenar los valores para esa escala en un archivo CSS y replicarlos en cada aplicación o sitio web, se pueden almacenar en un archivo JSON que luego se transformará en el código necesario para todas esas otras plataformas. Algo como esto:
{
"global": {
"type": "token",
"category": "typography"
},
"aliases": {
"TYPE_SIZE_SM": {
"value": "14px"
},
"TYPE_SIZE_MD": {
"value": "25px"
},
"TYPE_SIZE_LG": {
"value": "44px"
}
},Puede escribir su propio código para tomar este archivo JSON y convertirlo en todas las variables que pueda necesitar, por ejemplo, un archivo Sass dependería de estos tokens y podría consumirlos como variables para usar en cualquier otro lugar de una aplicación web. Un ejemplo de una herramienta que puede hacer mucho del trabajo duro por nosotros es el Diccionario de estilo de Amazon y aquí hay un ejemplo de cómo funciona en la práctica:
Creo que esto es ridículamente genial. Y puedo ver cómo ahorra una tonelada de código duplicado y confusión en varios equipos, ya que sirve como una única fuente de verdad en lugar de tener varias bases de código que tienen los mismos requisitos de diseño y sus propias hojas de estilo para mantener. Cristiano Rastelli también escribió hace poco sobre la gestión de tokens de diseño con Style Dictionary y profundiza mucho más sobre cómo empezar.
¡Tu fuente de verdad ni siquiera tiene que ser un archivo JSON! En una publicación de principios de este año, Pavel Laptev nos muestra cómo hacer estos tokens de diseño en Figma y, al usar su API, abstraer esos valores de las maquetas de diseño y usarlos en una base de código.
Pavel dividió su documento de Figma en páginas separadas para su cuadrícula, espaciadores, paleta y tipografía de esta manera:
En este momento, parece que esto requiere un montón de esfuerzo para configurarlo, pero creo que herramientas como Sketch y Figma solo harán que cosas como esta sean más fáciles para nosotros en un futuro cercano; probablemente quieran que la fuente de la verdad estar en su herramienta de diseño específica en lugar de en alguna otra herramienta.
Lo último que quiero mencionar es esta publicación de Brent Jackson donde escribió algunas ideas sobre la interoperabilidad cuando se trata de sistemas de diseño. Específicamente, argumenta que debería haber una especificación para los tokens de diseño para que cualquier biblioteca CSS-in-JS pueda consumir ese código en cualquier formato o estilo:
Los tokens del sistema de diseño deben ser flexibles y funcionar en varias plataformas, lo que significa que diferentes equipos, diferentes implementaciones y diferentes bibliotecas nombrarán las cosas de manera diferente. Aquí es donde encajaría esta especificación. Se podría lograr mucha interoperabilidad, si todos, por ejemplo, nombramos nuestra paleta de colores colors y nombró los tamaños de fuente que usamos fontSizes. Lo que haga más allá de eso y el formato de datos que use para almacenar estos valores, depende de usted. Es trivial convertir JSON a módulos ES a YAML o incluso TOML, si eso es lo tuyo. También es solo una estructura de datos, por lo que la transformación entre otras estructuras de datos (por ejemplo, herramientas de diseño o una API GraphQL) también debería ser posible. Este estándar tampoco intentaría resolver los problemas extremadamente complejos de cómo nombrar los colores en sí.
Brent luego siguió adelante y creó una especificación de tema para resolver este mismo problema. Parece que tener un solo estándar para escribir todas nuestras variables y configuraciones nos ayudaría si quisiéramos cambiar de una biblioteca CSS-in-JS a otra, o si quisiéramos cambiar a algún otro sistema que aún no hayamos imaginado. .
De todos modos, creo que los tokens de diseño solo están comenzando a convertirse en una corriente principal y su popularidad está a punto de aumentar a medida que estas herramientas, flujos de trabajo y estándares mejoran con el tiempo: ¡todo es algo completamente emocionante!