Affordances: How Structure Shapes What's Possible

Core Concepts

1. What an affordance is — and what it is not

Gibson's foundational formulation defines affordances as relational properties that emerge from the interaction between an environment and an organism's capabilities. An affordance is neither a purely objective feature of the environment nor a purely subjective perception. It cuts across the subject-object dichotomy: it points simultaneously to the environment and to the observer.

"The affordances of the environment are what it offers the animal, what it provides or furnishes, either for good or ill." — James J. Gibson, The Ecological Approach to Visual Perception

This matters immediately. When we say "the architecture is complex," we are not describing a property of the codebase in isolation. We are describing a relational fact: complex for whom, with what capabilities, working toward what goal. Complexity, navigability, deployability, modifiability — these are all affordances, not attributes.

Contemporary IS research extends this: affordances emerge from three-way interactions between actor capabilities, user goals, and technology features. The same technology affords different actions in different organizational contexts because the relational configuration differs. A microservices architecture read by a senior distributed systems engineer affords rapid reasoning about failure modes. The same architecture read by a newcomer may afford nothing beyond confusion.

2. The relational structure: actor, environment, capability

From Gibson's foundational work, the example is concrete: a set of stairs 1 meter high does not afford climbing to a crawling infant, may afford resting to a tired adult, and affords passage to another floor for a person seeking to traverse the building. The same physical structure; three different actors; three different affordances.

Affordances must be understood as properties of the animal-environment system as a whole, where both organism and environment contribute equally to determining what actions are possible. You cannot fully specify an affordance by describing only the object, or only the actor.

In software: a monolithic codebase affords seamless holistic refactoring to a solo developer because all components exist within a single deployment unit. The same monolith constrains a large distributed team because coordination overhead scales with team size. Microservices invert this: they afford independent deployment and team autonomy to a distributed team but introduce coordination overhead that burdens a solo developer. The architecture did not change. The actor did.

Affordance perception is also body-scaled — in physical terms, whether a doorway is passable is perceived relative to the ratio between the doorway's width and the observer's body width, not in absolute measurements. The software analog is capability-scaling: whether a distributed tracing system "affords debugging" depends on the developer's experience with distributed systems, not on the system's feature list.

3. Potential vs. actualized affordances

Gibson distinguished between potential affordances and actualized affordances. The environment offers possibilities for action. The actor has agency to select which possibilities to realize.

Strong and Volkoff make this distinction precise for IS contexts: affordances as potentials persist and have durability — they describe what could be done. Actualization is what is done, by a specific actor, in a specific context, for a specific goal. The relationship is not deterministic: the same affordance can remain unactualized, or be actualized in multiple different ways.

Fig 1

An affordance becomes actionable only when it is simultaneously perceived, valued, combined with other affordances, situated within social norms, and actualized through intentional action. Each is a distinct step — and each is a potential failure point.

The practical consequence: a system that provides a potential affordance but makes it unperceivable — through poor naming, hidden dependencies, absent documentation — has not delivered that affordance to the team working in it.

4. Perceived vs. actual affordances: Norman's contribution

Donald Norman adapted Gibson's concept for design contexts, introducing the critical distinction between real affordances and perceived affordances. For design, what matters is what users perceive they can do, not what is objectively possible. Perceived affordances result from mental interpretations based on past knowledge, experience, and design conventions — not from an accurate reading of capability.

Norman's insight shifted attention to the communication problem: a system may have rich actual affordances that remain invisible if design conventions, naming, and feedback do not surface them. Perceived affordances are shaped by visual cues, auditory and haptic feedback, prior experience with similar systems, and explicit conventions.

In UI design, this produces a practical taxonomy of affordance types:

• Explicit affordances: labeled, clearly signaled (a button that says "Delete")
• Hidden affordances: only discovered through interaction or exploration
• Pattern affordances: legible because the actor has seen the pattern before (a trash-can icon)
• Metaphorical affordances: understood through mapping from a known domain

For software architecture, the same taxonomy applies. An API method named processPayment() signals something; execute() signals almost nothing. A service boundary with a well-typed contract exposes explicit affordances. A shared mutable database accessed by six services hides almost all its constraints until something breaks.

5. Cognitive affordances and cognitive load

Cognitive affordances are the design features that help agents notice or acquire knowledge about action possibilities. They are distinct from functional affordances, which enable goal achievement. Cognitive affordances make visible what is possible; functional affordances make possible the achievement itself.

Clear module boundaries, explicit dependency graphs, and transparent interfaces create cognitive affordances for developers: they make perceivable what modifications are safe, what can be deployed independently, what is owned by whom.

