Whether I’m designing a new site or auditing an existing one, nearly all my design projects from the last few years have culminated in a pattern library. But in my experience, the biggest challenge of modular design isn’t designing the patterns. It’s everything that comes after that.

(That’s not to say designing in patterns is easy, mind.)

Here’s the inimitable Alla Kholmatova, from her wonderful article on “The Language of Modular Design”:

The biggest challenges around modularity are all the decisions that need to be reached: when to reuse a module and when to design a new one, how to make modules distinct enough, how to combine them, how to avoid duplications with the modules other designers and teams create, and so on. When modularizing an existing design or building a new one, it’s not always clear where to begin.

Generally, I’ve found that’s the biggest challenge for many organizations: not just designing a pattern library, but designing it so that it can be effectively used over time.

To put a finer point on it, a pattern library’s value to an organization is tied directly to how much — and how easily — it’s used. That’s why I usually start by talking with clients about the intended audiences for their pattern library. Doing so helps us better understand who’ll access the pattern library, why they’ll do so, and how we can design those points of contact.

I should probably note that many others have advocated for this, and for quite some time. But for my part, I’ll say I’ve found that it’s useful to talk with clients about the library’s audiences in terms of consumers and contributors: namely, understanding who’ll be accessing and using the patterns inside a design system; and who will add, change, or remove patterns from it. In early client meetings, I might kick off a discussion that revolves around these questions:

  1. Who are the contributors to the pattern library?
  2. How will each contribute to it?
  3. Who are the consumers of the pattern library?
  4. How will each get patterns out of the pattern library?

Now, there are a lot of other questions that follow from these. And in many cases, there’ll be a high degree of overlap between the consumer and contributor columns. For example, at most organizations, a design team is often adding new patterns to the design system, and referencing patterns as they ship new products; as a result, they’ll appear on both lists.

In my practice, the main benefit I’ve seen in this consumer/contributor framework is it helps organizations understand that not every user of a pattern library is human. If you’re creating a living, integrated style guide, perhaps one product might request patterns directly via an API, while your website’s CMS might pull modules into its templates through some other behind-the-scenes process. And it’s entirely possible that these systems could contribute pattern changes back to the library, too.

After all, a pattern library isn’t necessarily just for front-end developers. A more granular understanding of who — or what — will access your pattern library can better inform its design, ensuring it’s used by as many people — or products — as possible.

(Apologies and thanks to Mandy Brown for the title of this post.) (But mostly apologies.)