I would say mirror design structure in code. EG the folder structure of both your sketch files and code components follow the same atomic taxonomy.

I can tell you from my own experience that the setup process is long and very very detail oriented, but worth it once you can build out a whole series of separate uis that all connect back to a single source of truth. So when that one icon needs to be updated, you tweak it once.

I've settled on a model of two overlapping systems personally. Our UIs are based on Material Design, so I build out the Material standards first. Then, to keep that pure, I set up a second library that provides any custom elements we create. Finally, any actual UIs we create include both libraries, only deviating from the Material spec where necessary. This allows us to incorporate any changes from Google safely and cascade them down through the whole tree.

Check out https://github.com/adamnel/sketch-material to try it out. It works for me as a single contributor but I'd love feedback and to extend the Material library for broader use.

I've been building my own for the past few months and it's become pretty stable at this point. Uses many of the same principles referenced in this article.

Would love to know what you think: https://github.com/adamnel/sketch-material

I clicked 'update' on autopilot before I realized what I'd done.

Dodged a bullet so far, though

The / is used to divide when doing inline math in the input field

I've been doing this for a while now and it's fantastic.

Unfortunately, I learned the hard way that once you convert the entire Material Design 950+ icon set to use this method Sketch slows to a complete crawl. I had to move the icons out into a separate file and only bring in the ones I need on a case-by-case basis.

I agree. I appreciate that it's a little different which may be valuable from a branding perspective. I don't think it's ultimately worth it - it gives me low-level anxiety when looking at their designs.