Sistemas de diseño: Lecciones de Vivid

Nuestra especialista en CSS Rachel Tannenbaum dio una charla increíble cuando Vonage organizó Pull Requestuna reunión de la comunidad de código abierto. Ella dio una charla sobre sistemas de diseño, su enfoque durante los últimos 3 años. Pero todo el mundo debería aprender sobre sistemas de diseño, no sólo los que tienen la suerte de asistir a una reunión. Así que voy a compartir mis conclusiones de su charla en este artículo, respondiendo a las siguientes preguntas:

¿Qué queremos decir cuando hablamos de sistema de diseño? ¿Por qué necesitan las organizaciones un sistema de diseño? ¿Los sistemas de diseño son responsabilidad del equipo de diseño o del equipo de desarrollo? ¿Cómo se implantan los sistemas de diseño?

¿Qué son los sistemas de diseño?

Todo empezó con los libros

El libro de marca era la única fuente de verdad para mantener la integridad y uniformidad de la marca.

coca-cola-brand-book.png

Hace mucho tiempo, cuando los humanos podían sobrevivir sin Internet, las empresas tenían un libro de marca. Este libro contenía la filosofía de marca de la empresa: colores, tipos de letra, imágenes, etc. Definía diferentes estilos en diferentes entornos; por ejemplo, un anuncio en un periódico frente a un anuncio en una valla publicitaria. El libro de marca de Coca-Cola, por ejemplo, ¡incluso contenía directrices para la forma de sus botellas de vidrio! Este libro permitía mantener la marca y su visibilidad, independientemente de quién lanzara el producto final.

Los libros de marca se digitalizan: Guías de estilo

Pero hoy la gente no puede vivir sin Internet. Los sitios web de una sola página se han convertido en extensas aplicaciones web con subsitios. Ya no es posible que un solo diseñador mantenga la aplicación de una empresa. A medida que los equipos de diseño crecen para hacer frente a este reto, ha surgido un nuevo recurso para dar sentido al caos. Donde el mundo analógico tenía el libro de marca, el mundo digital tiene la guía de estilo.

vonage-style-guide-example.png

Una guía de estilo es la fuente de la verdad para los activos digitales de una marca. Estos activos incluyen elementos fundamentales como colores, iconos, tipografía y elementos como botones. También incluye elementos más complejos, como selectores de fechas, menús, etc. Por supuesto, las empresas de software que crean herramientas de diseño también están experimentando.

Pero, ¿qué tienen que ver las guías de estilo con los sistemas de diseño frontend? Piense en el proceso de desarrollo del frontend como si fuera construir con Legos. Las guías de estilo toman ideas abstractas como colores y formas y las transforman en un libro de instrucciones. Los sistemas de diseño toman esas instrucciones y las llevan al mundo real, combinando ladrillos en objetos. La ventaja de un sistema de diseño sobre una guía de estilo es que un sistema de diseño contiene secciones de código, llamadas componentes, que pueden reutilizarse rápidamente una y otra vez en toda una aplicación. El uso de componentes garantiza la uniformidad de la marca y ahorra un tiempo de desarrollo precioso. Además, los sistemas de diseño son fácilmente escalables y dinámicos. Así, con los sistemas de diseño, dejas de construir código como un artesano y, en su lugar, lo haces como una potente fábrica industrial de simpáticos legos.

¿Por qué utilizar un sistema de diseño?

Todo producto digital necesita un sistema de diseño UX.

Ok, tal vez no cada producto digital necesita un sistema de diseño. La pregunta que debe hacerse en su organización es: ¿somos un Ford o un Ferrari?

Los sistemas de diseño pueden requerir mucho tiempo adicional para su instalación y mantenimiento. La gran inversión inicial sólo merece la pena en proyectos a gran escala en los que se ahorre tiempo a largo plazo. El equipo debe tener en cuenta el número de desarrolladores que utilizarán el sistema de diseño, el alcance de los productos y los estándares y la comunicación del equipo de desarrollo.

¿Es su equipo un Ferrari? Si eres un Ferrari, tienes una línea de productos relativamente pequeña, con no demasiados componentes repetibles. Sus productos no se construyen pensando en una gran escala y, por tanto, las economías de escala en sus diseños no ahorrarían mucho a su organización.

¿O es usted un Ford? ¿Tiene muchos productos, muchos equipos y muchos diseños que incorporan una gran escala de páginas y funciones? Una buena prueba es preguntarse si tuviera que actualizar los diseños de todos sus botones, ¿sería una tarea gargantuesca o simplemente molesta? Si es una tarea gigantesca, probablemente seas un Ford.

Ventajas de los sistemas de diseño: Orden y eficacia

En pocas palabras, un buen diseño mejora la experiencia del usuario y mantiene la coherencia de la marca mediante el orden y la eficacia.

1. Pida

   • Ordenar en UI: Establece un diseño fijo, un patrón fijo de comportamientos, gestos, interacciones, etc.

   • Encargar en el desarrollo: Crea orden en el desorden, ayuda a limpiar el código y evita la duplicación de código.

