Cerrando la brecha entre diseño y código

"Diseño y código" es una serie sobre experimentos, procesos y aprendizajes de diseño e ingeniería, presentada por el equipo de AirSwap.

En AirSwap, tenemos un enfoque asíncrono e iterativo para el desarrollo de productos. Sin embargo, uno de los primeros desafíos que encontramos fue mantener una identidad de producto consistente a través de iteraciones de trabajo de características, a través de múltiples propietarios de productos. Al trabajar en las primeras versiones de AirSwap Token Trader y AirSwap Widget, acumulamos rápidamente un puñado de archivos de Sketch: cada archivo contenía una bolsa de símbolos y estilos que representaban el estado de la identidad de nuestro producto en ese momento. Aunque esto funcionó al principio, nuestra falta de una fuente consolidada de verdad rápidamente se convirtió en un desastre de estilos obsoletos en múltiples fuentes.

Con múltiples archivos y símbolos dispersos en todos ellos, se convirtió en una molestia gestionar una identidad coherente.

Cada experiencia frontend en AirSwap está escrita en React. Al principio, teníamos un directorio de componentes compartidos, una biblioteca de componentes preliminar si lo deseaba, con los estilos adecuados que coincidían con la identidad del producto. Sin embargo, a medida que iteramos, nuestra identidad del producto cambió. Hacer referencia a las composiciones de diseño para las funciones más nuevas hizo que fuera más difícil identificar si un componente en particular ya existía o si era necesario implementarlo. Tomamos una decisión temprana de usar componentes con estilo, lo que nos permitió iterar rápidamente y crear características. La facilidad de uso que vino con los componentes con estilo fue una gran victoria, pero también involuntariamente nos permitió tomar algunas malas decisiones al extender los estilos. Sin reglas estrictas sobre cómo crear o extender componentes, nuestra base de código rápidamente se convirtió en el hogar de una gran cantidad de código duplicado con solo pequeñas diferencias. Esto no solo disminuyó la velocidad del desarrollador y aumentó la deuda tecnológica, sino que también introdujo inconsistencia en la identidad de nuestro producto.

Debido a la ausencia de un sistema bien definido en las composiciones de diseño, muchos archivos en nuestra base de código introducirían nuevos componentes que eran similares a los existentes, o harían cambios menores en los componentes existentes.

En nuestra búsqueda de una solución a estos problemas, recientemente comenzamos a experimentar cómo cerrar la brecha entre el diseño y el código.

Diseñar tecnología

La idea de la tecnología de diseño no es nada nuevo. Existen herramientas como Craft e Invision para ayudar a los diseñadores a consolidar sus estilos y transmitir esa información a los desarrolladores. Esto permite que múltiples partes interesadas trabajen en diferentes características mientras mantienen un conjunto consolidado de componentes básicos o una biblioteca de componentes compartidos. Sin embargo, lo que necesitábamos era una forma no solo de mantener la paridad entre los diseños, sino de mantener la paridad entre los componentes que constituyen un diseño y lo que existe en el código.

Hace aproximadamente un año, el equipo de tecnología de diseño de Airbnb lanzó un proyecto de código abierto llamado react-sketchapp, que permitió que los componentes React se procesaran en Sketch. La comunidad React respondió favorablemente y, muy pronto, los componentes con estilo lanzaron una extensión de su biblioteca, componentes con estilo / primitivas, con soporte para la representación de múltiples objetivos (incluida la representación en Sketch). Estos proyectos se convirtieron en soluciones técnicas fundamentales para los problemas de inconsistencia que estábamos enfrentando.

Biblioteca de componentes AirSwap

Después de una exhaustiva auditoría del widget AirSwap, identificamos y recreamos en Sketch el conjunto de componentes que se utilizarían en todas las características presentes y futuras. Luego nos tomamos el tiempo para recrear toda esta biblioteca de componentes en React, utilizando componentes / primitivos con estilo como nuestra base. Nuestros componentes se representaron como símbolos a través de react-sketchapp, creando una única fuente de verdad para nuestros diseños.

Reaccionar componentes renderizados a Sketch

