Una receta para un buen sistema de diseño

Este artículo ha sido amablemente apoyado por nuestros queridos amigos de Backlight, una plataforma colaborativa que permite a los equipos de front-end construir y enviar excelentes sistemas de diseño. ¡Gracias!

En teoría, todos tienen un concepto relativamente similar de lo que significa un "Sistema de diseño", aunque los matices comienzan a aparecer a medida que nos acercamos al mundo real. El objetivo puede seguir siendo el mismo, pero diferentes organizaciones requerirán diversas estrategias para lograrlo. Al igual que con muchas tareas complicadas en ingeniería y arquitectura, no existe una panacea para lo que constituye un buen sistema de diseño.

Aunque los esfuerzos exitosos comparten algunos patrones comunes que han permitido que surjan herramientas y mejores prácticas. En este artículo, veremos qué soluciones encajan dentro del paraguas de un Sistema de Diseño, y algunos pasos importantes y puntos de control que debe vigilar a lo largo de sus proyectos. Nuestra experiencia puede diferir, pero con suerte, habrá aprendizajes para usted donde personalmente fracasé y tuve éxito.

Objetivo y significado

Si consideramos un "sistema" como una combinación de partes que trabajan juntas, y "diseño" como el plan de apariencia y función de algo. Entonces podemos entender el Sistema de Diseño como un conjunto de definiciones que dictarán patrones en los que las partes interconectadas de un sistema se verán, sentirán y funcionarán. Esto sigue siendo bastante abstracto, pero lo suficiente como para entenderlo como algo más que apariencias .

No es una biblioteca de componentes que ensambla como un rompecabezas y llega a un diseño consistente. De hecho, un sistema de diseño tiene un aspecto de presentación, pero también tiene que ver con la función y la integración. Se trata de experiencia .

• Experiencia de usuario
  Con una interfaz de usuario confiable y funcionalmente consistente.
• Experiencia del desarrollador
  Con componentes fáciles de integrar y patrones definidos.
• Experiencia de las partes interesadas
  Con una visión general de cómo evoluciona y crece el producto.

Con tantas piezas en movimiento, es comprensible que no haya una respuesta única para todos los sistemas de diseño.

Intencional vs Orgánico

Cuando un equipo decide crear un sistema de diseño, hay dos enfoques en los que deben decidir por adelantado:

• Orgánico
  Tome una aplicación existente como referencia, extraiga partes de ella y abstráigalas lo suficiente como para que otra aplicación las use. Este enfoque conlleva menos decisiones desde el principio, pero requiere un esfuerzo más reactivo por parte del equipo para adaptarse a los nuevos requisitos encontrados por los adoptantes. Las decisiones arquitectónicas tienden a tomarse a medida que surge la necesidad en lugar de hacerlo de manera proactiva.
• Intencional
  Los tokens, los patrones y los componentes se piensan con anticipación. Se definen los límites de un producto mínimo viable (MVP) y comienza el trabajo. Para este enfoque, tener objetivos y requisitos es un paso importante para alinear las expectativas con las partes interesadas.

Orgánico

Al permitir que el Sistema de Diseño se desarrolle orgánicamente, el éxito del esfuerzo se reduce a la aceptación de las partes interesadas y los adoptantes. Y con qué eficacia podrá reaccionar el equipo a medida que despejen todas las incógnitas que encuentren en el camino sin ser excesivamente disruptivos con un apoyo continuo. Es un camino complicado y la comunicación es clave. No hay un camino de acción claro, ya que está estrechamente relacionado con el contexto del equipo.

Además, es difícil ajustarlo como un sistema mientras está funcionando (pregunte a su electricista local) y como las tareas toman tiempo, los requisitos pueden cambiar: el mercado no esperará su biblioteca de componentes. Un momento habitual de "hacerlo o romperlo" para un sistema de diseño orgánico es descubrir la historia de desarrollo de un MVP (producto mínimo viable) de componente.

Por un lado, tenemos desarrolladores y diseñadores que desean crear la mejor experiencia posible y la calidad de código por excelencia; por otro, están los KPIs, ROIs y su banda de siglas para medir el éxito. Encontrar el equilibrio y permanecer escalable es complicado. Cómo abstraer algo inacabado es aún más complicado, y evitar que esas tareas de seguimiento se olviden en el backlog es la cuestión del millón de dólares de la gestión de productos.

Ser capaz de iterar de forma rápida e incremental en su sistema de diseño se convierte en un requisito básico cuando se trata del enfoque orgánico. Y también requiere un nivel adicional de claridad por parte de sus desarrolladores de consumo (en caso de que haya equipos separados: uno que crea el Sistema de diseño y el otro que crea las características del producto). Ambos deben alinear claramente las expectativas sobre los requisitos del producto y los requisitos de experiencia del desarrollador para tener una simbiosis adecuada. Porque un Sistema de Diseño no es nada si es molesto de usar, o si empeora la experiencia del usuario de alguna manera.

Intencional

