Moon
The moon has no light of its own. It reflects the sun, presents different faces across a predictable cycle, influences systems through gravitational pull rather than direct illumination. Where the sun dominates through energy output, the moon shapes through relationship—to the sun, to the earth, to tidal patterns. Every reflected element in a design system serves this function: it has no inherent authority but derives meaning from what it references. The dependency component, the themed variant, the localized instance—all are lunar. They wax and wane based on their source's state.
The moon shines by reflecting solar light. It has no internal luminescence, only borrowed radiance. Yet this reflection serves essential functions: illuminating the night, marking time, creating tides. The derivative source is not a lesser source but a different kind of source.
Design components that derive from core elements exhibit lunar properties. A themed button reflects the base button component. A localized string reflects the source language string. A responsive breakpoint reflects the base layout. These derived elements have no independent existence—change the source and they change—but they serve contexts the source cannot reach directly.
The moon's phases reveal an important property of reflected systems: they present different faces depending on geometry. A full moon (complete reflection) versus a crescent (partial reflection) demonstrates that derivative elements need not mirror their source exactly. The relationship can be complete or partial, direct or oblique, depending on the angle of derivation. A component theme might reflect all properties or only colors. The degree of reflection is a design choice.
The moon cycles through phases on a fixed schedule: new, crescent, quarter, gibbous, full, then back. This periodicity is predictable, reliable, and independent of human observation. The cycle continues whether noticed or not.
Design systems contain similar cycles, though often unacknowledged. Components move through phases of development, deployment, maintenance, and obsolescence. New components enter the library (new moon), gain partial adoption (crescent), reach half the team (first quarter), near-complete implementation (gibbous), full integration (full moon), then decline through the same phases in reverse.
Recognizing these phases allows appropriate intervention. A new-moon component (just created) needs different support than a full-moon component (widely adopted). The new needs documentation and evangelism; the full needs only maintenance. Treating all components identically ignores their phase in the cycle. The moon teaches that state is temporal—what is full now will wane, what wanes may wax again.
The moon affects earth through gravity, not light. Tides rise and fall based on lunar position. The influence is invisible but measurable, subtle but powerful, indirect but real. The moon shapes systems it does not illuminate.
In organizations, certain roles and artifacts exert lunar influence. They don't make decisions directly but shape the context in which decisions occur. Design critique influences work without dictating outcomes. Style guides shape choices without enforcing them. The influences is gravitational—pull rather than push, attraction rather than command.
Gravitational systems create problems when the pull becomes too strong or too weak. A moon too close creates excessive tides that destabilize coastlines. Critique that dominates stifles exploration. A moon too distant exerts no meaningful pull. Critique that's ignored provides no value. The appropriate distance must be calibrated: close enough to influence, far enough to allow autonomy.
The moon is tidally locked to earth, always showing the same face. The far side exists but remains hidden from terrestrial view. This asymmetry emerges from gravitational interaction over time. The system settles into a stable configuration where one side perpetually faces the primary body.
Component libraries often exhibit tidal locking. The public API (the face shown to users) stabilizes while implementation details (the far side) remain hidden and can change freely. This is deliberate architectural design: lock the interface, keep the internals flexible. But tidal locking also happens unintentionally when certain use cases dominate.
A component designed for one primary use case becomes tidally locked to it. The visible face—the documented patterns, the default configurations—serves that use case. Other use cases become the far side: possible but undocumented, supported but not showcased. The component has locked its visible face to the dominant gravitational pull of its primary user. Breaking this lock requires significant energy expenditure.
Moonlight is weaker than sunlight but sufficient for certain activities. Navigation by moonlight, nocturnal ecosystems, the romance of lunar illumination—all depend on this secondary light source. The moon doesn't replace the sun; it provides light when the sun doesn't.
Design systems need secondary sources for contexts the primary source doesn't address. The main design system serves web products; a secondary system serves mobile apps. The primary component library handles common patterns; a secondary library addresses specialized domains. These secondary sources don't compete with primaries; they serve different temporal or contextual needs.
The risk is creating too many secondary sources, fragmenting the system into incompatible satellites. Multiple moons create complex tidal patterns that can destabilize the whole. The designer must determine when secondary sources are necessary (serving genuinely distinct contexts) versus when they're proliferation (creating unnecessary complexity). One moon stabilizes earth's axis. Multiple moons of comparable mass create chaos.
During solar eclipse, the moon blocks the sun. Despite being far smaller, the moon can completely obscure the solar disk from earth's perspective due to geometric coincidence: the moon is 400 times smaller than the sun but 400 times closer. This accidental alignment creates perfect occlusion.
In design systems, small elements can block access to large elements through similar geometric accidents. A modal dialog (small) blocks the entire application (large). A loading spinner obscures complex content. A tooltip covers interactive elements. The blocking element is structurally minor but positionally dominant.
Eclipse teaches that position matters as much as size. The moon is tiny compared to the sun, but from earth's position it can create total darkness. A minor UI element in the wrong position creates major disruption. The designer must consider not just the element's intrinsic properties but its relationship to the observer's position. What seems small from the system's perspective may be totally occluding from the user's perspective.
The moon cannot orbit independently. Its path is determined by its relationship to earth and sun. Remove either primary body and the moon's orbit becomes unstable. The moon exists within a system of dependencies; it cannot be extracted and remain meaningful.
Design components have similar dependencies. A themed variant depends on the base theme and the component being themed. Extract the variant from its dependency chain and it becomes nonsensical—colors without context, behavior without structure. Some components can exist independently; others are fundamentally relational.
This suggests different strategies for different component types. Independent components can be extracted, reused, transported to different contexts. Dependent components must travel with their dependencies or recreate them in the new context. Trying to use a deeply dependent component independently is like trying to maintain the moon's orbit without earth. The system requirements are baked into the element's nature.
The moon's phases are not arbitrary but geometric necessities. The amount of illuminated surface visible from earth depends on the angle between sun, moon, and earth. The phases are not internal to the moon but relational properties of the three-body system.
Interface states exhibit similar relational properties. A button's disabled state is not intrinsic to the button but emerges from its relationship to application state. A form field's validation state depends on its relationship to user input and validation rules. The "phase" shown by any given component is a function of its position in a larger system.
Designing for phases means recognizing that states are relational. The component doesn't have states; it exhibits states based on its context. This shifts design thinking from "what states does this component have?" to "what relationships determine this component's state?" The moon waxes and wanes not because it chooses to but because its geometric relationship to sun and earth changes. Components transition between states not arbitrarily but based on systematic relationships to data, user actions, and application context.