2. Eficacia

   • Desarrollo eficiente: Reduce el tiempo de desarrollo, Permite a los diseñadores tomar mejores decisiones, ahorrando tiempo y dinero a su organización.

   • Actualizaciones eficacesActualizaciones de todo el sistema en un abrir y cerrar de ojos.

gmail-ui-uniformity-example.png

Gmail es un gran ejemplo de sistemas de diseño que crean orden y aumentan la eficacia. En cualquier dispositivo, el usuario tiene claro que se trata de un producto de Google. Sólo por los componentes de la interfaz de usuario, el usuario tiene claro qué tipo de interacciones puede esperar. Y en cuanto a la eficiencia, ¿recuerdas cuando Google pasó de Material Design 2 a Material Design 3? Imagínate cada lugar en el que había que cambiar las barras de navegación rojas y moradas, cada lugar en el que había que redondear las esquinas exactamente igual. En lugar de enormes dolores de cabeza en toda su suite de productos, un Sistema de Diseño aseguró que Gmail, Google Docs, Google Slides, y todos los demás se sintieran exactamente igual a través de componentes reutilizables.

Lecciones de Vivid

vivid-vonage-design-system-cover.png

Implantar un sistema de diseño en iteraciones

No construya primero un sistema de diseño UX. Piense en los sistemas de diseño UX de una manera LEAN. Quieres construir los componentes más útiles y escalables. Así que necesita saber qué componentes utiliza realmente su equipo de diseño. Esto significa que tu organización debería construir primero su producto o productos y luego evaluar qué componentes se reutilizan más. Los sistemas de diseño no sirven para la V0.1 de su producto, sólo a partir de la V1.0.