Well-designed affordances reduce cognitive load by making action possibilities immediately perceptible. Conversely, poorly designed or hidden affordances — undocumented coupling, implicit contracts, implicit ownership — require developers to perform cognitive inference instead of direct perception. The cost is not just friction; it is error rate and decision latency.

6. False affordances: structure that misleads

Architectures can create false affordances: structure that appears to afford one action but actually constrains it or affords something else. A poorly documented API may appear to afford certain modifications that are actually unsafe due to hidden shared state. A design pattern applied mechanically — microservices without proper service boundaries — can produce a structure that looks modular but possesses high coupling disguised as independence.

False affordances are a specific failure of Affordance-Based Design, which requires designers to address not just intended affordances but also unintended and negative affordances — the possibilities the structure creates but should not. A safety-critical system that does not suppress dangerous affordances has a design deficiency even if all intended affordances work correctly.

7. Social and temporal dimensions

Affordances do not exist in a static snapshot. Research on social and cultural affordances shows that affordances carry normative dimensions: they do not only indicate what actors can do but also what they should or should not do in shared social worlds. Cultural norms shape which affordances are perceived and which are acted upon.

The temporal dimension matters for engineering organizations: team norms, practices, and shared knowledge evolve. An architectural pattern that affords rapid parallel development for a team that has internalized deployment discipline may afford chaos for a team that has not yet established those practices. The affordance is relational with respect to time as well as capability.

Across organizational contexts, affordance perception operates through mediated action: organizational practices, team norms, and cultural knowledge mediate how actors perceive and actualize the action possibilities in a system. Two teams working in identical codebases, with different operational cultures, will actualize different affordances from the same potential.

8. Affordances are multilevel

Contemporary IS frameworks address affordances at individual, team, and organizational levels. A technology that affords an action for individuals may not enable team-level affordances for coordinated action. Team affordances may not translate into organizational capability changes unless organizational processes facilitate the bundling of individual actions into collective outcomes.

This has direct implications for system design: you cannot design only for individual developer affordances and assume team affordances follow. A system that is legible to individual engineers may still not afford the coordination patterns a team needs — shared observability, clear ownership signals, explicit deployment independence.

Affordance-Based Design operates on the principle that design is the specification of structure to produce desired affordances and suppress undesired ones. At the organizational level, this means designing not just systems, but the team structures, processes, and norms that translate individual system affordances into organizational capability.

9. Affordances are not functions

Affordance and function are distinct concepts and are not interchangeable. Functions describe intended transformations of input states to output states, independent of form. Affordances describe relational possibilities between an actor and an artifact that are fundamentally dependent on form and structure.

A function-based view of a service boundary asks: what does this service do? An affordance-based view asks: what does this boundary make possible or impossible for the teams on either side of it? The first question produces a specification. The second produces a map of behavioral gravity — what teams will tend to do, and why.

API affordances are the perceivable action possibilities that an API makes available to developers. They are shaped by interface structure, naming conventions, type signatures, and method patterns — not by what the implementation does internally. A well-designed API affords correct usage through its surface; a poorly designed one requires developers to internalize implementation details before they can use it safely.

10. Emergence through use and appropriation

Affordances are not static properties determined at design time. They emerge dynamically through interaction and use. Affordances can be sequential: one action creates conditions for subsequent affordances to become perceivable. Communities collectively discover affordances through shared use, experimentation, and circulation of knowledge about possibilities. These emergent affordances often differ substantially from designer intentions.

DeSanctis and Poole's Adaptive Structuration Theory captures the organizational form of this: users and organizations do not simply implement technology as designed but actively appropriate — adapt, resist, or transform — technological structures to align with their own goals and contexts. The operative technology is ultimately determined by patterns of appropriation, not by inherent system features.

This is not a failure mode to be prevented. It is the normal mechanism by which systems acquire meaning in organizational practice. The implication for designers is to create affordance-rich structures — ones with multiple possible uses and interpretations that remain flexible as needs evolve — rather than attempting to prescribe a single usage pattern that will be overridden anyway.

---

Worked Example

Scenario: Two teams, one shared data store

Consider a platform with three services: OrderService, InventoryService, and NotificationService. All three read and write to a single shared PostgreSQL schema. The schema was designed when these were one service.

Affordance analysis from the team perspective:

The shared schema potentially affords:

• Cross-service data joins without network calls
• Atomic transactions across logical domains
• Fast iteration when business rules change

The shared schema actually affords to a small single team:

• Rapid exploration and modification (everything is accessible)
• Debugging via direct queries

The shared schema actually affords to three teams working in parallel:

