Desarrollar un entorno de diseño.

¿Qué es un entorno de diseño y cómo puede hacer que un sistema de diseño sea más fácil de usar?

Desde que me mudé a San Francisco, he hecho mi parte justa de la búsqueda de empleo. He sido diseñador de comunicación, diseñador de productos y desarrollador front-end. Cada vez que cambiaba mi rol, siempre estaba ocupado aprendiendo nuevas habilidades, pero nunca sentí que estaba trabajando en problemas que en realidad sería bueno para resolver. Afortunadamente, todo resultó ser una gran capacitación para el trabajo que tengo ahora, que es desarrollar Thread, el sistema de diseño interno de Credit Karma.

Sketch Symbols for Thread, el sistema de diseño interno de Credit Karma.

Sin embargo, la mejor parte de saltar fue la oportunidad de estudiar cómo los diferentes tipos de organizaciones se acercan a hacer el trabajo. Me fascinaron especialmente los equipos de ingeniería, porque en ingeniería, la colaboración es esencialmente no opcional. Si tiene 400 ingenieros que escriben código, las contribuciones de cada persona tienen que interoperar y las organizaciones de ingeniería hacen todo lo posible para garantizar que haya la menor cantidad posible de inconvenientes al combinar el código.

De hecho, en la mayoría de las organizaciones de ingeniería, pasa todo el primer día configurando su entorno de desarrollo para poder enviar el código. En general, es bastante tedioso y a nadie le gusta hacerlo, pero es lo que haces para contribuir con un trabajo significativo a la producción. Lo que me hizo pensar, ¿cómo sería facilitar a los diseñadores el diseño para la producción?

A los fines de esta publicación, estoy definiendo un entorno de desarrollo como "El conjunto de procesos y herramientas de programación utilizados para crear el programa o producto de software".

Entorno de desarrollo: el conjunto de procesos y herramientas de programación utilizados para crear el programa o producto de software.

Por el contrario, un entorno de diseño sería "El conjunto de procesos y herramientas de diseño utilizados para diseñar el programa o producto de software".

Entorno de diseño: el conjunto de procesos y herramientas de diseño utilizados para diseñar el programa o producto de software.

Thread, nuestro sistema de diseño, es exitoso si la forma más fácil de diseñar o construir una interfaz de usuario es también la más alta calidad. Una gran parte de ese éxito es cerrar la brecha entre lo que un diseñador tiene acceso en Sketch y lo que un ingeniero tiene acceso en el código. ¿Podría formalizar la lista de herramientas de diseño y requisitos de proceso ayudar a reducir la brecha? Para averiguarlo, comencé con una lista.

Para diseñar adecuadamente para la producción, un diseñador de Credit Karma necesitaría:

  1. Símbolos de subprocesos que se comportan lo más cerca posible de sus contrapartes componentes Reaccionar (espaciado, tipografía, etc.)
  2. Acceso a una paleta de colores que coincida con nuestras variables CSS.
  3. Acceso a estilos de texto que coinciden con nuestras clases CSS
  4. Acceso a estilos de capa que coinciden con nuestras clases CSS
  5. Acceso a la biblioteca actualizada de croquis de hilos
  6. Una forma de probar si la fuente correcta de la compañía está instalada y acceder a la versión correcta si la anterior está presente

A partir de ahí, fue fácil comenzar a identificar posibles soluciones y reuní algunas opciones que pensé que ayudarían.

  1. Botón dinámico y diseño automático de Anima para alinear el espaciado y el relleno del símbolo con el espaciado y el relleno del componente React
  2. Paletas de croquis para importar colores
  3. Sketch Style Libraries para extraer estilos de texto de la biblioteca Thread Sketch
  4. Sketch Style Libraries para extraer estilos de borde y fondo de la biblioteca Thread Sketch
  5. Resumen para distribución de bibliotecas y control de versiones
  6. Un archivo de boceto para probar la versión de la fuente y acceder a la fuente correcta en Google Drive

Este último problema fue el más complicado. La fuente original que compramos tenía algunos problemas de altura de línea, lo que hacía que los botones y las insignias se vieran verticalmente descentrados. Trabajamos con el creador de fuentes para solucionar el problema, pero fue difícil para las personas saber fácilmente si la fuente se había actualizado o no. Elegí los elementos más obvios que se verían mal si la fuente fuera incorrecta y tomé capturas de pantalla de la diferencia, luego los puse en una página " Verificación de fuente" en el archivo de la biblioteca de Thread Sketch.

También noté algunas ventajas, como configurar el desplazamiento de Sketch + Shift + Arrow a 8px en lugar del valor predeterminado de 10px para que coincida con nuestra escala de clase de relleno de 8px e instalar SketchRunner para acelerar la administración de símbolos.

Cuando terminé la propuesta de recomendaciones, puse todos los recursos sueltos en una sola carpeta en Google Drive y preparé una presentación sobre cómo debería funcionar el proceso de configuración del entorno de diseño.

La carpeta de recursos de subprocesos

Nota: al igual que con los entornos de desarrollo, los problemas que un entorno de diseño pretende resolver y las soluciones que proporciona variarán ampliamente de una compañía a otra.

Probar el proceso

El siguiente paso fue reunir a un grupo de diseñadores para dar a la propuesta una prueba paso a paso, que hicimos el pasado febrero.

Comenzó con un grupo de 6 voluntarios, que creció a 10 para cuando la reunión terminó. Guié a todos a través de la presentación, los objetivos del entorno de diseño y la carpeta de recursos Thread en Google Drive, deteniéndome después de cada paso para asegurarme de que la configuración de todos funcionara.

