Design Pattern

Origin & evolution

The idea comes from architecture. Christopher Alexander's A Pattern Language (1977) proposed that good design recurs as named patterns, each describing a context, a problem, and a proven solution, and that the patterns combine into a language a community can share. Alexander's claim was that this knowledge should be written down and recombined, not rediscovered building by building.

Software adopted the idea twice. First in programming, where Kent Beck and Ward Cunningham experimented with it in the late 1980s and the "Gang of Four" book carried it into the mainstream. Then in interface design, where Jenifer Tidwell, citing Alexander directly, began assembling a pattern language for human-computer interfaces in the late 1990s, her Common Ground collection growing into Designing Interfaces (2005). That book made interaction patterns a standard part of the designer's vocabulary.

The thinking since has split the pattern's two jobs🔨JobUserJob To Be Done: what the user is trying to accomplishView reference →. A pattern as shared craft knowledge lives in books and public catalogues and travels across products. A pattern adopted into a specific design system🧰Design SystemDesign SystemThe root design system entityView reference → becomes a local rule with a status (proposed, adopted, experimental, deprecated) and a documented place to use it. The risk🎲RiskComplianceA risk to the product or businessView reference → Alexander warned about returns in the system context: a pattern applied without its conditions becomes cargo-cult design, the right shape in the wrong situation.

How it works in practice

A team keeps building one-off confirmation dialogs, each worded and laid out differently. They write a design_pattern🧩Design PatternDesign SystemA documented design pattern for "destructive confirmation": category feedback, usage context "any irreversible action such as delete or cancel-subscription🔂SubscriptionSales & RevenueA recurring subscriptionView reference →", and an anti-patterns note warning against using it for reversible actions, where it just adds friction. The pattern records that the confirm button must name the action ("Delete project") rather than say "OK", because a generic label is the documented mis-application. Three months later a new feature⭐FeatureProduct SpecificationA product capability or featureView reference → needs🫀NeedUserA user need, pain, desire, or constraintView reference → to delete a workspace; the designer applies the adopted pattern in minutes, and the dialog matches every other destructive action in the product because they all descend from the same written solution.

Design pattern vs. its neighbours

• Design component🧱Design ComponentDesign SystemA reusable UI componentView reference → is the coded artefact, the actual button or modal in the library. A pattern is the reusable idea; a component is one implementation of it. In the graph, design_component_follows_design_patternDesign ComponentfollowsDesign Patternhierarchy records a component honouring a pattern.
• Design guideline📌Design GuidelineDesign SystemA design usage guidelineView reference → is a rule or principle (always provide an undo for destructive actions). A pattern is a concrete solution shape; a guideline is the constraint🔒ConstraintStrategyA constraint entityView reference → a good pattern satisfies. The canonical anti-pattern is a pattern with no guideline saying when to use it.
• Anti-pattern is the inverse: a solution that looks reasonable and reliably fails. Mature patterns carry their anti-patterns as a property, so the lookalikes to avoid travel with the solution.
• Best practice is broader industry advice. A design pattern is more specific and structured, naming the problem, the context, and the solution, so it can be applied with judgement rather than followed blindly.

In the graph

In the Unified Product Graph, design_pattern🧩Design PatternDesign SystemA documented design pattern is a leaf in the Design System domain of the Experience, Design & Brand region. It has no outbound structural edges; a pattern is referenced, not a container. Its one inbound edge, design_component_follows_design_patternDesign ComponentfollowsDesign Patternhierarchy, lets the coded library point back to the reusable idea each component embodies. The pattern_category, pattern_status, and anti_patterns properties carry Alexander's full insight🔦InsightUser ResearchA synthesised finding from researchView reference → forward: a pattern is not just a solution but a solution with a context, an adoption state, and a record of how it goes wrong.