When I wrote Common Patterns in Styleguides, Boilerplates and Pattern Libraries back in May, I honestly didn’t know if anyone would find something as pedestrian as a spreadsheet that interesting. It was great to discover I’d at least partially solved a problem for a lot of people. But I was surprised to hear from a handful of designers and developers who interpreted it as a score card… the more patterns a library contained, the better.
Yikes! Totally not my intention.
Here’s the thing: These frameworks are terrific resources. I think it’s really helpful to see how other teams craft (and document) scalable and modular interface elements. They are excellent points of reference.
But I tend not to use them for more than that. For two big reasons.
It’s a rare project that launches with less complexity than anticipated. So why front-load your project with the totality of another team’s interface needs?
I think that our industry in general has it a little backwards: instead of the default being a framework or all these other little plugins and polyfills, the default should be just simple HTML and CSS. Then, as the project needs, you can start including things. But everything you add to a page or project adds something — be that weight, maintenance or complexity — and therefore everything needs to be justified before it gets thrown into play. Start light and vanilla and only add things in if they’re necessary.
And from Aaron Gustafson:
Many of these frameworks are incredibly well-designed and executed. But how, and why? Why that corner radius? Why that font size? Why three button sizes… why not four, or five? How can we competently extend this design thinking without knowledge of its history or principles?
Every design is like a little language with its own correct grammar and syntax nearly as specific as a programming language. It contains primitives but instead of concepts like maps, arrays, integers, and functions the primitives include size, weight, color, proportion, and texture.
Without first understanding that language it’s impossible to correctly express anything new. And that’s where the problems start for most people using these libraries. If they stay safely within the provided components they can make an application that looks designed (because it is) but no UI kit provides every possible component or even has guidance about all the ways existing components can be combined.
In the immortal words of Emil Faber, “Knowledge is Good.”