Front-end tools and practice

A thoughtful, important post by @beep about the great promise of design systems and component-oriented pattern libraries… and how a focus on design system tooling has kept many teams locked in broken ways of working. https://ethanmarcotte.com/wrote/the-design-systems-between-us/

Over the past several years, my content architecture and CMS strategy work has become more and more entangled in the way design is done inside large organizations. Tools can help streamline slow or overwhelming tasks in a process, but we need a vision for healthy process first.

“Process” doesn’t have to mean layers of bureaucracy — it can be as simple as answering, “How does a team modify a pattern to fit their needs?” and “If their efforts show promise, how and when do we re-integrate their work and share it with everyone else?”

Just yesterday I was talking to @beep about the way git and github have made the fork/pull-request/review/approve process standard. That’s a case of tools that support a specific vision of how experimentation and re-integration can happen.

I don’t have as much visibility into the daily grind of design work and FED tooling, but my limited view of it suggests that most teams and organizations are still trying to figure out what “flow” actually works for them, tooling or no.

In any case. Read @beep’s post; if you’re in the thick of this stuff I suspect reading it will feel like a cold glass of water on a very hot day.