Una nueva manera de trabajar en Figma: de local a global

Published in

DesignOps Latam

9 min readMay 26, 2022

Traducido del original.

Durante el primer mes como DesignOps lead tuve que replantearme la forma en que todo el equipo estabamos trabajando en Figma y recomendar una nueva manera de hacer las cosas que funcionara en todos los digital hubs del mundo.

Ahora mismo tenemos diseñadores basados en Singapur, India, China, Argentina, Brasil, Kenia y Alemania. Hasta hace bien poco cada hub ha trabajado de una manera aislada e independiente. Esa forma de trabajar se adaptaba a necesidades individuales pero no globales. El gran desafío de cara al futuro era garantizar interoperabilidad de los proyectos mediante este cambio en la manera de trabajar.

Para ello, hemos seguido un proceso de diseño bastante estándar para llegar a una solución viable, teniendo en cuenta que nuestros usuarios son: Diseñadores, PMs y Desarrolladores.

Estos fueron los primeros pasos:

Nos pusimos en contacto con todxs los leads de diseño de todos los hubs para documentar el proceso en figma AS-IS.
Hicimos una investigación preliminar sobre la forma en que otras organizaciones con grandes equipos de diseño trabajan actualmente (referencias al final del artículo).
Organizamos un taller con gente clave donde que recogimos los AS-IS que funcionan/no funcionan y por qué, así como necesidades actuales. Durante el taller agrupamos las necesidades y las priorizamos en función de su impacto y esfuerzo.
Tras analizar los resultados del taller, redactamos una primera propuesta y la presentamos al equipo para obtener feedback.
Pasamos por dos iteraciones. Luego se documentó y comunicó la solución.

Vista general del tablero de Miro que utilizamos para trabajar juntos

Aspectos más destacados de los resultados

🙅 No funciona:

Hay demasiados archivos y los archivos son demasiado grandes.
Nadie sabe dónde encontrar los últimos diseños.
Nos faltan archivos Master/Macro.
Nos falta contexto o introducción al proyecto.
No hay un sistema de nomenclatura adecuado.
La documentación no está estandarizada.
Las covers que utilizamos y que tienen información relevante no son lo suficientemente claras.

👼 Funciona:

Mantener los archivos de marketing fuera del espacio de Diseño.
Comunicar el estado del proyecto en la cover.

❓Desacuerdos en varios temas:

Mantener la investigación dentro vs. fuera del archivo de Figma.
Tener un archivo “final” para desarrollo independiente vs. en el mismo archivo de Figma.
Espacio para las crits de diseño dentro del archivo Figma vs. fuera en Miro.
Mantener el prototipo que hay que validar independiente vs. en el mismo archivo de Figma.

📎 Necesidades:

Le preguntamos al equipo acerca de sus necesidades de cara al futuro y se creó esta lista (por orden de popularidad):

Plantillas: Es más fácil mantener estandarización si todos partimos de la misma plantilla.
Comunicar el progreso: La cover debe indicar en qué punto del proceso nos encontramos.
Estandarizar el formato: Una forma estándar de documentar las decisiones de diseño, comunicar los flujos de usuarios, las especificaciones, etc.
Single source of truth: Tener un archivo “maestro” para las cosas que ya están live.
Nomenclatura: Una nomenclatura clara para las pantallas y una convención para nombrar los archivos.
Trabajos inter-relacionados: Enlaces a toda la información relevante para el proyecto: Informes de investigación, tableros de Miro, tickets de JIRA, informes de Amplitud, etc.
Papelera de reciclaje: Un lugar donde tirar las viejas exploraciones o UIs descartadas sin perderlas por completo.
Acerca del proyecto: Un lugar para documentar quién es el desarrollador, el PM y el diseñador responsables, quién hizo los últimos cambios, etc.
Secciones necesarias: Necesidad de tener páginas específicas para: Investigación y análisis, prototipos, archivos de entrega, crits de diseño, etc.
Figma Enterprise: Posibilidad de tener un espacio dedicado a cada producto con distintos permisos de acceso.

