How to organise your design projects.
Or at least, how are we doing it at Metropolis:lab 😊
Hello everyone, this is my first post on Medium… Please, don’t be too hard on me 😅!
I’m pretty curious about teams and projects organisation. Obviously, there is no single method and may depend on so many things like type of company, product, platform, size of the team, expertise, legal issues or budget for instance.
I thought that maybe explaining how we are currently doing at Metropolis:lab, may generate a bit of a discussion around and maybe some comments of other’s perspectives and configurations.
Our Design stack
This may seem irrelevant for someone, but if you try to remember how was your design workflow before the era of Sketch, Figma, Zeplin or Avocode, the memories would be quite painful.
So, what’s our stack? Something very common, actually. Just Sketch + Zeplin and the addition of a true game-changer called Abstract.
For those who are new to it, Abstract is a version control app for design files. Kind of what Github is to developers, where you can track your designs, work with multiple colleagues in the same file without overwriting the changes, recover older versions of your work, specific feature branches and many more.
Adding Abstract to our workflow, really improved our collaboration and review processes. Also has given a bit more transparency on the design iterations for those outside the Design team, like Product Owners or Developers, that now they can comment and evaluate the ongoing stuff.
Here is how we do it:
The set up.
Instead of working directly on separated Sketch files, we use Abstract as a hub. There, we define the structure of the project, link the specific libraries to it and review all the changes with the rest of the team.
Since we’ve been working on multiple products lately, we like to organise the files with a Platform based approach where there is an Abstract project for each of them: Android, iOS, Website and so on.
A part from that, each project is linked to a Library of components that’s shared across all platforms. This Library is a separated project as well, doing it like so, allows a better control of the changes that’s quite necessary for this kind of sensitive files that directly affect the rest of your designs.
There are other possible methods or structures that can be used too. For example the Client based, that may work for agencies, or the Feature based that may be more useful for single-product teams.
Note that inside any of the projects you could have multiple files as well. So let’s imagine that for the Library you want to create multiple sections like Icons, Colour, Typography and Components. You could have a single (and pretty huge) file with different pages inside or multiple and lighter files dedicated to the different purposes.
Branches + Versions
For the project versioning we try to use the same layout as development does. So, we generally work on 3 different levels:
- Master
- Next versions
- New Features / Hot Fixes
Master
This level should be the last that’s published, it’s also known as Production. This is the source of truth for what is out on the markets and should not suffer any changes until the next branch merges in with the new released version.
Next Versions
Those are the versions to come. Generally we use two branches at a time, the first is for the one that’s currently being developed and the second for the next ahead. This allow us to have a branch that gets minor fixes and updates that we encounter during the development phase and another to work on new features and design discovery without adding noise to the team.
Here we use a pseudo-level on the second branch. We branch it from the first to get all the updates from the previous one. After the first one is completely developed and merged into master, the second branch stays as the primary.
We mirror all the designs fo the first branch into Zeplin.
Worth mention that Abstract already has an Inspect tab with all the colours, measurements and typography styles but the exportation of assets is not there yet.
New Feature / Hot fix
This third level is used to try new things, fix others and validate the designs with the team before merging to a more stable version. You can have as many as you need but don’t get crazy over-branching with super small things.
And that’s it, hope this helps to somebody that’s just starting or growing a team of designers.
Thank you! 👋
