Fichas en sistemas de diseño

10 consejos para diseñar e implementar decisiones de diseño para todos

En una reciente revisión de código, mis pasiones se agitaron mientras recorría el estilo de un componente de la píldora con un compañero de equipo de diseño.

Difícilmente podría contener mi emoción:

"Mira. Sí, es un código, pero observa detenidamente esos tokens. ¿Sabes cómo se ve esto? Como especificaciones! ¿Y qué? Puedo leer esto, como tú. Y podemos enhebrarlos en todas partes: documentos, diseños y convos también. ¡En todos lados!"

La reacción de mi compañero de equipo insinuó curiosidad, incluso si no coincidía con el golpe emocional de mi arrebato. No es un geek del sistema como yo. Todavía no, al menos. Pero él entendió lo que importaba: hay un camino visible para las decisiones que tomamos sobre dónde se implementan.

Hemos invertido mucho esfuerzo tratando de sacar el diseño de nuestras variables, esos bits de código más atómicos y reutilizables, me sentí instantáneamente atraído por la idea de volver a colocar el diseño.

Así es como evolucionamos, diseñamos e implementamos tokens a lo largo del diseño, el código y la colaboración.

De variables a tokens

Cada sistema de diseño ofrece opciones. Por ejemplo, los colores pueden escalar del negro a través de neutros al blanco. Cada neutral, identificado mediante un código HEX como # 2B303B, se puede almacenar y poner a disposición en una variable $ color-neutral-20, para usar en un preprocesador como Sass.

Las variables eliminan el misterio de los valores oscuros. Pero no cierran la brecha entre nombrar y usar. Responden "¿Qué opciones tengo?", Pero dejan "¿Qué elección hago?" Poco claro.

Las opciones no son lo suficientemente buenas.

Decisiones de diseño, una opción aplicada a un contexto

La fortaleza de un sistema proviene de saber cómo aplicar opciones (como $ color-neutral-20) a contextos (como un color de fondo oscuro convencional). Esto fundamenta la opción como una decisión.

¡Esas son decisiones que puedo usar con confianza!

Sin embargo, tales decisiones generalmente aún están ocultas en algún archivo en algún repositorio utilizado por los desarrolladores que trabajan en el producto web que poseen. ¿Qué hay de los diseñadores? Otros productos web? ¿En otras plataformas como iOS y Android? Hemos codificado las decisiones para todos, pero eran dueños de un mazmorra de un repositorio que nadie más puede encontrar.

Fichas de diseño, decisiones propagadas a través de un sistema

Salesforce UX ofrece un vistazo. Sus ideas me cautivan, sobre todo su concepto de Guía de estilo de vida que aplica tokens de diseño en todos los productos utilizando su herramienta Theo de código abierto.

Aquí, las opciones y decisiones no están enterradas en los archivos Sass. En cambio, se centralizan y propagan como tokens a cualquier producto, diseñador o desarrollador que adopte el sistema, en formatos predecibles y fáciles de usar.

Cientos de tokens pueden convertirse en decisiones legibles, intencionales y rastreables entretejidas en los productos de una cartera o empresa.

¿Ve las decisiones como una hoja de especificaciones grande? Yo puedo. Los diseñadores también pueden. Con tal visibilidad y herramientas, reconocen el impacto de sus decisiones. Antes, nos decidimos por $ color-neutral-80 para un borde o fondo con un poco de fantasía. Ahora, estamos aplicando $ border-hairline o $ background-color-light de una manera reflexiva y convencional.

Los diseñadores comienzan a colaborar. Toman decisiones con más deliberación y confianza, organizan sus pensamientos en una estructura que comparten. Los desarrolladores hacen lo mismo.

Esto puede transformar actividades meticulosas como líneas rojas y medición de píxeles en una colaboración rica en conversación simbólica. En todo nuestro trabajo, criticando conceptos de diseño, escribiendo criterios de aceptación, revisando solicitudes de extracción, la arquitectura e implementación de tokens está siempre presente.

Fichas de arquitectura

Una arquitectura de token duradera y exitosa depende de una agrupación, ordenación, clasificación y toma de decisiones directas.

# 1 Mostrar opciones primero, luego decisiones luego

No puedes tomar decisiones sin opciones. Los tokens son un instrumento eficaz para ilustrar el camino de uno a otro.

En nuestros archivos de tokens, comenzamos con opciones como los colores disponibles. Después de eso, aplicamos opciones a contextos como "color de texto" y "color de fondo".

Para llevar: Organice sus decisiones para sugerir su base atómica: construcción de opciones a decisiones y simple a compleja.

# 2 Comience con Color y fuente, ¡y no se detenga allí!

A menudo hablo de los tres grandes de un lenguaje de diseño: color, tipografía e iconografía. Por lo tanto, no sorprende que nuestro archivo de token comience con opciones y decisiones de color y tipo (los iconos están automatizados en otros lugares). Sin embargo, el estilo visual se compone de mucho más, y también los tokens.

