Using a Pattern Library

That exact question has been answered thousands of times, tested against millions of people, and settled into a shape that works. Somewhere in that shape is the answer to whether they should be signed in automatically, which nearly everybody gets wrong in the same direction.

Reaching for the settled shape is not a shortage of imagination. Rebuilding a checkout from scratch does not make a product original. It makes every customer relearn something they already knew, and it spends the invention budget on the one part nobody wanted surprising.

The topic that follows is a library of those shapes, twenty-nine of them, from authentication to closed captions. This module is how to read it. What a pattern is, where the idea came from, and how it differs from a guideline and a component. Then when to break one, and how to notice that one has expired.

Anatomy of a Pattern

Every pattern library, in software or anywhere else, writes its entries to roughly the same shape. Knowing the shape lets you read any of them, including the ones written before screens existed.

The Six Parts

An entry that is missing one of these is harder to use than it looks.

The name, which is what lets a team say breadcrumbs and mean the same thing. The problem it answers, stated as somebody's difficulty rather than as a component. The context in which it applies. The solution, described as behavior and structure rather than pixels. The trade-offs, meaning what it costs and who it costs it to. And the examples, which are how you check that your reading of the words is right.

Most libraries add a seventh, the related patterns, since the alternatives are usually more useful than the entry itself when the entry turns out to be wrong.

The Two People Skip

Context and trade-offs are the parts that decide whether the pattern is yours to use, and they are the parts that get skimmed.

The context is the set of conditions the pattern assumes: a certain size of catalog, a certain kind of person, a device, a frequency of use. Infinite scroll is right for a recency-ordered feed and wrong for a catalog, and that sentence is context rather than opinion. The trade-offs say what you are paying, since every pattern buys something with something else, and a designer who cannot name the cost has not finished reading.

Why the Name Is Load-Bearing

Naming a pattern is what makes it discussable.

A team that can say this is a wizard, and wizards need a way back, has moved a design review from taste to a known shape with known obligations. A team without the vocabulary argues about the screen. Learning the names is most of the value of a library, which is why each module in this topic opens by naming its own parts before giving any advice.

How the Modules Ahead Are Built

Each one follows the same order, so the library reads consistently.

An introduction with the problem in a real scene. An anatomy article naming the parts. One or more articles on the decisions, usually starting with whether to use the pattern at all. And a practical activity that puts it against something real. Read the anatomy article of any module and you can hold a conversation about that pattern, even if you skip the rest.

Pro tip: Next time you use a pattern from any library, write down its context and its trade-off in your own words before you build. If you cannot state the cost, you have copied the shape rather than used the pattern.