Más o menos cuando empezamos a trabajar en esta iniciativa, nos cambiamos a Figma Enterprise. Esto nos facilitó mucho las cosas.

Jerarquía general

Si Yara es nuestra organization, proponemos que el team sea el de nuestros productos y los projects sean sus diferentes áreas de trabajo.

SOIL 2.0 es un producto, enmarcado en rosa. El marco morado indica las tres áreas de trabajo (equivalentes a los projects en Figma)

Las diferentes áreas de trabajo

1. Trabajo en curso / aka WIP: Cada trabajo de diseño que esta en curso/exploración tiene un archivo dentro de este área. Este archivo se comparte con las personas clave (eg. Product Managers, Desarrollo y otros). El handover ocurrirá dentro de este archivo.
2. Estado actual del producto / aka LIVE: En este área es donde tenemos la verdad verdadera. Solo mostramos lo que ya esta desarrollado. Dentro del area LIVE podemos tener distintos archivos para las distintas funcionalidades, plataformas, etc.
3. Exploraciones archivadas / aka ARCHIVE: Una vez que los diseños “finales” del archivo WIP se han desarrollado, podemos archivarlos. Esto nos va a ayudar en temas de documentación y para consultas futuras. Si después de tres meses nos preguntamos: “¿Por qué tomamos esta decisión?” podemos volver atrás y ver cual fue el razonamiento. El hecho de que todo el trabajo en curso (WIP) se traslade al ARCHIVE también ayuda a garantizar que el trabajo diario no se vea entorpecido por archivos antiguos.

Cómo dividimos un archivo WIP — Distintas páginas en Figma:

🖼 Cover: Una imagen para ayudar al equipo a identificar el archivo.
ℹ️ Como navegar este producto: Una guía rápida para desarrolladores y PMs interesados que explica dónde encontrar lo que necesitan.
❓Acerca de: Una ficha con información relevante al trabajo que va a comenzar.
💻 Listo para desarrollo: Pantallas finales y especificaciones listas para ser compartidas con los desarrolladores.
👆 Demo para desarrollo: Un pequeño prototipo que sirve para informar a desarrollo de ciertas interacciones.
🔍 Investigación / Analítica: Colección de toda la documentación de investigación y analítica disponible. Esto incluye insights, notas, análisis de la competencia, capturas de Amplitude, etc. Todo lo que se necesita para empezar a diseñar.
🕹️ Playground para diseño: Todas las exploraaciones que se realizan durante el proyecto. Con notas acerca de porqué se toman ciertas decisiones. Se trata de un lienzo abierto para explorar ideas, probar diferentes soluciones, recibir feedback e iterar. También es la página en la que se genera la mayor colaboración. Suele estar llena de comentarios del equipo.
✏️ Playground para UX Writing: Este es el espacio dedicado para que los UX Writers jueguen con distintas versiones de contenido.
💬 Crit de diseño: Todo el material necesario para hacer una crit de diseño y obtener feedback.
🔙 Prototipo para validación: Sólo necesitamos utilizar esta página cuando creamos prototipos para validar con usuarios.
✅ UI final: Esta es la página más organizada y estructurada de todo el archivo. Es donde viven los diseños finales/flujos de usuario.
🪦 Papelera de reciclaje: Una segunda oportunidad para el trabajo descartado.

Enmarcado en rosa, la estructura propuesta para las páginas

Empezar un nuevo trabajo de diseño. Paso a paso

Paso 1. Duplicar la plantilla

Los diseñadores comienzan el su trabajo accediendo al área WIP de su producto y duplicando la plantilla WIP.

La plantilla WIP preparada enmarcada en rosa

Paso 2. Activar las librerías necesarias

El siguiente paso es activar la librería del sistema de diseño del producto. También hay que activar la librería DesignOps, que contiene elementos que ayudarán a estructurar el trabajo.

