When I wrote about the process of designing in parallel, I wrote a phrase that I instantly identified as being an iceberg phrase¹:

They’re just names at this point. On a sheet of paper.

The iceberg below this phrase is the importance of naming components and why it’s so important that the entire team speaks the same language.

One of the biggest reason for any team to consider a pattern library is simply documentation. Having everyone on the team onboard with what a button looks like, for example. And how it should be used.

These are very important reasons for a pattern library to exist. But a major one, and you might not think this at first, is that pattern libraries can dramatically increase the efficiency of different teams working together, simply, because it unifies the language that the two teams are using.

When both teams agree that this whatsit is called a bingobrick instead of a catchercrane you can save a lot of time by cutting out the “No, not that bingobrick, this one.” We resort to finding a visual example: “See here, it looks like this” or explaining where the pattern shows up: “That bit when you click on the Pricing page and the thingy flies out”.

This all sounds extremely silly when talking about bingobricks and catchercranes but it suddenly isn’t when you’re talking about carousels, sliders, slideshows and galleries. Or thumbnails (as in, navigation) versus thumbnails (for a modal video). Or lightboxes and modals. Or paddles, and gallery navs.

Were the gallery nav the forward and backards arrows?

“No, those are the paddles”.

Oh, so they are the thumbnails?

“Well no, thumbnails are for videos, but yes, it’s the strip below a gallery showing all the slides.”

Hang on! It has slides, but it’s not a slideshow?

“Well, we call that a carousel…”

And those are almost all well known names for components. Most of them are descriptive and still we’re confused.

It gets worse when your design team invents a pattern that’s implemented by your developer team, but they never talk about the component outside the context of a page build. The design team are calling the component one thing (a made up, non-industry standard name) while the developer team have christened it something completely different.

Speaking the same language is one of the greatest, and easiest, wins for your teams’ collaboration. All it takes is pointing at things, writing those names down, and agreeing on them.

There are more articles on this series:

• Together: where I muse about how design and developer teams can work better together, by building great tools around their process.
• Not just pattern libraries: where I explain that those tools are more than just making a pattern library. And what that means.
• The process of design: where I talk about how designing in parallel results in great efficiency wins during the design process.