Where the design community meets.
I've noticed that none of these publicly available component library / design system files actually utilize Sketch symbols to set up for global changes or instant responsiveness or anything like that. Am I putting my time in the wrong place by investing too heavily in making a library of symbols where all colors and styles are linked and constraints are fully utilized?
Hey Sean! If I can toot my own horn a little bit, UX Power Tools is built in a sustainable fashion using all of the techniques you highlighted: text styles, layer styles, and symbols (many of which are nested).
You are NOT wasting time by prioritizing interlinking, style usage, and symbols. It will save you incalculable amounts of time in the future. So keep doing what you're doing.
If you're interested, here's a link for the system we've built:
You can — and UX Powertools was my starting place. I purchased it, but ultimately decided that for my needs it was maybe TOO flexible and, honestly, that I really needed to build it myself from the ground up to cross the knowledge/skills gap. I wanted to really understand why everything was the way it was and how to build things myself in the future... and reverse engineering files like yours and Jan Losert's helped me do that. So thanks :)
Same here. I started exploring UX Powertools, loved it, but found it a bit complex, especially to roll out to a team of people with mixed experience in Sketch.
In the end, I've built a library from scratch, containing the most common components we use, along with basic wireframe elements (boxes, shapes, placeholder, etc.). I spent significant time testing each thing I created, making sure things resized appropriately. In creating it, I've organized around atomic design principles, but for my team, I've changed the naming convention to keep things simplified. Everything we use regular is in a folder called "Components," and the next step up from there is Patterns, consisting of groups of components. From there, we will collaborate on building out reusable templates that suit best practices and our POV on things.
I'm definitely glad I took the time to build from scratch. I know it inside and out, which will help team members troubleshoot anything they have problems with.
I was planning to do the same with naming, but ended up adopting atomic (even though I hate the metaphor [for no good reason]) because the developers were already using atomic — so it seemed that it would be wise to all use a common language.
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.
Wow, thank you — I actually need to make material variants of many of our components so as not to ruin the lives of our Android devs... so this is going to be incredibly helpful as a reference.
Where the design community meets.
Designer News is a large, global community of people working or interested in design and technology.