When reviewing patterns in a collaborative setting, I’ve frequently found myself in interesting discussions about whether a pattern deserves to be a pattern.

Here’s an example: let’s say you’ve designed a splashy-looking hero image. (Nice work, by the way. It looks very splashy.) Let’s also say its scope is fairly limited: perhaps it’s being used on a small number of pages, or it’s tied to one specific section of your website. In other words, it’s generic enough to be a pattern, but it’s not a widely-used one.

As you might have guessed, this is a dangerous place for a pattern to be. If a pattern feels a little idiosyncratic, that should always prompt us to ask: should your team keep the pattern, or remove it?

Thing is, there’s no single, easy answer to that question. Every pattern is different, and each pattern’s value is variable. Maybe we’ll drop that pattern altogether; maybe we’ll combine it with another, similar pattern to make a new, more reusable alternative. And generally, this is the path we’ll take with these almost-patterns: we’ll make them obsolete. But. But! Sometimes, that pattern has to exist. Often, that pattern is tied to a specific product, or to one particular line of business. If that’s the case, it has to live in our pattern library.

In the design pattern workshops I’ve run, this is an issue that comes up a lot. How do you name and document patterns that have limited use?

Let’s take another look at your splashy-looking hero image. (Again: real nice work with the splashiness.) Assuming we’ve decided that it’s valuable to your business, what do we name it? Simply calling it hero probably wouldn’t work, because your system likely has a more generic hero pattern. More specific names like featured hero or alternate hero can easily become unhelpfully generic, as they don’t really describe the intended use of the pattern.

In my experience, most folks dealing with these limited-use patterns will explicitly tie its name to where and how the pattern’s used. For example, if that hero belongs to a mutual fund product, they might call it mutual fund hero; a logistics department-specific hero, logistics hero.

Personally, this feels like a fine, sensible approach. But I also think these patterns are most effective when they’re seen as having a short shelf life.

Here’s how I think about it:

A graph with two intersecting axes. Horizontal axis ranges from “Presentational names” on the left, to “Functional names” on the right. Vertical axis ranges from “Product-specific patterns” on the bottom, to “Generic and reusable patterns” up top.

Broadly speaking, patterns can be highly reusable, or they could be tied to a specific section of your site. At the same time, the names of those patterns can be fairly functional (“product title”; “profile avatar”), or they can be more presentational. (Think “scrolling table” or “image thumbnail, square crop”.)

If we’re talking about how valuable a given pattern will be to your design system — and, by extension, to your entire organization — we could plot out something like this:

A graph with two intersecting axes. “Low value patterns” is plotted in the bottom left, between “Product-specific patterns” and “Presentational names”. “High value patterns” is plotted in the top right, between “Generic and reusable patterns” and “Functional names”.

In other words, when we’re talking about design patterns, I think it’s safe to say that generic is better than specific. As a result, I generally consider it (ugh) a best practice to define patterns that trend toward the upper right quadrant. Those patterns would be more product-agnostic, and also defined/named according to their function. This feels like the sweet spot to me, and where you’ll generally find the “high value” patterns.

With that said, there’s nothing wrong with a “low value” pattern. In certain cases, and if there’s a proven need for it, it’s fine for a pattern to be tied to specific product, and for its name to reflect that association. But: I think there’s a tax for defining that pattern. Specifically, if you’re going to introduce a pattern of limited use, then your team should aim to replace it with a reusable, higher-value pattern as soon as possible. When we design a new pattern, we ask ourselves if it really deserves to exist in our design system — but also, we should always ask ourselves if it can replace some of those lower-value patterns we’ve created, too. Over time, our patterns should hopefully move from the bottom left corner, up toward the top right.