Last Call has loved the industry-wide push towards pattern libraries. We think pattern libraries are a smart, efficient way to iterate quickly while maintaining design consistency, and the seemingly unstoppable momentum they’ve achieved in a relatively short time shows that a lot of people agree. “Oh, right, that’s for sure the way to do it,” was my first reaction to hearing about the concept.
So I was surprised when I looked around for examples of how people had set them up in Sketch and wasn’t able to find a whole lot. (Feel free to let me know what I missed in the comments!) So we decided to post ours. Over four posts this week, I’ll talk a bit about some of the ideas that went into our pattern library, and some of the advantages and disadvantages of implementing it in Sketch.
In the meantime, here’s a direct link to the 17MB Sketch pattern library file. Knock yourself out! While our pattern library is a living document that’s always being iterated on, this link is to a copy that won’t be, so this post will continue to make sense!
First off, take it easy bud
I’m predicting an array of responses to this (should I be so lucky) ranging from “What’s wrong with this guy, why would he put so much time and effort into this?” to “This is seriously lacking. Meh!” It’s important to note that pattern libraries… could literally never end! Personally, I could never run out of connections to identify and document. This is the heart of iteration. Everything’s a work in progress, it’s always possible to improve. This is just where our pattern library is at right now! If there are omissions or mistakes, I’d love to hear about them. (Again, smash that comment button folks.)
So… why?
Always a good question! It might seem strange for us to set up a pattern library for a site that’s already launched. One reason, a common reason for sites in this position, is to heighten consistency. Our site has changed a lot since launch, and things that weren’t designed to be next to each other now are. This has created some situations where things are… off. For example, two instances of text that are slightly different sizes; too small a difference to look intentional, but too big a difference not to notice. Or components like summaries or tabs might look slightly different from page to page. Having standardized sizing and styling defined and applied to all components will increase visual consistency and cut back on those discordances dramatically, making for a smoother user experience.
Having standardized sizing and styling defined and applied to all components will increase visual consistency
Also, we’re always working on our site by identifying opportunities for improvement, designing a solution, and working with development to implement it. Having a pattern library will not only help us maintain consistency in our new designs, but having a library of components we have immediate access to makes design a lot faster. Having a documented, common vocabulary with development also makes theming a lot smoother and more efficient.
Hey, waitaminute… isn’t this a design system?
We’re at the point in the establishment of pattern libraries and related concepts that there are a lot of similar, overlapping terms being used in different ways by different people. This was the case with UX and UI five or so years ago. Some people say design systems and pattern libraries are the same thing. Others say design systems are for styling and pattern libraries are for interface components. My current thinking is that if a design system is more on the design file side of things, and pattern libraries are more on the website side of things, the designs should serve the pattern library as much as possible and therefore resemble the pattern library as much as possible. So we just call ours a pattern library. Will we eventually break things down to the point that there’s enough distinct designer vs development content that it makes sense to separate them? Maybe!
Join me for part 2 when I start to dig into the meat of the subject. The contents of the pattern library itself!