¿Cómo puede identificar los componentes que necesitará? Siempre puede empezar por los elementos más básicos: tipografía, colores, botones, etc. Estos elementos serán muy utilizados independientemente del producto. A partir de ahí, tu sistema de diseño evolucionará. Nathan Curtis tiene un excelente (https://medium.com/eightshapes-llc/the-component-cut-up-workshop-1378ae110517) sobre esto llamado, "The Component Cut-Up Workshop", donde se puede ver el flujo de trabajo de dividir un sitio web en los componentes que conforman el sistema de diseño.

vivid-abstract-artwork.png

En Vonage, nuestro sistema de diseño pasó por muchas iteraciones. El primer proyecto se llamó Volta y ayudó en gran medida a estandarizar CSS. Después, a medida que el proyecto fue ganando más apoyo por parte de la dirección, pasó a llamarse Vivid.

Vivid-2 se basaba en Material Design. Pronto nos dimos cuenta de que esto era problemático en varios sentidos:

• demasiado pesado para lo que necesitábamos

• poco comunicativo con la comunidad y con las peticiones de cambios o errores

• no se ajusta a la especificación

• no totalmente accesible

• no pretende ser la base sobre la que crear un sistema de diseño

Vivid 3: Replantearse todo

Al pasar de Vivid 2 a Vivid 3, decidimos replantearnos todo por completo. Así que utilizamos la tecnología Fast de Microsoft como base. Elegimos Fast porque está construida a propósito como base del sistema de diseño. Al mismo tiempo, es ligera pero también evoluciona continuamente para añadir nuevos componentes y funciones. Y lo más importante es que está construido de acuerdo con W3C y OpenUI.

Vivid-3 no sólo tiene todas las ventajas de Fast, sino que también las ha mejorado:

• cobertura de las pruebas - del 70% al 100%.

• documentación - con fragmentos de código listos para usar, que facilitan a los desarrolladores copiar y pegar lo que necesiten

• accesibilidad - de acuerdo con WCAG 2

• etiqueta blanca

Construir un puente

El equipo como puente

Su sistema de diseño debe actuar como un puente. Forme su equipo con las partes interesadas adecuadas, que compartirán sus conocimientos y moldearán el sistema de diseño para satisfacer las necesidades de cada función empresarial.

¿Quién es responsable de construir el sistema de diseño? En pocas palabras: el equipo de desarrollo. El equipo de desarrollo debe ser el principal responsable de la creación del sistema de diseño, pero no el único. Una de las ventajas más importantes de un sistema de diseño es que sirve de puente entre los diseñadores y los desarrolladores. El sistema de diseño actúa como guía, proporcionando un lenguaje común para aclarar la comunicación entre desarrolladores y diseñadores. Cuanta más responsabilidad se comparta entre estos equipos y más aportaciones de cada uno se inviertan en la creación de un sistema de diseño, mejor será el producto final y mejorarán las sinergias en toda la organización.

Puente con utillaje

Paralelamente a nuestra API, mantenemos una biblioteca de componentes en Figma para los diseñadores. Cuando están trabajando en el diseño de una página, app o lo que sea, pueden añadir rápidamente la biblioteca de activos de Vivid a sus componentes de diseño. Así mantienen un diseño uniforme. En el archivo final de Figma, los desarrolladores tienen todo lo que necesitan para codificar: exactamente qué componentes utilizar y sus especificaciones exactas de píxeles perfectos (tamaño, forma, fuente, etc.).

vivid-component-library-figma.png

Además, exportamos tokens de diseño para colores, tipografía y tamaños desde Figma para utilizarlos en la biblioteca de código. Lo bueno de los tokens de diseño es que al cambiar el Figma de uno de los tokens y exportarlo, automáticamente se hará el mismo cambio también en Vivid.

Identifique las principales preocupaciones de su organización

identify-main-concerns-investigate.png

Vonage es una empresa muy grande con muchos equipos de desarrolladores que trabajan en una amplia gama de productos. Esto se traduce en un gran número de bibliotecas de desarrollo front-end que se utilizan en toda la empresa: Vue.js, React Native, Angular, etc. La misión de Vivid es unificar el diseño en todos estos proyectos. Para Vivid identificamos 3 preocupaciones principales: escalabilidad, uniformidad entre frameworks y accesibilidad. Necesitamos que Vivid se actualice de manera uniforme en una gran variedad de productos. Necesitamos que el resultado final sea independiente del marco de frontend. Por último, tenemos que asegurarnos de que la solución cumple las normas de accesibilidad más recientes.

Para satisfacer esta necesidad, Vivid se basa en componentes web.

¿Qué son los componentes web?

Los Web Components son un conjunto de diferentes tecnologías que te permiten crear elementos personalizados reutilizables -con su funcionalidad encapsulada lejos del resto de tu código- y utilizarlos en tus aplicaciones web. Básicamente, el producto final de un componente web es HTML, CSS y Javascript, lo que significa que puede adaptarse a cualquier entorno de desarrollo. Para saber más, te recomiendo leer Introducción a los componentes web.

Los componentes web contienen 3 elementos principales:

1. Elemento personalizado

Este es el elemento "host". Se verá en el DOM y normalmente tendrá un nombre único. Por ejemplo, en Vivid Components, el nombre del elemento personalizado siempre empieza por vwc. Estas iniciales significan Vivid Web Components. La segunda parte del elemento es el nombre del elemento que actúa como una descripción de su propósito. Por ejemplo vwc-button, vwc-dialog, etc.

1. Shadow-dom

Una especie de "subdominio" oculto a la vista, se encuentra bajo el elemento anfitrión, el elemento personalizado. Permite que un componente tenga su propio árbol DOM "en la sombra", al que no se puede acceder accidentalmente desde el documento principal, puede tener reglas de estilo locales y mucho más.

1. Plantilla

Dentro del shadow-dom podemos ver la plantilla html que contiene los elementos o partes del componente.

Los componentes web de Vivid requieren que los usuarios definan los componentes en función de sus necesidades (texto, icono, etc.) y, a cambio, recibirán componentes totalmente funcionales y diseñados, sin apenas codificación y sin meterse con la estructura HTML del propio componente.

Por ejemplo, para añadir un Modal al proyecto todo lo que necesitas es esto:

Bajo el capó, dentro del dominio de la sombra, todo este código se añadirá realmente al proyecto:

<vwc-elevation dp="12">
  <dialog class="base icon-placement-side hide-body hide-footer" open="">
  <slot name="main">
    <div class="main-wrapper">
      <div class="header border">
        <slot name="graphic">
          <vwc-icon class="icon" name="info"></vwc-icon>
        </slot>
        <div class="headline">Dialog Headline</div>
        <div class="subtitle">subtitle content</div>
        <vwc-button size="condensed" class="dismiss-button" icon="close-line">   
        </vwc-button>
      </div>
    </div>
  </slot>
  </dialog>
</vwc-elevation>

Y para asegurar que el Diálogo se abre dentro de un Modal, la apertura debe ser activada con una funciónhowModal.

<script>
  function openDialog() {
    dialog = document.querySelector('vwc-dialog');
    dialog.showModal();
  }
</script>

El producto final tendrá este aspecto:

vivid-dialog-component.png

Cómete la comida del perro

De todas las herramientas que ayudan al desarrollo de sistemas de diseño, Storybook es probablemente la más popular. Pero a pesar de todas sus ventajas, no maneja bien los componentes web. No muestra correctamente el código de los componentes ni genera fragmentos de código para los desarrolladores.

Por esta razón, la documentación de Vivid está construida con... ¡Vivid! El uso de nuestros propios componentes permitió mejorar los propios componentes y su documentación.

El uso de los componentes fuera del entorno de desarrollo es esencial. Dicho esto, los desarrolladores de sistemas de diseño deben recordar siempre que no son los usuarios de la biblioteca. No asuma que la forma de utilizar los componentes será la única o la correcta, sea comunicativo con sus usuarios.

Conclusión

Ahora que sabes un poco más sobre cómo construimos Vivid, deberías probarlo. Echa un vistazo al libro de cuentos o Github repo. Nos encantaría ver lo que estás construyendo con Vivid o escuchar tus propias experiencias construyendo un sistema de diseño. Envíanos un mensaje en la comunidad de desarrolladores de Vonage Slack o en Twitter.