Se requiere mucha más planificación, incógnitas que aclarar e infraestructura que preparar cuando se toma la decisión consciente de construir el Sistema de Diseño antes de tener un producto para usarlo. La otra cara aporta más claridad con las restricciones. objetivos y expectativas. Si las velas se revisan dos veces antes de salir del puerto, la tormenta es menos aterradora.

La previsibilidad del sistema también crece cuando se planifica con anticipación, y esto se debe a que el Sistema de Diseño se convierte en su propio producto y no en la herramienta para mejorar a otros. Con esta abstracción, los patrones y soluciones utilizados en otros se transportan más fácilmente.

Aunque elegir Intencional sobre Orgánico puede parecer contraproducente al principio para los equipos con menos experiencia al no tener una prueba de concepto para probar, es especialmente útil para evitar errores comunes al comenzar. “De pie sobre los hombros de gigantes” es una jerga común y es veraz en este caso. Entonces, la mejor receta en el futuro debería ser más o menos:

1. Identificar los requisitos básicos;
2. Investigue temprano y a fondo para casos similares;
3. Lea los resultados de 2 para soluciones y estrategias implícitas;
4. Hágalo todo suyo ensamblando una combinación de soluciones comunes y agregando su propia salsa;
5. Iterar.

Esos cinco pasos pueden parecer simples y obvios, pero no lo son. Es fácil saltarse una de las reuniones de requisitos o acortar la investigación. Sin embargo, un consejo: pagará intereses en el paso 4 si olvidó alguno de esos.

Construir para la eficiencia

Ningún consumidor de paquete disfruta cuando una actualización de dependencia rompe su aplicación de alguna manera. No es diferente cuando el paquete en cuestión es parte de un Sistema de Diseño. En realidad, se podría señalar que es peor. La reacción violenta de una dependencia interna que rompe una aplicación tiende a ser mayor que cuando se trata de un paquete de código abierto, además, los cambios en la interfaz de usuario tienden a "romperse silenciosamente" primero frente a los usuarios finales: lo cual es particularmente frustrante.

Con eso en mente, ya podemos alinear algunos problemas:

• Documentación API
  Que sea fácil de descubrir y usar.
• Versionado
  Indica cómo se espera que los lanzamientos impacten a los consumidores.
• registro de cambios
  Indica qué cambios trae cada versión.
• Liberando
  Una forma sensata de mantener un código estable fácil de entregar para todos los consumidores.
• Entorno de desarrollo
  Todavía no hay una aplicación que lo use, debe descubrir cómo exhibir y desarrollar artefactos.

Es importante señalar que la prioridad de cada uno de estos elementos puede variar según su millaje. Pero la necesidad de ellos aumentará a medida que Design System escale, aumente la adopción y crezcan las funciones. Es posible que no sean suficientes para evitar que un equipo avance, pero seguramente obstaculizarán la productividad si la capacidad está sesgada para encontrar esas soluciones.

Fuente de la verdad

Otro problema eventual al que se enfrentan muchos equipos es identificar la fuente de la verdad en un sistema de diseño. ¿Es código, interfaz de usuario o documentación? Para muchos tipos de productos, solo miramos al lado del consumidor y podemos identificar fácilmente cuál es el resultado principal. La razón por la que se vuelve complicado en este caso es porque cada tipo de consumidor lo usará de manera diferente y, por lo tanto, la respuesta variará según la demografía solicitada.

Un sistema de diseño suele ser una combinación de una biblioteca de componentes, documentación y una guía de estilo. Y no solo el consumidor es diferente para cada uno de esos artefactos, también es diferente el artesano. Un desarrollador, un diseñador, un escritor técnico; Se necesitarán diferentes personas para crear cada salida.

Patata caliente

Para mantener la coherencia en la entrega, la comunicación y la colaboración son clave. Y el proceso similar a una cascada ya establecido no es alentador para ninguno de los dos.

No hay un espacio diseñado (juego de palabras) para la colaboración o la iteración en función de cada especialidad. A menudo, el diseñador desconoce algunas limitaciones del código y el desarrollador no tiene idea de la UX prevista para el resultado. Este enfoque no es extremadamente perjudicial, es posible crear un buen producto con él. Pero uno excelente es difícil, cada parte del proceso está casi desconectada a menos que el equipo haga un esfuerzo activo para corregirlo.

Los siempre sorprendentes Dan Mall y Brad Frost han acuñado el nombre igualmente genial para un nuevo proceso: Hot Potato. Este proceso no solo fomenta la comunicación, sino que también impone directamente la colaboración al equipo al unificar la fuente de verdad del trabajo. Con eso, cada artefacto entregado no solo comparte un origen común, sino que también es producto de la experiencia del equipo combinado.

Sin embargo, hacer que este tipo de colaboración sea fluida es más fácil decirlo que hacerlo. Incluso sentarse uno al lado del otro para esquivar el "estás silenciado", "se cortó mi conexión" y "¿puedes oírme?" molestias, cuando se coloca en el mismo lugar, el intercambio de información tiende a volverse informal con facilidad, y luego el proceso puede terminar siendo difícil de documentar o demasiado sincrónico. Queremos menos cuellos de botella, no más.

