¿Pueden los diseñadores e ingenieros utilizar una única fuente de verdad? Parte 2.

Ahora que comprende el tira y afloja constante entre diseñadores y desarrolladores (lea la primera parte de este artículo aquí), hablemos sobre cómo solucionarlo.

Sistemas de diseño y una única fuente de verdad (Parte 2 de 2)

Los últimos 10 años trajeron mucha madurez al mundo de las tecnologías web. CSS se volvió extremadamente poderoso y creció en herramientas que permitieron flujos de trabajo predecibles y sostenibles (desde preprocesadores hasta módulos y linters de estilo). JavaScript se convirtió en el estándar de desarrollo para una variedad de plataformas. Agregó características que aumentan la legibilidad (mapas, funciones de flecha ...) y la modularidad del código (módulos ES6). Incluso obtuvo herramientas increíbles que llevaron el ecosistema al siguiente nivel (NPM, Webpack, React.js).

Ambos, el progreso en CSS y JavaScript, llevaron a una creciente popularidad de una arquitectura modular de aplicaciones web. Como consecuencia, también condujo a una popularidad drástica de los sistemas de diseño. La necesidad de sistemas de diseño se originó en el caos, el mantenimiento costoso y las experiencias inconsistentes de la primera web. El rápido crecimiento de la popularidad de los sistemas de diseño se hizo posible gracias al progreso de las tecnologías web.

Los sistemas de diseño ofrecieron muchas promesas:

  • La unificación de las fuentes de la verdad.
  • Previsibilidad del flujo de trabajo de desarrollo de productos.
  • Aumento de la calidad de la experiencia del usuario.
  • Disminución del costo de mantenimiento.

Como una revolución en el flujo de trabajo iniciada por el Sistema de producción de Toyota, los sistemas de diseño ofrecieron alivio de los dolores del desarrollo moderno de productos gracias a una sistematización de procesos.

Todavía es demasiado pronto para juzgar el efecto general del auge del sistema de diseño. Sin embargo, cada vez es más obvio que la generación actual de sistemas de diseño es excelente para sistematizar la ingeniería frontend y solo tiene poco éxito para solucionar la desconexión entre diseño e ingeniería.

Tomemos, por ejemplo, tokens de diseño, que son una parte fundamental de muchos grandes sistemas de diseño. Se pueden usar para generar conjuntos complejos de hojas de estilo y paletas de colores para herramientas de diseño, pero los componentes interactivos esenciales para cualquier sistema de diseño permanecerán desconectados de las herramientas de diseño.

Pocos intentos de cerrar esta brecha no ganaron popularidad masiva o tracción significativa. El mejor de ellos, HTML Sketchapp, ofrece una importación de elementos HTML a Sketch. Desafortunadamente, todos los estados e interacciones se pierden en el camino. Sketch, en última instancia, una herramienta de ilustración vectorial, no ofrece estados o interacciones a nivel de componente.

No culpe a los sistemas de diseño por esa deficiencia. Culpar a las herramientas de diseño. Mientras las herramientas de diseño impongan el formato vectorial a los diseñadores de interfaces de usuario, la implementación de una única fuente de verdad seguirá siendo imposible.

El tema de una sola fuente de verdad suena teórico, pero piense en las implicaciones prácticas.

¿Qué pasaría si los diseñadores pudieran usar los mismos componentes utilizados por los ingenieros y todos estén almacenados en un sistema de diseño compartido (con documentación y pruebas precisas)? Muchos de los frustrantes y costosos malentendidos entre diseñadores e ingenieros dejarían de suceder.

Revise la historia de dos recolectores de fechas en conflicto de la primera parte de este artículo. Si la diseñadora tuviera acceso a un componente interactivo sincronizado con la base de datos de producción, podría tomar una decisión de diseño informada sobre la experiencia de seleccionar datos y reutilizar un componente existente. Todo el conflicto se disolvería, resultando en un proceso de diseño más rápido, un proceso de desarrollo más rápido y una experiencia menos frustrante para todo el equipo.

Confiar en el rediseño manual de componentes codificados en producción en una herramienta de ilustración vectorial no solo es costoso sino también propenso a errores críticos.

En la implementación perfecta de un sistema de diseño, los diseñadores e ingenieros utilizan una única fuente de verdad para cubrir todas las facetas del flujo de trabajo. Una vez que los diseñadores abandonen sus viejas herramientas de ilustración vectorial (inevitablemente pierden todos los problemas relacionados con este viejo paradigma), este nivel de integración y madurez del proceso será posible.

Diseño unificado: colaboración de ingeniería con UXPin Merge