Si bien comenzaremos aplicando color al fondo y al texto, nos expandiremos a muchos otros tipos de decisiones, incluidas las siguientes:

Para llevar: Comience con, pero no se detenga solo con el color y el tipo. Amplíe sus decisiones para cubrir las innumerables preocupaciones de un lenguaje de diseño.

# 3 Variar opciones a través de escalas significativas

Muchos conceptos simbólicos incluyen escalas para elegir, como el tamaño de la camiseta (XS, S, M, L, XL, XXL), progresiones (como una geometría 2, 4, 8, 16, 32, 64) o terminología personalizada (como compacto, acogedor y cómodo). Las escalas también pueden comenzar con algunas opciones (solo S & M) y crecer para incluir más según lo justificado.

Las escalas permiten ramificar una jerarquía de tokens a variantes similares pero distintas, como enriquecer la inserción espacial (de XS a XL) a las variantes de aplastamiento de inserción espacial y estiramiento de inserción espacial (que también ofrecen XS a XL).

Acordar un modelo a escala: camisetas o progresiones, ¡tú decides! - Para rangos como estos es un esfuerzo específico del equipo. Aún más difícil, deberá evitar escamas endurecidas que no sean resistentes para insertar un paso en el medio más adelante.

Para llevar: adopte y tokenice escalas y demuestre cómo se aplican en diferentes escenarios.

# 4. Invita a contribuir, pero conserva la colección

¿Cuándo una elección garantiza convertirse en una ficha? Un solo uso: no, no lo suficiente. Un segundo puede carecer de convicción. Pero tres? Si aparece tanto, generalmente es digno de token. Existen excepciones, pero el criterio "¿Se ha usado 3 veces?" Fundamenta la discusión.

Entonces, ¿quién es el guardián de la ficha? Nadie, si empleamos procesos saludables para el diseño y las revisiones de desarrollo. Cualquiera puede proponer tokens, aparecer candidatos en un concepto o solicitar solicitudes. Nuestro canal Slack también tiene muchas conversaciones simbólicas.

Sin embargo, sirvo como curador de tokens, escaneando el trabajo con miras a los candidatos de tokens. Puedo hojear el marcado de una solicitud y omitir el JavaScript. Sin embargo, escaneo a fondo los archivos de estilo y token con nombres delicados, reclasifico a los candidatos rebeldes y desafío la expansión excesiva. Todos tienen una voz simbólica. Pero no todos se preocupan lo suficiente o tienen tiempo para mantener las fichas limpias.

Para llevar: Haga que los tokens sean un esfuerzo de equipo y (aunque sea implícitamente) designe una mente arquitectónica estructurada para comisariar la colección.

# 5. Decisiones graduadas de componentes a fichas

Es una distracción desviar la capacidad intelectual para pensar constantemente en fichas, fichas, fichas. “¿Debería ser esta una nueva ficha? ¿Es eso una ficha? ¿No estoy usando un token? ¡Oh, no! Nadie necesita esta fricción.

Sin embargo, mi compañero de equipo Kevin Powell tiene un hábito saludable de almacenar variables en la parte superior de un archivo de estilo de componentes. Por ejemplo, una parte de las variables en uso en el estilo de su componente de formulario identifica muchas aplicaciones de color de texto para formar elementos como errores en línea, entrada, etiquetas y texto de marcador de posición.

Archivo de componentes emergente a la izquierda, con variables específicas de archivo en la parte superior fáciles de comparar y considerar para el archivo de tokens a la derecha.

Estas variables específicas del componente ofrecen un inventario útil de candidatos para graduarse en la biblioteca de tokens. Aquí, podemos aprovechar la oportunidad para reemplazar un color deshabilitado menos específico de $ color-neutral-90 con su color más intencional $ background-color-disabled en el archivo form_elements.styl. Por otro lado, el componente $ border-color-input-hover del componente tiene menos probabilidades de reutilizarse más allá de los formularios y, por lo tanto, es un candidato token deficiente.

Para llevar: Fomentar hábitos en el diseño y desarrollo que estacionen las decisiones reutilizables - candidatos simbólicos - en un lugar predecible como la parte superior de un archivo de texto o esquina del diseño artístico.

# 6. Hacer frente al cambio sistémico previsiblemente

Los tokens son una herramienta maravillosa al formular un sistema inmaculado desde cero. Pero, ¿qué pasa con 18 meses a partir de ahora, cuando las decisiones de diseño evolucionan? ¿Cómo cambia un token la cascada? ¿Cuáles son los riesgos y cómo los mitiga?

Los tokens lo protegen de un cambio impredecible y generalizado dada su especificidad y, como resultado, un uso más limitado e intencional.

Buscando una variable genérica

Anteriormente, combina y evalúa un repositorio para un código hexadecimal # 2B303B o una variable $ color-neutral-20 aplicada a una miríada de elementos diferentes. ¡Abucheo!