La colaboración en vivo ha llegado muy lejos entre pares. Al igual que VSCode Share o FigJams de Figma, los IDE en la nube, hay muchas opciones. Pero cuando se trata de iterar entre diferentes especialidades, no es muy sencillo. Agregue esto a la pila de herramientas, arquitectura o procesos mencionados en las secciones anteriores y tendrá un montón de trabajo por hacer incluso antes de comenzar a trabajar.

Arquitectura de un sistema

Como se señaló anteriormente, mantener un sistema de diseño es mucho trabajo. El mejor consejo es probablemente intentar no hacer las cosas desde cero siempre que sea posible. Use los recursos de la comunidad cuando sea conveniente. Si lo hace, recuperará menos tiempo para mantener puntos específicos del sistema y ayudará a los ingenieros y diseñadores a incorporarse si ya están familiarizados con ciertas partes del sistema.

Viene la luz de fondo. Es una plataforma como servicio que reúne una serie de herramientas de una manera obstinada pero flexible para acelerar toda la configuración de la arquitectura. Puede comenzar desde cero o elegir una plantilla de inicio que se adapte mejor a su proyecto. No se reinventan las ruedas si no es completamente necesario, usan recursos de la comunidad en todos sus elementos iniciales (el que probé, Yogi, está basado en ChakraUI), menos mantenimiento para ellos y el consumidor no se preocupa por estar encerrado. Además, el código se enviará a su plataforma de control de versiones, por lo que solo faltan unos pocos comandos de shell para salir si es necesario.

Una vez allí, organizará la integración con una plataforma de control de versiones (se admiten Gitlab y GitHub), un sandbox basado en Storybook, un IDE basado en VSCode, pruebas unitarias e incluso la publicación en el registro de NPM (esto último dependerá de su plan con ellos, puede ser a su cuenta o a la de ellos).

Múltiples Salidas

Mapeamos previamente que hay al menos 3 salidas diferentes que la mayoría de los sistemas de diseño requieren: documentación, código, interfaz de usuario. Una vez que la arquitectura está lista para generar cada uno de ellos, el equipo generalmente encuentra otro desafío: mantenerlos sincronizados. Los desarrolladores siempre están ansiosos por hacer cambios atómicos, tocas un lugar y se extienden a todos los lugares consumiendo esa información. Dentro de un Sistema de Diseño, no siempre está claro cómo lograrlo.

Si no está siguiendo el proceso Hot Potato, es fácil perder de vista qué actualizaciones de la interfaz de usuario ya abordaron los desarrolladores. E incluso si lo hace, entonces hay documentación. Backlight soluciona este problema colocando todo.

Y una vez realizados los cambios, sin salir del Dashboard de la plataforma. Es posible consultar la documentación en vivo actualizada.

Y todo esto solo está arañando la superficie de lo que pueden mejorar su arquitectura. También obtienes:

• Prueba de captura de pantalla en solicitudes de extracción con su función de "Revisión visual"
• Compatibilidad con el desarrollo basado en pruebas con pruebas unitarias integradas
• Sandbox con vista previa en vivo

Es un entorno de desarrollo completo para su sistema de diseño. Y aún obtienes todas esas integraciones incluso si decides no usar sus iniciales. La infraestructura está ahí para que construya la biblioteca de componentes que alimentará su sistema de diseño desde cero.

Colaboración remota en tiempo real

Como se mencionó anteriormente, el Proceso Hot Potato puede volverse problemático para que los equipos configuren una forma de trabajo remota y asíncrona. La retroiluminación aborda eso con una combinación de dos características:

• Integración del diseño;
• Comparte un enlace en vivo.

La integración de diseño trae el artefacto de diseño de su herramienta de diseño dentro de la misma plataforma. Para que el resto del equipo pueda mirar, agregar comentarios y hacer referencia al trabajo directamente desde el mismo tablero:

Con esta característica, el proceso de papa caliente comienza directamente en el tablero de dibujo, sin importar dónde se encuentre su equipo. Y sin cambiar de pestaña, también suaviza el proceso de codificación con la función de compartir enlaces, mejor explicada con su gif promocional que cualquier cosa que pueda hacer yo mismo. Los desarrolladores pueden compartir un enlace remoto en tiempo real de su trabajo sin publicar cosas en ningún lugar, sin procesos intermedios, eso es un gran impulso para los equipos que necesitan iterar rápidamente en el trabajo detallado.

comida para llevar

En caso de que aún no lo haya sido, con suerte, ahora está más claro lo que implica crear y mantener un sistema de diseño. Mucho más que un puñado de clases CSS, definiciones de tokens y tipos de letra; es herramientas, apoyo activo y promoción. La utilidad de un proyecto está dictada por la calidad de su producción y qué tan rápido puede adaptarse a los requisitos en constante cambio.

Entonces, al menos, prepárese para ser productivo y eficiente al crear su proyecto. Si todavía está encontrando su terreno, herramientas como Backlight lo ayudarán con valores predeterminados sensibles y una excelente experiencia de usuario lista para usar. Si ya está familiarizado con una arquitectura específica, elija sus batallas sabiamente y use la comunidad para manejar el resto.