• Contention over schema migrations (one team's change breaks another's deployment)
• Invisible coupling (service A can read service B's internal state — it is possible, so it happens)
• False affordance of independence (the services appear independent as network services, but are tightly coupled at the data layer)

Perceived vs. actual:

A new engineer joining InventoryService sees three distinct services with separate repositories and deployment pipelines. The perceived affordance is independence — three teams can move separately. The actual affordance is high coupling, because the shared schema means schema changes require coordination. The false affordance is discovered at the moment of the first conflicting migration.

Cognitive affordance failure:

The coupling is hidden. There are no explicit dependency declarations between the services at the schema level. Developers must build a mental model of the shared schema to understand what is safe to change. This is a cognitive affordance failure: action possibilities are not directly perceivable from the structure. The result is elevated cognitive load and higher error rates.

Redesign in affordance terms:

Each service owns its data. InventoryService publishes domain events; OrderService subscribes. The boundary now explicitly affords:

• Independent deployment (actual)
• Independent schema evolution (actual)
• Asynchronous coordination (actual, now visible through the event interface)

The false affordance (apparent independence that hid actual coupling) has been eliminated. The actual affordances now match the perceived ones — which is the goal of cognitive affordance design.

The team dimension:

This change does not automatically translate to organizational affordances. For three teams to actually actualize independent deployment, they also need: per-team deployment pipelines, separate on-call rotations, and a shared protocol for event schema evolution. The technical boundary affords independence; the organizational structures must bundle those individual affordances into a collective team capability.

---

Compare & Contrast

Gibson's affordances vs. Norman's perceived affordances

Dimension	Gibson	Norman
Primary question	What does the environment offer?	What does the actor perceive as possible?
Ontological status	Relational property of organism-environment system	Perceptual/cognitive property of the actor
Design implication	Design to create genuine action possibilities	Design to surface and communicate those possibilities
Risk	Actor may not perceive real affordances	Actor may perceive affordances that do not exist (false affordances)
Level of analysis	Ecological, behavioral	Cognitive, perceptual

Both frameworks are necessary. Gibson tells you what you are designing. Norman tells you whether the actor will perceive what you designed. In software: an API can have excellent functional affordances (it actually does allow what you need) while having poor perceived affordances (the names and types do not communicate what is possible). You need both lenses.

Potential affordances vs. actualized affordances

Dimension	Potential	Actualized
Exists when	Structure is in place	Actor perceives, values, and acts
Durability	Persistent until structure changes	Episodic, context-specific
Measured by	Structural analysis	Behavioral observation
Failure mode	Not perceived / not valued / not socially permitted	Perceived incorrectly (false affordance) or not at all
Design relevance	What you are responsible for creating	What teams actually do with what you created

Affordance vs. function

Dimension	Function	Affordance
Actor-dependent	No — describes transformation regardless of who uses it	Yes — exists relative to a specific actor's capabilities and goals
Form-dependent	No — input/output specification independent of form	Yes — fundamentally dependent on structure and form
Covers static structures	Poorly — chairs have no transformative function	Yes — a chair affords sitting regardless
Design language	Specification, contract	Possibility, action space
Failure mode	Delivered function that nobody can perceive or use	—

---

Boundary Conditions

When affordance thinking becomes less useful

Highly constrained systems. Affordance thinking is most powerful when there is meaningful variation in what different actors perceive and actualize. In a strictly regulated pipeline where every actor must follow a single prescribed procedure, the variation in perceived and actualized affordances collapses. Function-based analysis is more appropriate there.

Novel actors in novel environments. Gibson's principle that affordances are directly perceivable holds most cleanly for actors who have relevant prior experience with similar structures. Affordance perception is mediated by cultural practices, team norms, and prior experience. A brand-new team joining a mature platform may perceive almost none of the affordances that experienced team members perceive easily. Onboarding design must compensate.

Single-actor contexts. Affordance theory's most distinctive contribution is explaining differential behavior — why different actors do different things with the same structure. When there is genuinely only one actor type, affordance analysis still applies but provides less marginal insight than a standard usability analysis.

Affordances cannot substitute for explicit contracts. Perceived affordances can guide behavior but are not legally or operationally binding. A well-named API endpoint reduces misuse; it does not prevent it. For safety-critical interactions, explicit constraints and enforced contracts must supplement affordance design.

The temporal trap

Affordances have a temporal dimension: team capabilities, organizational norms, and actor knowledge evolve. An affordance analysis accurate for a team today may be inaccurate in 12 months. Architecture that affords the right behaviors for the current team may afford different (or wrong) behaviors after significant team turnover, scaling, or reorganization.

This is not a reason to avoid affordance analysis. It is a reason to revisit it — and to design structures that remain affordance-rich as contexts change, rather than structures optimized for a single actor configuration.