Si está trabajando en varias composiciones al mismo tiempo, o si varios diseñadores están trabajando en el mismo diseño, es importante que el equipo (diseñadores y desarrolladores por igual) sepa que el Sistema de diseño es sólido (“Estoy mirando el objeto correcto”) y fresco (“esta es la última versión comprobada). Esta es una de las partes más difíciles de conseguir porque siempre hay que trabajar con diferentes presas y el sistema es un organismo vivo en constante evolución.
Para lograr confiabilidad y frescura, puede
- Retire los componentes no utilizados. Para hacer esto, personalmente uso un complemento llamado “Buscador de instancias” que me ayuda a encontrar todas las instancias de un componente en un archivo Figma. Cuando creo que un objeto ya no está en uso, antes de eliminarlo, me aseguro de que ninguna instancia haga referencia a él.
- mover o eliminar componentes obsoletos. Los componentes heredados son objetos que todavía están en uso en algún lugar de su archivo pero tienen una versión más nueva en su sistema de diseño.
- encontrar un letrero para indicar el estado del trabajo. Hay muchas maneras de ayudarlo con esto: puede colocar su trabajo en progreso en una página dedicada o en un marco de página, o agregar un sistema de etiquetado como el de Igor Lanko, o usar complementos personalizados como la anotación de estado de Thomas Lowry.
Hay muchos otros complementos disponibles para ayudar a mantener su diseño limpio y ordenado. Con 20 complementos de Figma cuidadosamente seleccionados por diseñadores experimentados, encontrará otros complementos para organizar su sistema de diseño.
Su sistema de diseño evoluciona, al igual que su código. Es inevitable que los dos terminen viviendo vidas separadas, pero quieres que estén lo más cerca posible. Algunos dicen que los desarrolladores deben ceñirse al diseño a toda costa. Yo digo que debemos adaptarnos unos a otros.
Es por eso que realizo sesiones de ingeniería inversa a intervalos regulares para adaptar los componentes y diseños a su implementación real. Junto con el desarrollador front-end, estudiamos cuidadosamente el diseño o el componente para identificar las diferencias entre el diseño y la implementación, y vemos cómo combinarlos. A veces tengo que adaptar un componente, a veces mi compañero desarrollador tiene que adaptar el código CSS o el tema.
Además de mantener el diseño y el código lo más uniformes posible, estas pequeñas “sesiones cooperativas” con el desarrollador principal me ayudan a comprender las limitaciones de los líderes y me ayudan a comprender las mías.
Por último, pero no menos importante, para facilitar una comprensión compartida tanto del diseño como del proceso, he establecido un ritual de UX semanal mediante el cual presento el trabajo de UX en progreso, analizo los clientes potenciales y los callejones sin salida, y le doy al equipo una idea de dónde trabajo. m en
Utilizo un tablero de gitlab disponible para todo el equipo para mostrar el progreso de mi trabajo. Dado que gitlab es la herramienta que usan nuestros desarrolladores como nuestro repositorio de código, hay muy poca fricción y no hay barreras para acceder a la herramienta: todos pueden ver el tablero y lo que está pasando. Además, utilicé las mismas convenciones que nuestro tablero de funciones (por ejemplo, gitmojis).
Actualizo cada número a medida que trabajo de acuerdo con este ciclo de vida.
- el número se abre con un título simple (basado en comentarios o puntos débiles) y una descripción de la solicitud de diseño
- número complementado con prototipos en papel que luego se discuten en la reunión semanal de UX
- problema actualizado con el prototipo de Figma cuando esté listo y este prototipo se exhibirá en la reunión semanal de UX
- lanzamiento listo para lanzamiento y se crea un problema correspondiente en el repositorio funcional
- lanzamiento desarrollado y aprobado pruebas de aceptación: yay podemos cerrarlo!