Al final resultó que, 10 personas eran un grupo demasiado grande y la naturaleza esencial del ejercicio hizo que fuera fácil para los participantes distraerse y perder el enfoque. A pesar de los baches, tomé notas sobre todos los lugares donde la gente se metió en problemas y convertí la presentación en una guía en nuestro sitio de documentación.

En la guía, me aseguré de enmarcar el proceso como una inversión, diseñada para ahorrar tiempo al colaborar con la ingeniería. También agregué un "tiempo de finalización" estimado para establecer expectativas de que todo el proceso solo debería tomar unos 30 minutos de principio a fin.

Una vez que se publicó la guía, organicé un chat de video con Pedro, un diseñador en nuestra oficina de Los Ángeles, y tomé notas adicionales mientras revisaba la guía. Nuevamente, encontré muchas cosas para mejorar y aclarar, luego repetí algunas de las instrucciones.

Compensaciones

Aunque el proyecto ha tenido algún éxito temprano (uno de mis compañeros de trabajo me dijo que configurar un nuevo archivo de Sketch ahora es "una emoción barata"), todavía es un trabajo en progreso y, como siempre, hay compensaciones a considerar.

Reducción de la autonomía del flujo de trabajo.

Uno de los cambios más importantes para nuestro equipo fue adoptar una postura grupal sobre la administración de archivos mediante el uso de Resumen para realizar un seguimiento de los cambios en los archivos de Sketch. Decidir usar Resumen significaba pedirles a todos que cambiaran la forma en que organizaban su trabajo, lo que resultó algo convincente. Pero estábamos luchando por rastrear y compartir el trabajo de manera efectiva a medida que el equipo crecía, por lo que el contexto que proporciona el control de versiones fue realmente atractivo. Aunque nos costó un poco de autonomía en el flujo de trabajo, ha sido de gran ayuda para la colaboración, especialmente al entregar diseños a la ingeniería.

Dependencias adicionales y conflictos de software

Por supuesto, cuando se agregan dependencias nuevas a una cadena de herramientas, aumenta el riesgo de conflicto de software. Todavía no ha sido un problema importante, pero la actualización a las principales versiones de software clave como Sketch puede generar frustraciones. Además, es menos probable que el nuevo software sea estable que el software maduro, tanto en errores como en longevidad. Al elegir incorporar un proyecto de código abierto o una herramienta de inicio, tenga en cuenta que existe la posibilidad de que el proyecto no se mantenga o que el inicio se doble.

Sobrecarga mental

Lo último a tener en cuenta es la sobrecarga mental. Con cada nueva herramienta y complemento, hay atajos y comportamientos que los usuarios del entorno de diseño deben recordar. Si bien quiero reducir la brecha entre lo que ve un diseñador en Sketch y lo que ve en la producción tanto como sea posible, demasiados pasos y complementos anularían el propósito de crear un flujo de trabajo más racionalizado. Dado que siempre habrá discrepancias entre el renderizado de Sketch y el renderizado del navegador, de todos modos, Sketch debe tratarse como una aproximación cercana.

Herramientas de evaluación

En el diseño de productos digitales, la cantidad de herramientas para elegir nunca ha sido tan alta, entonces, ¿cómo se da cuenta si es una buena idea introducir una nueva herramienta? Si decide reemplazar una herramienta antigua por una nueva, ¿cómo convence a todos los demás en su equipo?

Las tres preguntas principales a considerar son:

  1. ¿Qué problemas estás tratando de resolver con esta nueva herramienta?
  2. ¿Qué nuevos problemas podría presentar esta herramienta?
  3. ¿Qué hace que valga la pena?

Ninguna herramienta es perfecta y todas tienen un costo. Si le está pidiendo a un grupo de personas que cambie significativamente su forma de trabajar, es bueno ser sincero acerca de los pros y los contras del cambio que está proponiendo demostrar que ha realizado su diligencia debida.

Sin embargo, lo bueno de las herramientas de diseño que convergen colectivamente es que todas las herramientas mejoran individualmente. Cuando Figma consiguió prototipos, Sketch hizo lo mismo. Cuando Abstract introdujo el control de versiones para Sketch, Figma lanzó el historial de versiones con comentarios. Incluso las herramientas de creación de prototipos como Framer e InVision han aumentado su inversión en el lado del diseño de las herramientas. Algunas compañías, como Airbnb y Facebook, están construyendo herramientas personalizadas sobre estas plataformas o construyendo herramientas completamente nuevas.

Lo bueno de las herramientas de diseño que convergen colectivamente es que todas las herramientas mejoran individualmente.

Lo mejor que puede hacer es considerar su proceso de manera integral y elegir herramientas que se adapten a la forma en que desea trabajar, y no al revés.

Mirando hacia el futuro

Este proyecto de entorno de diseño es solo el comienzo. ¿Qué otras mejores prácticas podemos adaptar de disciplinas relacionadas que han resuelto problemas con los que tradicionalmente luchan las organizaciones de diseño? ¿Puede alguna de esas prácticas hacer que los sistemas de diseño sean más fáciles de usar?

Otras compañías ya están comenzando a hacer esto. Airbnb ha creado un experimento de diseño con la API de Figma. Abstract está allanando el camino para solicitudes de extracción de diseño que podrían hacer que mantener la coherencia a nivel del sistema sea una responsabilidad compartida. Y hay mucho que aprender más allá de la ingeniería: el sistema de diseño Polaris de Shopify está estableciendo el estándar para el aprendizaje interfuncional al poner una estrategia de contenido a nivel de componente en su documentación.

Independientemente de las herramientas que todos usemos en los próximos cinco años, espero ver cómo nuestro enfoque para hacer el trabajo evoluciona con el tiempo.