En UXPin, hemos pasado los últimos 8 años construyendo un editor de diseño colaborativo basado en código. Con una representación precisa, componentes con estado, interacciones avanzadas a nivel de componente (interacciones condicionales, variables, integración de API ...), hemos logrado evitar muchas de las deficiencias de las herramientas de ilustración vectorial como Sketch, Figma o XD. En lugar de confiar en cientos de mesas de trabajo estáticas, UXPin permite a los diseñadores crear componentes con estado totalmente interactivos y reutilizables. Diseñar formularios con validación completa se vuelve fácil incluso para los diseñadores que no codifican.

Cada vez que un diseñador crea algo en UXPin, nuestro motor de renderizado crea HTML CSS y JavaScript (para todas las interacciones avanzadas). Por lo tanto, los diseñadores e ingenieros pueden estar seguros de que habrá una coincidencia del 100% entre los diseños creados en UXPin y la implementación de producción final. Los malentendidos con respecto a las animaciones o la representación de fuentes mencionadas en el primer artículo no existen en el universo de UXPin.

No resolvimos todos los problemas a la vez. Incluso nuestro editor basado en código, que parece ser el más fuerte en el amplio mercado de herramientas de diseño, cayó en el problema de la unificación de las fuentes de la verdad. Nuestra herramienta ayudó a los diseñadores a evitar muchos malentendidos, pero no teníamos una manera de construir una conexión duradera con los componentes codificados existentes en un sistema de diseño. No lo teníamos ... hasta ahora.

Hace casi 2 años, comenzamos a trabajar en la construcción de una conexión duradera entre diseño e ingeniería. Después de explorar varias ideas, hemos decidido seguir el siguiente flujo de trabajo:

  • UXPin se conecta a un repositorio Git (la herramienta de línea de comandos se está instalando como una dependencia a nivel de proyecto)
  • UXPin aprende sobre el código de componentes almacenados en el repositorio y serializa su contenido
  • UXPin ejecuta el proceso de compilación y entrega el código de producción al editor de diseño de UXPin, donde todos los componentes son idénticos al entorno de producción, totalmente interactivos y disponibles para los diseñadores (incluso si no saben cómo codificar)
  • UXPin permite conectarse a un servidor de integración continua para permitir la sincronización automática entre un repositorio de Git y nuestro editor de diseño (cada cambio en el código de producción se refleja automáticamente en los componentes del editor de diseño de UXPin)
  • UXPin muestra especificaciones precisas para todos los proyectos de diseño que mostrarán fragmentos de código informativos para indicar a los desarrolladores cómo implementar un diseño dado

Este enfoque fue extremadamente ambicioso y mucho más amplio en su alcance que cualquier solución competitiva. Desde el principio queríamos evitar:

  • Crear una función de truco capaz de llamar la atención en el mercado, pero no puede solucionar los problemas clave del flujo de trabajo de diseño e ingeniería
  • Obligar a los diseñadores a aprender a codificar (que caracteriza el enfoque adoptado por Framer)
  • Obligar a los equipos a implementar nuestra solución de flujo de trabajo para crear código solo para UXPin (en cambio, creíamos en un enfoque plug and play, donde UXPin puede consumir código de producción no modificado).

Nos llevó más de 18 meses, pero me complace decir que UXPin Merge acaba de ofrecer una solución que realmente unifica el diseño y la ingeniería en un flujo de trabajo continuo.

Merge se conecta sin problemas a cualquier repositorio GIT, importa componentes React.js (soporte de más bibliotecas y frameworks en el futuro!) Al editor de diseño de UXPin y mantiene todas las versiones sincronizadas gracias a la integración de CI. Lo que exista en el código, existe en UXPin, lo que brinda a los diseñadores acceso a componentes codificados reales sin obligarlos a aprender codificación.

Con la integración de CI, UXPin Merge se encarga de la sincronización de la herramienta Código - Diseño.

Con UXPin Merge, los diseñadores e ingenieros usan una única fuente de verdad y finalmente pueden trabajar juntos sin malentendidos y frustraciones innecesarios. ¿Adivina qué? La implementación perfecta de un sistema de diseño es posible.

Componentes complejos como los selectores de fechas están disponibles de inmediato para los diseñadores.

UXPin Merge se encuentra actualmente en una versión beta cerrada. Regístrese para obtener acceso temprano a continuación. Nuestros clientes y los creyentes más apasionados en un flujo de trabajo unificado (si es usted, ¡háganos saber sus pensamientos en Twitter!) Se les ofrecerá acceso primero. Nos vemos en el otro lado.

Obtenga acceso anticipado a UXPin Merge