Design Tokens 101. Los desarrolladores web lo codificaron todo – Usabilidad web y seo

Design Tokens 101. Los desarrolladores web lo codificaron todo

Vistas: 104
0 0
Tiempo de lectura:6 Minutos, 12 Segundos


Mayo Capozzi

Los desarrolladores web generalmente han codificado todos sus datos de estilo. Si el botón necesita un color de fondo azul, asignan un color de fondo directamente en la fuente:

Esto funcionó para sistemas pequeños que no necesitaban una capa temática y no sufrían cambios frecuentes. Pero si necesitaba un rediseño masivo, era un enfoque doloroso.

Inventado por Gina Ann para Salesforce LighoraEn el sistema de diseño, los marcadores de diseño son un método para almacenar atributos de estilo como el color, la tipografía y el espaciado en una estructura predefinida. Son una alternativa a los datos de estilo codificados directamente, lo que permite a los diseñadores y desarrolladores crear diseños consistentes y agradables, realizar rediseños rápidamente y agregar una capa temática a sus aplicaciones.

Si un diseñador usa Figma, sus tokens de diseño se pueden representar de la siguiente manera:

Tienen nombres comunes específicos. Si cambió el valor asignado a `primario1`, ¡aún tiene sentido!

En código, estos tokens podrían verse así:

Estos tokens pueden ser leídos por cualquier motor de estilo que usemos. Por ejemplo, pueden ser utilizados por “componentes con estilo”.

He visto tres niveles diferentes de uso de tokens de diseño en sitios.

1. Sin tokens de diseño

Los sitios sin marcadores de diseño tienen datos de estilo codificados. No hay un lugar central donde se almacenan y administran los datos de estilo.

2. Fichas de diseño no estructurado

En mi experiencia, este es el nivel más común de uso de tokens de diseño. Hay un lugar central donde se almacenan y administran los datos de estilo, pero los datos no están organizados ni nombrados de manera consistente.

3. Fichas de diseño estructurado.

En el mejor de los casos, los sitios tienen tokens de diseño estructurados. Aquí es cuando los diseñadores y desarrolladores están negociando activamente la forma y las convenciones de nomenclatura de sus tokens. Esto permite que los diseñadores y desarrolladores se comuniquen de manera más eficiente y también facilita el rediseño de sitios web y la creación de temas.

El uso de marcadores de diseño puede mejorar varios flujos de trabajo generales. En muchos casos, tener tokens de diseño mejora el diseño y la experiencia del desarrollador y también proporciona valor comercial. Echemos un vistazo a un par de estos escenarios comunes y en qué se diferencian para los sitios que no utilizan tokens de diseño, tokens de diseño no estructurados y tokens de diseño estructurado.

1. Rediseño del sitio web

Sin tokens de diseño

La paleta de colores del sitio es predominantemente azul. Si un diseñador está trabajando en una herramienta que no admite una biblioteca de colores compartida (como Sketch), si lo desea, debe actualizar cada instancia de azul en todos sus archivos.

En el lado del código, probablemente no sea mucho mejor. El desarrollador tendrá que revisar todos los archivos de diseño que indiquen dónde se cambió este color a naranja y reemplazar el azul codificado por naranja en todo el sitio.

Fichas de diseño no estructurado

Luego, hay un escenario en el que se utilizan tokens de diseño, pero los tokens se nombran de acuerdo con el valor asignado originalmente.

En este caso, el desarrollador puede cambiar a naranja.

Pero ahora en la base de código usamos el token en el sentido de naranja, lo cual es realmente confuso. Entonces, el desarrollador realmente necesita cambiar el nombre del token de diseño, lo cual es contrario al propósito.

Fichas de diseño estructurado

El diseñador utiliza una herramienta que admite bibliotecas de colores compartidas como Figma. Si quieren que “primario1” sea naranja en lugar de azul, todo lo que tienen que hacer es cambiar el código hexadecimal de “primario” y todos sus diseños se actualizarán automáticamente con el nuevo color.

