Diseñando el Workflow con FigmaTiempo de lectura 7 minutos

Sin embargo, el correcto escalado y documentación de los archivos merece dedicar cierta atención a cómo planteamos la estructura. Que sea escalable según las necesidades presentes y futuras del producto y fácil de consumir para todos sus participantes.

Os contamos cómo lo hemos hecho en Bnext con Figma:

Estructura en Figma

Entender la estructura y las ventajas que nos ofrece Figma, en nuestro caso el Plan Organización, es clave para maximizar su buen uso.

Nos ofrece una estructura de 5 niveles, que son los siguientes:

• Organización: Todos los miembros de Bnext con un correo de empresa pueden acceder a Figma. Accederán con un permiso de vista y podrán unirse a los diferentes equipos abiertos.
• Equipos en Figma: Serán abiertos y cualquier miembro de Bnext podrá unirse a ellos. Los usaremos para organizar los proyectos del equipo Bnext en sus diferentes equipos.
• Proyectos en Equipos: Usamos los proyectos para organizar los archivos de trabajo. Serán un reflejo de la organización de los equipos, como en el de Product Design, que se dividirá en proyecto de tareas y documentación.
• Páginas en archivos: Las páginas nos ayudarán a organizar el diseño dentro de los archivos. En las tareas, organizaremos por páginas el según el proceso de inspiración, diseño y entregable. En los archivos de documentación, organizaremos las páginas según la arquitectura del producto.

Puedes saber más sobre Figma Organización aquí

Estructura del equipo Product Design

En el primer nivel de estructura de Figma, planteamos un equipo de Diseño de Producto, al igual que otros equipos como Gráfico o Sistema de Diseño.

En este equipo, adaptaremos la estructura de Figma para adecuarla a nuestro Flow de Diseño:

Dividimos el equipo en proyectos, que serán:

• TASKS: Archivos de tareas de diseño. Trabajamos las nuevas funcionalidades, nuevos conceptos, requerimientos, etc.
• MAIN MOBILE: Serán los archivos de documentación que muestren los diseños que están en producción del producto Bnext. Será la fuente de la verdad y servirá como documentación global de diseño.
• MAIN WEB: Al igual que en Main Mobile, será la fuente de la verdad del diseño que está en producción para el producto de la web. Se seguirán creando nuevos proyectos de documentación a medida que se creen nuevos productos en la compañía.

Organización de archivos de tareas y Sistema de Covers

El proyecto de Tareas, en el equipo de Product Design, se desarrolla en vista es fundamental para la correcta organización del equipo y asegurar un buen escalado del producto y su documentación.

En el proyecto de Tareas, organizamos y crearemos nuevos archivos en base a las tareas que se van requiriendo para el desarrollo del Producto.

Las asociaremos a una Cover de Figma, mostrando su estado, y a un nombre identificativo, que nos permita relaccionarla con su correspondiente en JIRA. Deberá estar asociada con su correspondiente ID de JIRA en el nombre de la misma, resultando en algo así:

En consideración con el flujo de trabajo del equipo de Diseño y las necesidades de los que consumen estas tareas, desarrollamos un sistema que se compone de las siguientes Covers de estados identificativas:

• Work In Progress: La tarea está en proceso, el diseñador está trabajando en ella.
• Ready For Dev: La tarea está terminada, validada por los diferentes perfiles y lista para ser desarrollada.
• Archive: La tarea está producida y documentada
• Pending: La tarea está lista pero todavía no está llevada a desarrollo.
• Declined: La tarea está acabada pero no pasará finalmente a producción.

Añadimos diferentes iconos que nos hacen más fácil identificar el proyecto de las tareas.

Estas Covers las utilizamos como componentes de Figma, lo que nos permite cambiar entre ellas con facilidad con las instancias. Las usamos en una primera página de los archivos reservados para la Cover, que Figma detectará como primer Frame y cargará como vista preeliminar. Cambiamos el fondo de esa página para que la vista fuera del archivo quede sin bordes.

Para el proceso de un diseñador en una tarea, creamos un archivo Template, que duplicamos siempre al empezar una para tener la configuración lista. El proceso que seguimos para actualizar las covers será el siguiente:

Estructura de páginas en una tarea

Dentro de las tareas, utilizamos las páginas para organizar el trabajo y desarrollo del flujo de un diseñador. Será una estructura básica que servirá como estándar:

• Inspiration: En ella podremos pegar capturas de pantalla o referencias de otras aplicaciones, bocetos, etc… No se trabaja en ella.
• Design: Será la página en la que trabajaremos para alcanzar los objetivos de la tarea.
• Proposal: Será donde colocaremos el diseño final y propuesta para validar la tarea. Podremos generar un enlace a partir de la vista de prototipo para compartir con la gente responsable de la revisión.
• Rejected: Propuestas que hemos hecho y han sido rechazadas, pero no borraremos por su posible utilidad de cara a futuro.

Organización de Main y Sistema de Covers de Flujos

Como documentación global, utilizamos los archivos Main que serán el reflejo del diseño que hay en producción. Estos archivos serán actualizados a medida que se desarrolla producto desde los archivos de Tareas. Organizamos el proyecto en archivos, que serán el reflejo de la arquitectura del producto, conteniendo en cada uno de ellos los flujos y diseños correspondientes.

Dentro de los archivos utilizamos un Sistema de Covers de Flujos, que nos permite organizar los diseños en filas y ser entendidos por todos los consumidores. Se utilizarán de la siguiente forma:

• Covers de Flujo: Indicarán el Flujo, Historia o Grupo de Vistas que vincule. En general, representaremos un flujo “Happy Case” con un nombre que lo describe y, en caso de estar fragmentado en filas para mejorar su entendimiento, añadiremos el detalle del tramo. También podremos añadir el país o países a los que corresponde el flujo, así como una numeración que los identifique en el archivo.
• Covers de Variante: Indica variantes de pantallas o posibles subflujos del principal. Indicaremos en la Cover el evento de la variante, así como una descripción detalla que pueda explicar cuándo ocurre. Para unir con el flujo principal, añadiremos la pantalla desde la que procede la variante
• Covers de Estado: Las covers de Estado nos ayudan a documentar pantallas que, sin ser un flujo ni variantes, las consideramos estados de otra. Puede ocurrir en pantallas al hacer scroll, con condicionantes según cierta información, etc.
• Covers de Inicio de flujo: Las usamos para representar el inicio de otro flujo documentado. Evitamos la duplicidad de pantallas y flujos y, con la opción de linkear desde Figma, creamos un falso botón que nos lleva a ellas. Añadiremos el nombre del flujo, así como una descripción si fuese necesario.
• Covers de Evento Externo: Se utiliza para documentar un evento externo del producto Bnext y que lo condiciona. Podrá ser el recibir un correo, SMS, abrir otra app, etc.

Debemos tener en cuenta sobre este sistema:

• Los flujos deben leerse de izquierda a derecha y de arriba a abajo. Si hay variantes, pertenecen al flujo inmediatamente anterior.
• Ha sido iterado en base a las necesidades de nuestro producto y equipos, así como por las futuras necesidades de escalabilidad del producto. Puede que, para otros equipos, sea más acertado o no según las necesidades específicas.
• Esta documentación estará apoyada con flujos dibujados en Whimsical, que serán mucho más visuales. Siempre conectados a la documentación de Figma como base.

Resultado final

Como resultado, hemos visto mejorada la comunicación entre los diferentes departamos y la consumición de diseños.

• Nos permite involucrar más a toda la organización y hacerles partícipes de decisiones de construcción, mejoras y búsqueda de errores.
• Con una organización en diseño, detectamos casuísticas que podemos corregir, mejorar puntos ciegos en diseño y seguir mejorando el producto.
• El sistema de tareas nos permite tener un control sobre los diferentes procesos abiertos en diseño y los estados en todo momento del desarrollo de producto. Además el crear archivos en figma ligados a JIRA, nos permite recuperar y tener una documentación firme sobre decisiones pasadas, descartadas o archivadas.
• Los archivos Main son de gran utilidad, pero requieren de gran mantenimiento y el involucrar al equipo de Diseño de Producto en entender su importancia. Estar alineados en su desarrollo es imprescindible.