La creación de la biblioteca de componentes se convirtió en la base de nuestro proceso de diseño preliminar de principio a fin en AirSwap. Los diseños de los componentes llegaron primero, seguidos de la implementación. Debido a que estábamos usando componentes con estilo y react-sketchapp, pudimos procesar el código implementado nuevamente en Sketch para su revisión. Una vez aprobados, los componentes renderizados se convertirían en los nuevos diseños, listos para una futura revisión si es necesario.

Varias versiones de la biblioteca de componentes, renderizadas en Sketch y cargadas en Figma

Entra Figma

Este ciclo elimina la disparidad entre el código y el diseño. Sin embargo, descubrimos rápidamente los beneficios adicionales de esta solución cuando comenzamos a hacer la mayoría de nuestro trabajo de diseño en Figma. Debido a que nuestras herramientas de diseño nos permiten crear documentos Sketch de nuestra biblioteca de componentes, cargamos cada nueva revisión en Figma. Los comentarios y las solicitudes de cambios se pueden realizar de forma interactiva en la última revisión, que proporciona especificaciones para la próxima revisión, solo para cargarse cuando se aborden todos los comentarios anteriores. Esto no es perfectamente perfecto (todavía), pero crea un proceso de revisión de la interfaz de usuario que es informativamente similar a las solicitudes de extracción de GitHub.

Uso de nuestra nueva biblioteca de componentes para crear simulacros para el nuevo AirSwap Conversational OTC Trading

Además, utilizando las funciones de biblioteca compartida de Figma, podemos proporcionar acceso a estos componentes en todas nuestras composiciones de diseño. Como ingenieros, podemos, en tiempo real, ver y editar en colaboración estas composiciones, lo que proporciona una indicación clara de qué componente se está utilizando. Esto elimina por completo cualquier suposición sobre si un componente ya existe o no, ya que el nombre del componente se muestra en Figma.

El nombre del componente se muestra en Figma, que proporciona información de inmediato a los desarrolladores que ven los simulacros

Que sigue

En el futuro, tenemos la intención de mejorar y ajustar este proceso para que se adapte mejor a nuestro trabajo de desarrollo de productos. Todavía hay varios pasos manuales e ineficientes requeridos.

Por un lado, Figma no proporciona actualmente una API con capacidad de escritura para documentos, lo que nos obliga a cargar manualmente los archivos de Sketch generados. Con el soporte API adecuado, podemos integrar fácilmente este proceso de extremo a extremo en nuestra línea de integración continua. Visualizamos un futuro en el que una canalización de CI procesa un archivo Sketch de una etiqueta o rama en un repositorio (o mejor aún, renderiza objetos Figma nativos en lugar de pasar por Sketch), carga ese archivo en Figma y vincula ese documento resultante a un pull solicitud. Los comentarios de Figma se pueden publicar de forma cruzada en GitHub, lo que proporciona una comunicación perfecta y comentarios entre el diseño y el código.

Además, a pesar de que hemos creado la base técnica para la biblioteca de componentes, todavía tenemos que establecer reglas prácticas sobre cómo y cuándo deberíamos extender los componentes y / o crear otros nuevos. ¿Qué propiedades de qué componentes se pueden ajustar caso por caso y cuándo una gran cantidad de cambios indican la necesidad de crear un nuevo componente? Necesitamos identificar respuestas naturales a estos problemas, idealmente ideando formas automatizadas de hacer cumplir esas decisiones.

Con esta nueva biblioteca de componentes, hemos notado un aumento en la productividad y la eficiencia con nuestras transferencias de diseño a código. Aunque lejos de ser perfecto, las capacidades completas de este nuevo proceso nos han permitido aumentar la velocidad a la que iteramos en el trabajo, manteniendo un alto nivel de integridad en la identidad del producto. La conversación sobre diseño y tecnología de diseño se está desarrollando rápidamente en muchos equipos de productos en todo el mundo. El diseño es algo que nos interesa profundamente en AirSwap, y la tecnología de diseño se ha convertido en una emocionante intersección del desarrollo de productos que podemos aprovechar para ayudarnos a enviar productos increíbles.

  • Suscríbase al blog de AirSwap
  • Únete a nuestro canal oficial en Telegram
  • Síganos en Twitter
  • Encuentranos en Facebook
  • Suscríbase a nuestro subreddit