This content is based on our experience in working with different versions of different design systems and focusing on their management and upkeep.
Working with the different versions allows us to spread the workload, to establish a roadmap and define milestones. It makes sense for ongoing or complex projects so that the stages are coherent and add value.
When it comes to working with different versions, it is important to set well-defined stages, knowing what is going to be dealt with in each one of them and having a backlog of tasks in which we can establish priorities.
Each version must fulfil specific and quantifiable goals. These will be defined depending on the priorities and the team. An example in the context of a design system could be a list of components to work on.
Figma allows us to make commits, that is to say, to keep changes that have been made in a project through the Version History. For design systems, each time a component is created, added, modified or deleted, a commit will be made. This way, everything will be recorded in a changelog, meaning we can maintain control and consistency in the work we do.
To make a commit in Version History we suggest following this structure:
Observations will support us when detailing specific notifications, for example, if a component is unified. Format: bullet points.
We consider a version closed when it meets all the set goals.
When closing a version, it’s advisable to make a copy of the file to keep an original of that version from the moment of publication. This copy will be moved to the project Versions on Figma. These versions could be consulted in the future for development or design purposes, allowing:
As a summary, in order to work on a version-basis, we will follow these steps:
Each team will determine what concept to assign to each one of these. Generally, we will use these terms as follows: