PJ Onori

PJ Onori

@pjonori.com

I work on and write about design systems. Purveyor of fine typos.

790 followers238 following1.1K posts

The problem I have with a the recent hullabaloo around taste in software circles is that it’s primarily driven by self-proclaimed tastemakers. But in reality they’re peddlers—peddling taste.

And the thing is, it‘ll work because for sizable amount of people, good taste is good when others deem it good.

I’m starting to think design systems should *slightly* piss people off. Just a wee bit—and not to be a jerk. But a strong point of view is bound to ruffle feathers. Which is a good thing, if done well.

But that begs the question—if people buy into that statement, how many folks working on design systems are comfortable with that?

PJ Onori reposted

I'm currently looking for full-time or contract work. I specialize in building CSS-based design systems where engineers don't have to write CSS and helping product teams develop a shared language for building on the web. If you know of anything that might be a fit, please let me know. Thanks!

I‘ve been hearing a lot of feedback around adding support for icons In DSDS. I‘m trying to abstract that to something more general. What do people think about an “asset” entry kind that covers icons, illustrations, fonts, Lottie files, etc.?

DSDS 0.22 coming soon. Maybe next week. Should be more refinements than anything else—which makes me think it’s headed in the right direction.

The thing that I’ve continuously failed to successfully communicate is an unbridled focus on design system adoption is a one way trip to devolving into a UI library. A design system isn’t a design system if every single edge case/preference is covered. It’s exclusionary by design.

Mike Krukow has been a fixture of San Francisco Giants' radio and TV for 26 years. He's a future Hall of Famer. Today was his last day. If you're not familiar with the Giants, it's impossible to know how much he's meant to fans. And on his last day, he got a great sendoff.

After many, many speaker talking about how much he meant to them, he said his final words. He spent the entire time thanking everyone else. He didn't utter a single word about himself. He's the epitome of a class act. He's given so much—and during his retirement, he chooses to thank everyone else.

DSDS 0.21.0 is out. - A new style guide for how to structure/order the schema - traits' traitType now provides more explicit callout to variants vs states via traitType - sections can now carry tags for easier categorization - A new apiId allows for mapping prop/attribute names to traits and combos

I'll never dismiss what Atomic Design has done to create an approachable model for design system hierarchies. That said, I find the divisions subjective—which in turn leads to wildly different interpretations.

View full thread

Perfect? No. But something that's repeatable and _should_ be more universally applicable across systems. Thoughts?

Also worth mentioning—I just applied that approach to our own design system and had some pretty hard disagreements where some components ended up. So, the thinking needs some work. 😂

I'll never dismiss what Atomic Design has done to create an approachable model for design system hierarchies. That said, I find the divisions subjective—which in turn leads to wildly different interpretations.

I've been thinking about a more objective way to assign "tiers" to design system components. I'm wondering if something as simple as this: - Level 0: Components made from no other components - Level 1: Components made from Level 0 components - Level n: Components made from Level n-1 components.

DSDS update. I'm pretty much done with a full, start-from-scratch redesign of the schema based on what I've learned. The only thing that's holding back publishing is the documentation. I'm trying to make the docs site simpler. I'm hoping to have something ready by next week.