Great tips here, especially color naming.

This collaborative philosophy of matching design to code works great if the designer and the developers are starting anew on a virgin app.

In my own work experience, I've joined companies years after the website or web app was built, long before much attention if any was paid to design tokens, modular components, or working in sync. Websites built on old frameworks and enterprise software, full of bespoke html for every page template, as each new FE dev comes in and builds something for the current year's roadmap.

In this situation, a design system can either include the ideal states of components, or a recreation of what currently exists in code, which is quite often a set of class names applied inconsistently across templates.—neither of which is satisfactory for both parties.

I shoot for a middle ground of focusing on improving the UI where it will make the biggest impact on the user experience; even there, it can take a year or more to implement those changes. The design system is mostly type, color, and iconography, with newly built components added after deploy.

I'd love to read articles from designers who have successfully tackled situations much more typical: post hoc design system creation for a product built years ago by remote developers, while also getting new features out the door. What overall strategy did they take for creating and maintaining a design system in that situation? What advice can they offer when there isn't organizational support for designer and developer building components together?