Algunos de los componentes de la librería DesignOps. Los diseñadores pueden utilizar los componantes para hacer anotaciones en su trabajo. Otros componentes creados son marcos, fondos, notas para feedback, cabeceras, diagramas de flujo, etc.

Paso 3. Cambiar la información de la “cover”

Información de nivel 1 (en amarillo): No es necesario editar, viene preestablecido.
Información de nivel 2 (en rosa): ¿A qué funcionalidad o parte del producto pertenece este trabajo?
Información de nivel 3 (en naranja): Hay qe darle un nombre claro al trabajo que se está realizando.
Píldoras de estado (en verde): Activar la píldora de estado para indicar en qué fase del proceso de diseño nos encontramos.

Paso 4. Cambiar la información de la página “Acerca de”

Nombre del proyecto y una pequeña explicación
Información general: Proporcionar datos como: fecha de inicio, el ticket de Jira, el sprint al que pertenece, etc.
Documentos relacionados: Añadir enlaces para referenciar diferentes tipos de documentos. Añadir un título, una descripción y un enlace (tantos como haga falta).
Equipo: Identificar a los miembros del equipo añadiendo nombre, apellido y rol. Se puede elegir una foto preestablecida o subir la foto real del compañerx.

Paso 5. Seguir el proceso de diseño

Se espera que los diseñadores trabajen en las distintas páginas que hemos creado en Figma a medida que avanzan en el proceso de diseño.

Hay páginas específicas para documentar investigación y análisis, hay un playground donde el diseñador puede explorar diferentes ideas, también un espacio para colaborar con UX Writing, etc.

Todo el proceso de diseño está dividido en distinta páginas en Figma. Todo el proceso desde el kick-off hasta que se comparte con desarrollo.

Además, en cada una de las páginas de Figma existe una checklist que hay que completar antes de pasar a la siguiente página. Por ejemplo, no entregaremos nada a desarrollo sin haber documentado todas las casuísticas.

Enmarcado en rosa ejemplos de checklists

Paso 6. Listo para desarrollo

Cuando la página “Ready for Engineering” está terminada, el archivo se comparte con los desarrolladores. Sin embargo, nuestro trabajo no termina aquí. Ese archivo WIP sigue en progreso hasta que el trabajo esté listo en producción.

Paso 7. LIVE

Cuando el trabajo está en producción y el usuario final ya puede verlo, el diseñador fusiona las pantallas finales en el área de trabajo LIVE.

LIVE debe ser la única fuente de verdad.

Paso 8. Archivar el archivo WIP

Una vez realizado el paso 7, el diseñador puede arrastrar el archivo WIP al área ARCHIVE.

Cómo asegurarse de que los diseñadores cumplen

Como todos hemos trabajado juntos en esto, nuestros diseñadores están interesados en hacerlo realidad.

Pero para asegurarnos de que el nuevo proceso se implanta correctamente también:

Presentamos la solución varias veces en diferentes canales (showcases, mail, videos).
Creamos un canal de Slack abierto para preguntas relacionadas con esta nueva estructura.
Organizamos reuniones quincenales con cada design lead.
Establecimos reuniones mensuales para hablar de temas relacionados con DesignOps.
Creamos un tablero de Miro en el que todo el mundo puede dar feedback cuando quieran.

Tablero de Miro donde recojo feedback acerca de la nueva estructura

¿Y ahora qué?

Llevamos dos o tres semanas trabajando con esta nueva estructura. Y aunque aún es pronto, hemos visto algunos resultados positivos.

Sin embargo, ya he recibido feedback:
“Mis prototipos para validar son demasiado grandes. Si los tengo dentro del archivo WIP, tendré problemas al cargarlos”
“¿Dónde puedo almacenar el material para marketing?”

Por ahora, vamos a mantener la propuesta durante un par de meses y obtener otra ronda de feedback para poder iterar a partir de ahí 🤞.