Nobody browses a pattern library the way its author organized it. Clients open the inserter with a job in their head — “I need a pricing section” — and either your categories answer that sentence or they scroll past everything you built. Categories are the interface to your library, and they deserve the same care as the patterns.
Name the job, not the technique
“Heroes,” “Pricing,” “Testimonials,” “Calls to action,” “Galleries” — these work because they finish the sentence I need a…. “Media & text variations,” “Flex layouts,” and “Misc” do not. If a category name describes how a pattern is built rather than what it is for, rename it.
Keep the list short enough to scan
Five to nine categories is the comfortable range. Below that, categories stop narrowing anything; above it, the list itself needs a search box. A category with one pattern in it is a hint to merge; a category with thirty is a hint to split — usually along audience lines (“Heroes” into “Heroes” and “Page headers”) rather than visual ones.
One pattern, one primary home
Patterns can carry several categories, and cross-listing is fine — but every pattern should have one category where it obviously belongs. If you cannot name a pattern’s primary home, the pattern is probably two patterns.
Categories as the unit of sharing
On patternbuilderwp.com, categories do one more job: they are what you share. Your cloud library is private by default, and you publish by flipping a whole category public — “Starter Heroes” goes out to the community while “Client drafts” stays yours. That model only works when categories are coherent, which is one more reason to organize by job: a category that answers a real sentence is a category worth publishing.
Ten minutes of renaming is the cheapest usability upgrade your pattern library will ever get.