Este contenido está basado en la experimentación de haber trabajado con versiones en sistemas de diseño y enfocado al mantenimiento de estos y su gobernanza.

Trabajar por versiones nos permite distribuir el trabajo en el tiempo, establecer un roadmap y definir hitos. Tiene sentido en proyectos que tienen continuidad en el tiempo o que son lo suficientemente complejos para que dividir el trabajo en fases tenga sentido y aporte valor.

‍

A la hora de trabajar con versiones es importante contar con unas fases definidas, conocer qué se va a atacar en cada una de ellas y tener un backlog en el que se puedan establecer prioridades.

Cada versión debe satisfacer unos objetivos concretos y cuantificables. Estos serán definidos en función de las prioridades junto con el equipo. Un ejemplo para un sistema de diseño sería un listado de componentes a trabajar.

Figma nos permite realizar commits, es decir, guardar los cambios realizados en un momento del proyecto a través de Version History. Para los sistemas de diseño, cada vez que se cree, añada, modifique o elimine un componente o estilo, se realizará una commit. De esta forma queda registrado a modo de changelog, teniendo así control y constancia del trabajo realizado.

Para realizar los commits en Version History se propone la siguiente estructura:

Las observaciones nos servirán de apoyo para detallar modificaciones concretas, por ejemplo, si se unifica un componente. Formato: bullet points.

Una versión se considera como cerrada si cumple con todos los objetivos marcados.

Es recomendable, al cerrar una versión, realizar una copia del archivo para conservar una foto fija de la versión en el momento de publicación. Esta copia se moverá al proyecto Versions en Figma. Estas versiones podrán ser consultadas tanto por desarrollo como por diseño, permitiendo:

• Ver la definición de los componentes de la versión debido a que el archivo del sistema de diseño puede tener cambios a medida que se trabaja sobre él.

‍Resumen: Pasos a seguir

A modo de resumen, para trabajar por versiones se seguirán generalmente los siguientes pasos:

1. Definir objetivos con el equipo.
2. En la fase de ejecución, realizar commits según se vayan alcanzando los hitos.
3. Al cumplir todos los objetivos, cerrar versión.

‍Diferencias entre new version, new feature y fix

Cada equipo puede determinar qué concepto asigna a cada una de estas. Por lo general, lo utilizaremos de la siguiente forma:

• New version. Cuando hay un cambio muy significativo. Por ejemplo, un rediseño visual en los componentes.
• New feature. Para la incorporación de cambios. Normalmente, será la que más utilicemos.
• Fix. Para corregir posibles errores sobre la versión existente.

‍

‍