A Place to Wait

conceptual-metaphor Architecture and Building → Software Abstraction

Categories: software-engineering systems-thinking

What It Brings

Alexander’s pattern #150 observes that whenever people must wait — at a doctor’s office, a bus stop, a theater lobby — the quality of that experience depends on whether the waiting space was designed with care or treated as an afterthought. A good waiting place acknowledges the wait, provides comfort, and communicates progress. Software is full of waiting: loading screens, queue positions, buffering states, spinners. The mapping asks: have you designed a place for your users to wait, or do you just make them stare at a blank screen?

Key structural parallels:

Waiting is inevitable; the experience is designed — Alexander’s insight is not that waiting should be eliminated but that it should be accommodated. A well-designed clinic lobby has comfortable chairs, reading material, and a visible queue number. A well-designed loading state has a progress indicator, a skeleton screen, and something to look at. The metaphor frames UX loading states as architectural hospitality.
The waiting place communicates status — a good waiting room tells you where you stand. “You are third in line.” “The doctor is running 15 minutes late.” Software progress bars, queue position indicators, and “estimated time remaining” displays are the digital equivalent. The architectural metaphor demands that the wait not be opaque.
The waiting place is a transition zone — architecturally, a lobby is between outside and inside. A loading state is between requesting and receiving. Both are liminal spaces that mediate the transition from one state to another. The metaphor frames buffer states as architectural thresholds rather than engineering defects.
Neglected waiting spaces breed anxiety — a bare hallway with no chairs or signage makes waiting feel longer and more uncertain. A spinner with no progress information does the same. Alexander’s pattern argues that the emotional quality of the wait is a design responsibility. Applied to software, it makes “the loading experience” a first-class design concern.
Waiting rooms have capacity limits — a lobby that seats twenty can’t serve a hundred. Queues, buffers, and connection pools have capacity limits too. The architectural metaphor imports the idea that the waiting infrastructure itself needs to be designed for expected load.

Where It Breaks

Architectural waiting rooms are physical spaces; software waits are temporal states — you can walk around a lobby, sit down, look out a window. You can’t “inhabit” a loading screen. The spatial metaphor suggests presence and agency where the user actually has neither. A person in a waiting room can leave; a user watching a spinner can only wait or cancel.
Alexander’s waiting places assume human company; software waiting is solitary — a clinic lobby has other patients, a receptionist, maybe a coffee machine. The social dimension of shared waiting — commiseration, small talk, seeing others in the same situation — is absent from software loading states. The metaphor imports a communal experience that is actually isolating.
Physical waiting has environmental quality; screens have pixels — Alexander cares about natural light, comfortable seating, connection to nature. The best a loading screen can offer is a well-designed animation. The metaphor invokes richness of experience that the medium can’t deliver.
Waiting rooms don’t pretend the wait isn’t happening; software often does — a lobby doesn’t try to hide that you’re waiting. Software loading patterns sometimes attempt to make the wait invisible (lazy loading, optimistic UI), which is a fundamentally different design strategy than creating a good waiting place. The metaphor doesn’t map onto the “pretend there’s no wait” approach.
The metaphor can justify slow systems — Alexander’s pattern assumes waiting is inevitable. Applied naively to software, it can become an excuse for not optimizing: “let’s design a better loading screen” instead of “let’s make it load faster.” The architectural metaphor can redirect engineering effort toward decoration of a problem rather than its elimination.
Queues in software are invisible; queues in architecture are spatial — a line at the post office is visible and self-organizing. A message queue has no spatial presence. The metaphor suggests that making queues visible is natural, but in software, visibility must be deliberately constructed.

Expressions

“Loading state” — a temporal condition framed as a spatial location
“Waiting room pattern” — explicit adoption of Alexander’s metaphor for UX design
“Queue position: you are number 47” — the architectural queue number applied to digital waiting
“Skeleton screen” — a loading placeholder shaped like the final content, the architectural blueprint of the finished room
“Buffer” — literally a cushioning space, a place to absorb the shock of timing mismatches
“Please wait while we prepare your experience” — the hospitality language of the waiting room applied to software

Origin Story

Christopher Alexander’s pattern #150, “A Place to Wait,” appears in A Pattern Language (1977). Alexander observed that transit stops, clinics, and government offices often forced people to wait in inhospitable non-places — bare corridors, exposed sidewalks, plastic chairs under fluorescent light. The pattern argues that wherever waiting occurs, the environment should be designed to make it comfortable and informative.

The pattern found new life in UX design during the 2010s, as web and mobile applications increasingly confronted the problem of latency. Luke Wroblewski’s advocacy for skeleton screens and progressive loading drew implicitly on Alexander’s insight: the wait is unavoidable, so design for it. The metaphor remains active in UX discourse, where “loading experience” is a recognized design specialty — a direct descendant of Alexander’s argument that waiting deserves architectural attention.

References

Alexander, Christopher. A Pattern Language (1977), Pattern #150: A Place to Wait
Wroblewski, Luke. “Mobile First” (2011) — loading state design for mobile constraints
Nielsen, Jakob. “Response Times: The 3 Important Limits” (1993) — the cognitive basis for why waiting feels long