Buscando una decisión específica.

Ahora, está rastreando la amplitud del uso de $ text-color-microcopy con precisión y reduciendo el riesgo. ¡Sí!

Para llevar: aproveche los beneficios de mantenimiento de un token y utilícelo como un punto de venta para su equipo de adopción.

Implementando tokens

La mayoría de los equipos comienzan a consolidar las decisiones como una enorme pila de nombres de variables jerárquicas predecibles en un archivo SASS o Stylus. Pero ese archivo entierra las decisiones en un solo lugar, lo que limita el uso de esa tecnología.

Eso deja la promesa de fichas sin cumplir. Un primer paso para difundir los tokens en un sistema es liberarlos con un formato abierto como JSON.

# 7. Hacer que los datos de token sean reutilizables, a través de JSON

JSON es un estándar abierto ideal para codificar pares de nombre / valor jerárquico para su reutilización en todas las herramientas.

Con los tokens en JSON, puede transformar las decisiones para múltiples preprocesadores (SASS, Stylus y LESS) según lo requiera su comunidad. Esto abre la puerta a productos limitados a un preprocesador que no pueden dejar o no dejarán atrás, incluso si no es el "recomendado" del sistema.

Del mismo modo, JSON crea un puente hacia otras plataformas, ya sea directamente consumidas en el trabajo de iOS o transformadas en XML para los equipos de Android.

Para llevar: codifique tokens en un formato reutilizable en todas las plataformas, exponiéndolos en una forma que todos puedan usar.

# 8. Administre y lea datos de tokens fácilmente, a través de YAML

JSON es poderoso, jerárquico y flexible. Sin embargo, es imperfecto como un lugar para administrar datos. La sintaxis es detallada, propensa a errores cuando se selecciona manualmente, carece de soporte para comentarios y carece de variables.

Ingrese YAML, un lenguaje más legible para los humanos para registrar pares de propiedades / valores jerárquicos. YAML agrega variables y comentarios a la capacidad jerárquica de JSON en un formato más legible. YAML ayuda a mostrar tokens rápidamente a cualquier audiencia y su simplicidad abre un límite para que los diseñadores sugieran nuevos valores e incluso envíen solicitudes de extracción ellos mismos.

Nuestro equipo usa yamljs para transformar los datos de YAML que administramos como una fuente única de verdad en un objeto JavaScript como un paso de nuestro proceso de compilación.

Para llevar: considere YAML para capacitar a los diseñadores para que se involucren y trabajen en el código, acercándolos al código y a aquellos que usan código.

# 9. Automatizar la documentación con datos de token

Incrustar decisiones de diseño en el código no es valioso si los diseñadores y desarrolladores no saben cuáles son las decisiones y cómo acceder a ellas. Es por eso que usamos tokens como contenido tanto como lo hacemos con el código.

En nuestros sistemas, conectamos tokens como una estructura de datos (piense: JSON) en plantillas para mostrar decisiones en una referencia de tokens y otros temas como el espacio y los botones temáticos.

Plantillas básicas para el sitio de documentación, con datos de token

Otra documentación está más personalizada, como una pila de tinte de color que incluye nombres, puntajes de accesibilidad y más. Si bien no es un simple ciclo a través de la jerarquía de tokens, la documentación aún puede usar tokens directamente.

Para llevar: Use tokens para enriquecer cómo puede ser su guía de vida.

# 10. Incrustar datos de token en herramientas de diseño, también

Los datos de token pueden inspirar ideas para herramientas no solo para desarrolladores, sino también para diseñadores. Hablamos de crear herramientas personalizadas para la comunidad de diseñadores de nuestra cartera en herramientas como Sketch, Photoshop o (en el pasado) InDesign.

Dicho software ofrece enganches robustos para utilizar los datos JSON a su favor. Por ejemplo, InVision's Craft se basa en objetos JSON almacenados como texto en subcarpetas, lo que sugiere una posible integración con los resultados del proceso de compilación de nuestro sistema. Dichas conexiones fueron lo suficientemente difíciles y en el pasado como para ser ignoradas. Hoy, se sienten más realistas a medida que un sistema madura.

Para llevar: Identifique oportunidades para extender el sistema a herramientas de diseño, especialmente software de diseño. Considere los costos, tanto de configuración como de mantenimiento, en relación con los beneficios para la experiencia del usuario de su sistema.

Cuanto más usan mis fichas los equipos, más me siento en casa discutiendo sobre diseño. Enhebrar decisiones inteligentes codificadas con nombres significativos me ayuda a confiar en que la salida de mi equipo se está arqueando hacia la aspiración de un sistema más coherente y sostenible.

¿Está a punto de embarcarse en un sistema de diseño o necesita profundizar para hablar sobre productos y jugadores? EightShapes realiza talleres de planificación de sistemas y entrena a clientes en sistemas de diseño. ¡Hablemos!