If you are working on several compositions at the same time or if your are several designers on the same design, it is important that the team (both designers and developers) knows that the Design System is reliable (“I’m looking at the right object”) and fresh (“it’s the latest validated version”). That’s one of the hardest parts to achieve because you always need to be working on different leads and the system is a living organism in perpetual evolution.
To achieve reliability and freshnesh you can
- remove unused components. For this, I personally use a plugin called “Instance Finder” that helps me find all instances of a component in a Figma File. When I think that an object is not used anymore, before deleting it, I make sure no instance references it anymore.
- move or remove deprecated components. Deprecated components are objects that are still in use somewhere in your file while having a newer version in your Design System.
- find a signage to indicate the state of the work. There are many ways to help you get there : you can either put your Work In Progress in a dedicated page or dedicated frame of the page or add a tagging system like Igor Lanko’s or use some dedicated plugins like Status Annotation by Thomas Lowry
Many other plugins exist to help you maintain you designs clean and tidy. In 20 Figma Plugins, Carefully Selected By Experienced Designers you will find other plugins to keep your Design System organized.
Your design system evolves and so does the code. It is inevitable that the two end up living different lives but you want to keep them as tight as possible. Some say developers have to stick to the design at all costs. I say we have to adapt to each other.
That’s why at regular intervals I do “reverse designing” sessions to adapt components and layouts to their actual implementation. With a frontend developer, we examine a layout or a component closely to spot any difference between design and implementation and we see how we can make the two converge. Sometimes I have to adapt the component, sometime my fellow developer has to adapt the code or the CSS theme.
On top of keeping design and code as homogeneous as possible those little “peer sessions” with a front developer help me understand the constraints of the front men and it helps them understand mine.
Last but not least, to ease a shared understanding both of the designs and the process, I have established a weekly UX ritual through which I present the UX work in progress, discuss leads and dead-ends and give the team visibility on where I’m at.
I use a gitlab board — shared with all the team — to show the progress of my work. Since gitlab is the tool our developers use as our code repository, there is very little friction and no barrier to entry to the tool: everyone can see the board and what’s going on. Plus, I used the same conventions as our functional board (like gitmojis for instance).
I update each issue as I work according to this lifecycle
- issue is opened with a simple title (based on a feedback or painpoint) and description of the the design request
- issue is updated with paper prototypes that are then discussed in the weekly UX meeting
- issue is updated with the Figma prototype when ready and this prototype is demonstrated in the weekly UX meeting
- issue is ready for implementation and a corresponding issue is created in the functional repository
- issue was developed and passed the acceptance tests: yay we can close it!
