Hey, check out our Sketch pattern library! Part 4: Conclusions and next steps

This is part four in our series of posts about our Sketch pattern library. If you missed them, it’s probably best to read part one, part two, and part three first. Here’s a direct link to the 17MB Sketch pattern library file we’re discussing.

Next steps

Like I’ve said, this is still a work in progress and will always be. Here are some of the biggest improvements we’re looking forward to implementing.

The biggest next step for us is to implement this pattern library on our site! This will be an additional project unto itself (one we’ll be completing with our own open source component theming tool Mannequin, natch). I’m anticipating that some changes to the design file will need to happen once the rubber hits the road. We’ll also be reconsidering the structure and vocabulary as a team, in order to get as many ideas into the mix as we can and to give the entire team ownership of the pattern library- making them more comfortable implementing it and even changing it themselves.

A few things need to be moved around. For example, “Lines and Horizontal Rules” are an atom, really. Image Captions either need to be made an atom or expanded into representing content images as a whole.

We’re missing a couple things; the header, and our Solution Story Covers have a full image layout that isn’t represented.

There’s bunch of big, important stuff we’ve yet to add.

• Guidelines for motion design. What are the qualities motion should have in order to meet our branding?
• Site-wide responsive behavior. What are the max widths? The site-wide margins?
• Document our grid system.
• What are the site’s breakpoints?

There’s an issue with some of the vocabulary we use in sub-atoms. We list our font sizes in S, M, L, etc. Some fonts use similar vocabulary, leading to some awkwardly named font sizes like “Gilroy Medium M”.

Once we’ve implemented it, and some of the bigger gaps are filled, we’re considering making a generic version of it to release for free for people to use as a template. In the meantime, feel free to download this file and use it as a starting point for your own pattern library!

In addition to implementing and continuing to iterate on our pattern library, this thing has to live and thrive now. If we have a new idea for the site we have to consider whether it’s something that needs to be incorporated into the pattern library. And we need to navigate exactly how to keep it up to date. Is there a single person in charge of editing it? Or should multiple team members have ownership over it? There are advantages and disadvantages to either.

Conclusions

I had a lot of disparate thoughts while making this pattern library that don’t really lend themselves to being put in an orderly manner. So here’s a more or less random assortment of deep thoughts about our pattern library. I recommend imagining the voice of Jack Handey while you read them.

Our pattern library has documentation right on the designs, with no external documentation. We’re able to get away with this mostly because our site was already built, so the functionality didn’t need to be specced out. So if your site isn’t built, or even if you’re just at an organization that requires more thorough documentation, this may not be an option for you.

I don’t like listing styling specifications on the design, but we do it in a number of places. Namely, on the font styling sub-atoms, and on many individual pieces of text that don’t utilize a font styling sub-atom (like body copy, for one). I put them in because it’s nice for our developers to not have to go into InVision Inspect all the time. I also like the intentionality of it. I think developers are more likely to notice and implement some of the more subtle styling (like, say, letter spacing) if it’s mentioned on the design itself.

Those first two points brush up against something I thought a lot about throughout this process. I tried as much as possible to have a single source of truth for our pattern library. With our documentation I succeeded. It’s only in one place (on the designs). But with our styling specifications I failed. They’re listed on the designs and in InVision Inspect. Having multiple sources of truth increases the chance for errors (we won’t always remember to update something in more than one pace) and decreases agility (because changes take longer).

Having multiple sources of truth increases the chance for errors and decreases agility.

These designs are about as close to pixel perfect as anything I’ve ever done. As far as I know they are pixel perfect. Is there value in that? I think there is, but I also think it’s rare that value is justifiable in the face of the amount of effort it takes. But that brings me to my next point…

This design is an illustration of our best practices! Again, there are always improvements that can be made, but I wanted this to be something I could use as an example when describing our design standards. We don’t often get the chance to make something this pristine on a project. In fact it’s almost always impossible! But if we design with these rules and benchmarks in mind, our designs will be better for it and it’ll get easier and easier to get closer to this.

Because we won’t have the luxury of perfecting designs on projects, there’s still going to be judgement calls that need to be made by the developers. One rule of thumb to help with that is if some styling is noted to correspond to a sub-atom, but the design itself is slightly off from that styling… err on the side of protecting the integrity of the pattern library and use the styling defined in the sub-atom.

Err on the side of protecting the integrity of the pattern library.

One might be tempted to start the design process with the pattern library, so it can be used to inform the rest of their designs. You can get started on some of it, like colors and fonts, but largely people just don’t think this way! It’s hard to design organisms and even molecules in a vacuum. More likely you’ll be filling out your pattern library throughout the design process, adding to it as new discoveries are made. It works best for most people to do a few designs, so you can have an idea of how your components will look in context, and start constructing the library from there.

You might think that would produce results too disparate to make patterns out of, but we’ve found that isn’t actually the case! For example, when we started to define our sub-atoms text styling for Gilroy Interface we found that almost all of our interface components were already using the same text styling. Whether this was done intentionally or subconsciously, it’s not a coincidence. So, what I’m saying is, people DO think this way! (Life is full of contradictions pal, you better get good at dealing with it.)

Later gator

Thanks everyone! Now I’m going to curl up in a corner and go into denial that Invison Studio and Design System Manager may be about to blow all of this out of the sky, okay?