Abstract
En el equipo trabajamos con Abstract porque nos permite tener un control de versiones del producto y trabajar varias personas simultaneamente sobre un mismo archivo de Sketch, nuestra principal herramienta de trabajo.
Con Abstract hemos conseguido eliminar copias en conflicto, duplicados y confusiones sobre cuales son los archivos finales. Y además, nos ha permitido incluir a nuestros clientes en el flujo de trabajo, pudiendo estos visualizar el trabajo realizado y el estado en el que está proyecto.
✏️ Para que los clientes puedan ver el proyecto deben estar invitados al proyecto y formar parte de los miembros de este.
En este apartado veremos cómo funciona Abstract y cómo lo utilizamos en el estudio en nuestro día a día.
La estructura básica de abstract se compone de Master y Branches. Su funcionamiento se basa en realizar commits y mergear ramas, o branches.
Los commits representan los cambios que se han realizando. Un commit puede entenderse como una foto a un archivo de Sketch en un momento determinado, permitiéndonos volver siempre que queramos a ese instante. El conjunto de commits forman un histórico, donde están reflejados todos los cambios que se han realizado sobre los distintos archivos de Sketch que formen un proyecto. Esto nos permite tener conocimiento del trabajo realizado, y que ante cualquier ausencia no prevista, se pueda continuar con el trabajo sin ningún problema. Cualquier miembro del equipo podría seguir sin que se produzcan pérdidas de información, conocimiento y trabajo.
El Master es la Source of truth de nuestros proyectos. Todo lo que contenga el Master debe estar listo para poder validar el trabajo con el cliente o subir los diseños a Zeplin para producción.
Cada persona que trabaja en el proyecto, trabaja en una rama distinta. Cada rama pertenece a una persona distinta. Todas las ramas principales sobre las que se trabaje una nueva funcionalidad o un concepto deben partir del Master, ya que es allí donde están reflejados los últimos cambios buenos realizados. Y una rama puede sostener otras, de forma que varias personas puedan trabajar sobre lo mismo y posteriormente se pueda unificar sin problemas el trabajo realizado.
Al realizar una rama se realiza una copia exacta de los archivos de su rama padre, bien sea el Master o la rama de otro compañero. Esto nos permite evitar pérdidas de información.
Para nosotros, ejemplos de ramas podrían ser:
Branding
Exploración visual
Módulo de búsqueda
Flujo del checkout
Alineación navbar
Las ramas tienen un nombre y una descripción.
El nombre debe ser descriptivo sobre lo que se va a trabajar en esta.
La descripción debe complementar al nombre. Para nosotros, una buena descripción es aquella que contiene cuales son los requisitos para que la funcionalidad se complete o cual es el objetivo de ella. Así, cuando se haya cumplido se podrá mergear con su rama padre.
En este apartado compartiremos como utilizamos Abstract en el equipo, cual es nuestra metodología, nuestras pautas y procedimientos ante los distintos proyectos. A este proceso hemos llegado tras trabajar meses con la herramienta, pero para cada equipo y proyecto pueden funcionar de forma distinta.
✏️ Un commit puede entenderse como una actualización de los archivos de Sketch en un momento de tiempo determinado, de forma que recoge todos los cambios que se han realizado hasta ese momento.
¿Cuándo realizamos un commit?
En el estudio, distinguimos entre tres tipos de commits, que representan tres momentos en los que se debe realizar un commit.
Cada vez que se complete una tarea. Esto nos permite llevar un control sobre cuándo se llevó a cabo y cuales fueron los cambios realizados para completarla.
En las ramas de concepto, a lo largo de la fase de exploración, realizamos un commit cada vez que se cambia de dirección.
Al finalizar el día. Siempre, cada uno de las personas del equipo debe hacer commit antes de cerrar el ordenador e irse a casa. Esto nos ayuda a que cualquiera pueda continuar el día siguiente con el trabajo, en el mismo punto que se dejó el día anterior.
✏️ Las tareas coinciden con las tareas marcadas en Asana, que es donde reflejamos el roadmap y las tareas a realizar en un proyecto.
¿Cómo se realiza un commit?
✏️ Para hacer un commit habrá que clicar sobre Preview and Commit en la bar que sale la parte inferior en Sketch. Al seleccionar esta opción, se cargan todas las pantallas añadidas o modificadas en Abstract para poder visualizar los cambios que se han realizado.
Para completar el commit, hay que incluir un nombre y una descripción de este. El nombre y la descripción nos dan contexto para cuando queramos visualizar commits anteriores, y que sean los suficientemente claras es especialmente útil cuando queremos retroceder a un punto concreto.
El nombre debe ser descriptivo y la descripción contener los cambios realizados. Una buena práctica para dar nombre al commit realizado es:
Si el commit se realiza tras haber completado una tarea, el nombre debe coincidir con el [nombre de la tarea].
Si el commit se hace por haber finalizado el día, el nombre debe seguir la siguiente estructura:
Avanzar con [nombre de la tarea].
Si el commit es en una rama de exploración, el nombre debe describir los cambios realizados
Para nosotros, la descripción es una lista de cambios que se han realizado entre un commit y otro. Para que esta sea clara y fácil de entender por todos los miembros que formamos el equipo utilizamos la siguiente nomenclatura:
✅ [Acción] [Donde se producido la acción]
Un ejemplo sería:
✅ Añadir [artboard]✅ Añadir [symbol]✅ Añadir [página]✅ Cambiar [módulo]✅ Cambiar [symbol]✅ Eliminar [módulo]✅ Eliminar [página]✅ Cambiar [página]
Cuando mergeamos estamos unificando el archivo de Sketch. Al mergear volvamos todos los artboards y páginas en los que hemos estado trabajando y hemos realizado cambios al archivo que se encuentra en la rama padre desde la que hicimos la rama. Nosotros hacemos merge cuando se completa el objetivo para el cual fue creada la rama en la que estábamos trabajando. Como por ejemplo, tras completar una funcionalidad.
Cuando mergeamos una rama, Abstract nos da la opción de incluir detalles. Esto es importante cuando hay comunicar información al equipo sobre los cambios realizados en la rama, y queremos que esta quede reflejada.
Puede ocurrir que se modifique un mismo artboard o un mismo símbolo en distintas ramas. Cuando esto ocurre, Abstract nos obliga a seleccionar con que opción nos quedamos. Es importante que esta decisión se tome junto con el equipo que esté participando en el proyecto, y comunicar finalmente cual es la decisión.
Abstract nos permite añadir comentarios sobre los distintos elementos de un archivo de Sketch. Esto nos ayuda tanto a la comunicación interna como a la colaboración con el cliente y su equipo.
Cada proyecto en el que trabajamos en el estudio, forma parte de un proyecto distinto en Abstract.
Los proyectos en Abstract tienen un nombre, una descripción y un color asignado.
Para el nombre, mantenemos el nombre del proyecto tenemos en Dropbox. De esta forma, conseguimos mantener consistencia en las distintas herramientas con las que trabajamos.
La descripción es interesante y recomendable que refleje la descripción del proyecto y sus objetivos a alcanzar.
El color sirve como identificador visual del proyecto, por lo que es bueno que este sea el color principal de este.
Para mantener los procesos, creamos los de Sketch direcamente en Abstract. Abstract, nos permite crear archivos de Sketch o bien librerías de Sketch. Las librerías que creamos en un proyecto quedan automáticamente vinculadas con todos los archivos que contenga este.
La nomenclatura de nuestros archivos de Sketch siguen el siguiente formato:
[id archivo][tipo de archivo][Plataforma]
Un ejemplo sería:
01_Research02_UX_Web02_UI_Web02_UI02_UI_App_Android02_Design-System
✏️ Para conocer más sobre como nos organizamos y cual nomenclatura de archivos que seguimos puedes encontrarlo en 1. Cómo nos organizamos.