Cambio de ruptura visual en sistemas de diseño

Respetamos las API de código. Pero, ¿qué pasa con el color, el tipo y el espacio?

N.º 4 de 6 de la serie Sistemas de diseño de lanzamiento:
Salidas | Cadencia | Versiones | Ruptura | Dependencias | Proceso

Los sistemas de diseño establecen un estilo visual de referencia que es una dependencia esencial. Estas opciones (color, tipografía, espacio y más) se especifican de manera sólida y se espera que cambien de forma estable y previsible. Cuando un adoptante actualiza, un sistema de diseño no debe romper sus cosas inesperadamente.

Entonces, pregúntate ...

¿Pueden los adoptantes actualizar a una versión menor confiando en que su IU no se romperá debido a los cambios visuales del sistema?

El control de versiones semántico (SemVer) ofrece criterios claros para comunicar el cambio entre las versiones utilizando designaciones mayores, menores y parches. Todos los sistemas de diseño que encuentro utilizan SemVer y supervisan los cambios en la interfaz de programación de aplicaciones o API de su paquete. Este es un territorio familiar para los desarrolladores que codifican accesorios JavaScript y marcado HTML. Rompa su API, y su próxima versión debe incrementar la versión a una próxima versión principal, como de 1.4.0 a 2.0.0.

Especificar una interfaz para el estilo visual compositivo nos elude. Se siente tan difícil definir reglas claras y simples para monitorear los cambios de estilo. Los creadores de sistemas luchan por articular qué o por qué "Cambiar este estilo rompe la interfaz de usuario de un adoptante" frente a "Cambiar ese estilo no". Pocos equipos del sistema documentan tales criterios. Pregunto "¿Qué tipos específicos de cambios visuales desencadenan una versión principal para usted?" Su respuesta: ¯ \ _ (ツ) _ / ¯.

En este artículo, propongo que al menos el color, la tipografía y el espacio garanticen criterios que constituyan un cambio radical. También hay otras propiedades a considerar. Un sistema de diseño puede definir, documentar y comunicar estos criterios para que los adoptantes puedan actualizar versión por versión con confianza.

Color de última hora

La mayoría de los equipos del sistema se sienten seguros al ajustar el color de fondo de un botón primario. Tal vez su motivación es mejorar el contraste contra una etiqueta de texto generalmente blanca. "Oscurezcamos un poco el verde azulado", dicen. "Mejoraremos el contraste de color accesible del botón de una calificación AA a AAA".

Ajuste del color de fondo de un botón primario

Ciertamente, los equipos de adopción no deberían anular el conjunto de colores de un botón primario estándar. Anular una elección del sistema corta la conexión con un sistema. En ese punto, un adoptante está solo. Por lo tanto, ajustar el tono del color de fondo del botón primario es seguro y no es un cambio importante.

Sin embargo, cambiar los colores en otros lugares puede poner en peligro a los adoptantes. Considere los siguientes escenarios.

Ejemplo: texto del sistema en fondos personalizados

Imagine un equipo del sistema que ajusta el azul interactivo para mejorar el contraste de color. Se podía acceder al azul interactivo de v1.4.0 sobre un fondo blanco, pero falló en el fondo de carbón.

Comprobación de contraste de color a través de contrast-grid.eightshapes.com

Entonces, para v1.5.0, el equipo ajustó el azul interactivo a un tono más claro y saturado que funcionó tanto en blanco como en carbón.

Ajuste del color del texto de una etiqueta de botón fantasma en fondos impredecibles

Sin embargo, un adoptante había usado el botón Fantasma que dependía de ese color sobre un fondo gris claro. Después del cambio del sistema, el contraste del color del texto de la etiqueta es inaccesible. Su sistema rompió su producto.

Ejemplo: fondos del sistema con texto superpuesto personalizado

Del mismo modo, imagine que un sistema oscurece el color de fondo del componente Tarjeta. El área de contenido de la Tarjeta incluye una zona de contenedor de contenido "segura" donde los usuarios insertan el contenido y el marcado que deseen.

Ajuste del color de fondo de una tarjeta que permite contenido personalizado contenido

En esa zona presumiblemente segura, un adoptante agregó un texto secundario que, aunque sutilmente gris moderado, pasó una prueba de contraste de color. Después del cambio del sistema, el contraste de color ya no es accesible. Su sistema rompió su producto.

Imagine que la versión menor de su sistema incluye esos ajustes. ¿Retrocompatible, dijiste? No hay riesgo en la actualización, confiaron? No! ¡Su sistema rompió su producto!