En el código, los tokens de diseño se ven así:

En este caso, el desarrollador solo necesita cambiar a naranja, y todo el código base se actualizará automáticamente en los lugares correctos con naranja en lugar de azul.

Entre otros beneficios, los tokens de diseño introducen un vocabulario común que los diseñadores y desarrolladores pueden usar cuando se refieren a estilos, lo que mejora la colaboración y reduce el intercambio, lo que ahorra tiempo y dinero.

  • Sin tokens de diseño
    Los diseñadores tienen diseños estáticos que deben actualizarse manualmente en todas partes. Es posible que ni siquiera sepan qué colores hay en el código base. En lo que respecta al código, es difícil comprobar qué colores forman parte del sitio y si coinciden con el diseño. Todo el mundo recurre a adivinar, lo que provoca una inconsistencia en la interfaz de usuario.
  • Fichas de diseño no estructurado
    Los diseñadores y desarrolladores se refieren a los tokens de diseño de forma diferente. Los diseñadores lo llaman blue blue1 y los desarrolladores lo llaman babyBlue. Es difícil comunicar lo que se necesita cambiar. Al final, lo consiguen.
  • Fichas de diseño estructurado
    Los diseñadores y desarrolladores llaman al azul … Ahora que los diseñadores quieren actualizar el color en sus diseños en todo el sitio, todo lo que tienen que hacer es decirle al desarrollador que actualice primary1 de azul a naranja.

Sin tokens de diseño

Hasta donde yo sé, esto no es posible.

  • Fichas de diseño no estructurado
    Si sus tokens tienen nombres como , será extraño cuando se vuelve rojo cuando se renombra.
  • Fichas de diseño estructurado
    Será realmente fácil si todos los temas siguen las reglas del token de diseño.
  • Sin tokens de diseño
    Tener valores codificados en un sitio hace que sea casi imposible mantener la coherencia. No hay forma de limitar el número de estilos y no existe un lenguaje común entre diseñadores y desarrolladores.
  • Fichas de diseño no estructurado
    ¡Mucho mejor que ninguna ficha de diseño! Como mínimo, los desarrolladores saben muy bien cuántos estilos diferentes aplican y es bastante fácil de auditar.
  • Fichas de diseño estructurado
    Esto es ideal ya que la estructura del token de diseño se puede compartir entre desarrolladores y diseñadores y el rediseño del sitio será simple y consistente.

A medida que la empresa crece, comienzan a admitir varias aplicaciones a la vez. La compañía podría comenzar a abordar algunos de los puntos débiles que surgen cuando esto comienza a suceder al acordar una especificación de token de diseño común.

Acordar una especificación común abrirá una serie de beneficios para la empresa:

  • Un conjunto de sitios con una interfaz personalizada lista para usar
  • Una biblioteca de componentes que contiene elementos que son conscientes de la especificación general; esto significa que puede insertar un botón en su marca y automáticamente se le asignará un estilo de acuerdo con sus tokens de diseño.
  • Mejor colaboración entre diseñadores y desarrolladores utilizando un lenguaje común de tokens de diseño.
  • Scripts que pueden extraer datos de Figma automáticamente a su base de código y cambiar el aspecto de su interfaz

Brent Jackson está trabajando en una especificación de estilo genérico de código abierto llamada Theme UI, que tiene como objetivo abordar este problema en todas las empresas.

Esta publicación se publicó originalmente el https://maecapozzi.com/design-tokens

Happy
Happy
0
Sad
Sad
0
Excited
Excited
0
Sleepy
Sleepy
0
Angry
Angry
0
Surprise
Surprise
0
Previous post Modelado conceptual de soluciones digitales, en profundidad
Next post Diseño receptivo versus diseño receptivo

Average Rating

5 Star
0%
4 Star
0%
3 Star
0%
2 Star
0%
1 Star
0%

Deja una respuesta