It’s been four years since I wrote about Responsive Deliverables. Since then I’ve been working steadily with companies to build out their own “tiny bootstraps”. I’ve been reflecting on this work and I thought I’d share some of the things I’ve learned.

Rolling out a Pattern Library is infinitely harder than building one

Building a Pattern Library is somewhat trivial, you can literally “Just use Foundation” if you want. I think the hardest part of the job is rolling out the Design System. Whether it’s some edge case you didn’t think of or some degradation when integrating with the legacy system, there’s always something that comes up and takes more time.

Unless your development team has an abnormal degree of autonomy, there’s a lot of politicking that has to take place to secure development cycles to revamp pages that aren’t broken. “I need a day in the sprint cycle to make this page look basically the same, then I need to do that a few dozen times” is a tough argument to make to people who budget the hours.

We know it’ll speed up new feature development in the long run. But developers have a tendency to burn everything to the ground and start over. We’re at war with this instinct and not everyone can see the benefits of refactoring/re-architecting when there’s a mile long backlog.

The unfortunate irony here is that the longer it takes to roll out a Pattern Library the more out of date it is trends-wise. The problems it solved might be more or different. New design work has probably already diverged in leiu of newer, shinier trends. New CSS properties we can use (like Grid) could drastically improve the way we build things. Fifteen new JavaScript frameworks have been created since you started.

If you don’t have pages, it’s doesn’t solve the problem

“Systems not Pages” is something I advocate. Conversely, if you build blocks without pages, you’re just playing Fantasy Web Design. It’s tempting to focus on the blocks task but building a Pattern Library requires a lot of zooming in and out from the component level to the 10,000ft view. I like to view pages as a form of “test coverage” to make sure the Pattern Library can do its one job; build pages.

There’s also a social dynamic afoot that you can’t ignore too. Plainly, people who sign checks don’t give a shit about your components until they see the full pages.

Vertical spacing will make or break you

Vertical spacing is one of the toughest parts of building a Pattern Library. The best example of this is after you typeset your H1-H6 styles, you put it on a page and say “Oof, I need some default margin-bottom.” At the same microsecond you save your changes, a new comp appears featuring a paragraph or subheading directly under the title. Your smart defaults have created a nuclear wasteland called Override Town. Each futile refactor will be met with another edgecase.

Spacing is complex too. 1px, 1em, 1rem, 1%, and 1vh behave so totally different. A margin of 1em and 1rem on an H1 are very different. Finding a universal solution is so tough, at Paravel we’re even moving away from default margins on block elements in favor of utility classes.

Zooming out from the atom/molecule/component level, spacing is also a problem between tiers/layers of your page (aka, “the sandwich”). The nearly infinite combination of inter-component “lockups” must be taken into consideration. How components glue together and the mortar between them takes weeks of consideration and trial and error.

The only article I can recall about spacing in a Pattern Library is Nathan Curtis’ Space in Design Systems which is about logarithmic values in spacing variables. I’d love to read more about how people approach veritcal spacing in Design Systems.

The Pattern Library is dead if it’s not prioritized

This is well-tread territory, but I just want to add agreement. Again, Nathan Curtis sums this up nicely in his post “A Design System isn’t a Project. It’s a Product, Serving Products.”

It’s tempting to put some blocks in a bucket, put that bucket on Github, and then call it “Mission Accomplished”. But those blocks –even before they ship– need to respond to new scenarios and demands, they need to meet accessiblity requirements, they need to consider every possible lockup. These blocks solve a lot of problems and require a lot of consideration.

I think it’s safe to say a Pattern Library isn’t necessary for every project. But if your site, application, or network of content suffers from style collisions, repeated code, and lack of cohesive UX then a Pattern Library is probably a helpful tool to have.

But Pattern Libraries take time. They take dev cycles. Usually they have some redesign implications which may mean A/B test cycles. And it’ll need to be maintained going forward.

Questions I have…

One question I have and I posed this on Twitter, is how do you prevent a Style Guide from becoming a compendium of every web design trick ever? And should you prevent it?

Over time, the organizational demands a Design System must support continues to grow and grow. Variance kills a Design System, so all ad-hoc components must undergo a canonization process. Eventually your list of canonized components contains 10 types of hero unit variants. 13 types of feature lists. 3 media players. And an avatar class specifically for dogs. Updates become slower as more patterns are affected by atom-level changes. It’s no different than legacy software, burdened by years of demands.

If you’re bundling all this together, you have performance problems. If you don’t bundle, you have sharding problems.

There’s also an education problem. Jumping into a design system and digesting the whole of Web Design takes more time than most are willing to give. This creates a cumbersome Developer Experience, even if it solves a problem. You’ll probably get some “riffing”.

I have started to wonder if the “tiny” part of “tiny bootstraps” is really the most important part. Perhaps there’s a radical middle between perscriptive prefab components and allowing components to be built on-the-fly. Maybe a small digestible core with a good API (utility classes) would allow Pattern Libraries to be built quickly, extended quickly, and better serve your organizations. Guidelines would be needed for creating non-canon components to ensure the quality and DNA your users expect, but I think inspiration could be pulled from other ecosystems like jQuery, Node/NPM, and my favorite A-Frame which are very encouraging of extending the core system.

I know this is harder than it sounds but the end result I think would be a “flexible design system” that could do a better job serving users, developers, and the organization.