Por lo tanto, evalúe las propiedades de los colores modificados para determinar si un sistema cambió, como por ejemplo:

  • Color del texto que podría aparecer sobre el color de fondo, la imagen u otra textura del adoptante.
  • color de fondo en el que se superpone el color del texto del adoptante.
  • color de fondo, color de borde, color de texto, cuadro de sombra u otra propiedad compuesta al lado, arriba o debajo del borde o contenido de otro componente para disminuir el contraste entre los elementos.

La accesibilidad impulsó estos ejemplos. También existe un riesgo estético, ya que los cambios de sistema bien intencionados podrían alterar la armonía colorida lograda por un diseñador de producto. Las interacciones de color abundan en la interfaz de usuario que un diseñador de sistemas no controla ni tiene visibilidad.

Para llevar: Comience a romper la conversación de cambio con criterios de color. Es más fácil transmitir riesgos, es medible objetivamente y está vinculado a la accesibilidad que despierta pasiones. Armado con unos pocos criterios, puede pasar a otras preocupaciones.

Romper tipografía (por envoltura)

La tipografía es una faceta central de cualquier estilo visual. Los equipos quieren hacerlo bien. Y hay tantos diales para ajustar: familia de fuentes, peso de fuente, tamaño de fuente, transformación de texto, altura de línea, espaciado entre letras y más.

No todas las experiencias corren el riesgo de romperse si un sistema ajusta la tipografía. Para las experiencias con mucho contenido, el contenido de cada elemento puede ser impredecible, de longitud variable y diseñado para ajustarse y responder a los cambios en el ancho de la ventana gráfica.

Para interfaces más densas, la tipografía debe ser precisa. Los diseñadores trabajan durante horas ajustando la tipografía, organizando etiquetas para que quepan en áreas compactas. Si ajusta la tipografía del sistema, sus elementos pueden ajustarse o recortarse de manera inesperada.

Ejemplo: las pestañas de envoltura son horribles

Imagine que su sistema ajusta la pestaña labelfont-weight de normal a negrita.

Después de una actualización de versión menor, las pestañas que no responden se ajustan. No está bien.

Un adoptante actualiza. Sus pestañas que no responden existentes exceden el espacio asignado, por lo que se ajustan. ¡Horrible! Su sistema rompió su producto.

Ejemplo: Caos de espaciado entre letras

Las pautas de la marca evolucionan, produciendo una nueva jerarquía y estilo de encabezado. Por lo tanto, su sistema se adapta aumentando el espacio entre letras de cada encabezado.

Un adoptante actualiza su densa aplicación de radiología de una sola página que está traducida a 14 idiomas, compuesta por una miríada de paneles de control, cada uno lleno de elementos y encabezados. Se actualizan y la interfaz de usuario está inundada de encabezados recortados de forma impredecible. Convocan una reunión de crisis. Invitan a los ingenieros de datos de fondo, ¡por el amor de Dios! ¡Su sistema rompió su producto!

Ajustar la tipografía del sistema puede ser peligroso. Para ti, es una evolución tipográfica refrescante implementada sin esfuerzo en una biblioteca. Para ellos, el texto comienza a comportarse mal. Te culpan a ti. Tal vez te enciendan en el canal Slack de # system-design. Nadie necesita eso.

Para llevar: Antes de 1.0.0, trabaje diligentemente para experimentar, refinar y finalizar estilos de letra adecuados a la variedad del cliente. Una vez que pase 1.0.0, mantenga una base estable y considere el cambio con precaución. Considere reservar turnos peligrosos para el próximo lanzamiento importante. Hasta entonces, agregue gradualmente características contenidas, como un componente de texto de formato largo para diseñar solo una copia del artículo.

Rompiendo espacio y tamaño

Al menos puedes ver el color y la tipografía. ¿Espacio y tamaño? Esos son más difíciles de definir como concretamente reutilizables, y mucho menos monitorear cambios importantes.

En HTML, cuando cambia las propiedades del modelo de caja de un componente: relleno, margen, ancho, alto, visualización, tamaño de caja, posición, izquierda, derecha, arriba, abajo, corre el riesgo de afectar la composición del diseño que organiza ese componente con otros elementos de la página.

Ejemplo 1: eliminación del espacio vertical

El equipo de su sistema decide eliminar los controles de formulario aplicado de espaciado vertical en forma de margen inferior. Esto afecta a ,