The Pitfalls of UI Kits and Pattern Libraries

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?

.net magazine recently published an interview with six RWD experts. Here’s a gem of a quote from Tim Kadlec:

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:

I find Foundation, Bootstrap, and similar frameworks interesting from an educational standpoint, but I would never use one when building a production site. For prototyping a concept, sure, but to take one of these into production you need to be rigorous in your removal of unused CSS and JavaScript or you end up creating a heavy, slow experience for you users. I also think you need to work twice as hard to break out of the theme of the framework. There are a ton of Bootstrap sites out there that look like Bootstrap sites. Your design should be as unique as your product, not some off the shelf thing you just changed some colors on.

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?

Trek Glowacki wrote a wonderful gist that describes this problem in detail:

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.

Our own responsive deliverables benefit from seeing what patterns emerge from those who’ve solved similar problems before. We can learn from their techniques while crafting new ones.

In the immortal words of Emil Faber, “Knowledge is Good.”