The Door Handle Is Not for Everyone

I kept seeing the same mistake in paper after paper. Someone would list features, call them affordances, and move on. The collaboration feature? That is an affordance. The dashboard? Affordance. The notification system? Affordance. By the third paper I read this way, the word had lost all meaning. If everything is an affordance, nothing is.

The mistake is understandable. "Affordance" sounds like it means "what the system can do," which is close to "feature." But James Gibson coined the term in 1979 to mean something specific: an action possibility that exists in the relationship between an organism and its environment. A door handle affords pulling for a human hand. It does not afford pulling for a dog. The affordance sits in the relationship between the actor and the object, not in the object alone. The handle is not for everyone.

Markus and Silver (2008) brought this relational logic into information systems and sharpened it. They drew a hard line between three concepts that most IS research muddles together. Technical objects are the material artifacts with no inherent purpose, the software, the interface, the code. Functional affordances are what the artifact enables for a specified user group with a specified goal. Symbolic expressions are what the artifact communicates about identity and status. The insistence on actor and goal is not decoration. It is the theoretical core. The same technical object affords different things to different actors with different goals. A generative AI tool affords content generation for faculty preparing course materials. The same tool affords assessment vulnerability for academic integrity officers. If you leave out the actor and the goal, you have not named an affordance. You have named a feature.

I think this is the single most common conceptual error in IS research today. Papers claim that a technology "affords collaboration" or "affords transparency" without saying for whom and toward what end. Markus and Silver (2008) explicitly warned against this. A feature without a specified actor-goal pair is merely a technical object property, not an affordance. The distinction matters because it decides whether your theory can explain differential outcomes. If affordances are just features, then every organization that adopts the same software should get the same result. They do not. The relational definition explains why.

Zammuto et al. (2007) took affordances to the organizational level. They named five affordances of IT that bridge material properties and organizational action. Visualizing makes invisible organizational processes visible through data dashboards and process maps. Innovation enables new ways of working through digital prototyping and rapid experimentation. Virtual collaboration enables distributed teamwork through shared workspaces. Mass collaboration enables large-scale collective action through wikis and crowdsourcing platforms. Simulation enables organizational learning through what-if scenario modeling. These are affordances, not features, because they specify the organizational action that becomes possible. But Zammuto et al. also made clear that affordances are relational properties that emerge from the interaction between organizational actors and IT artifacts, not inherent properties of the technology itself. A dashboard does not visualize anything until a manager with a specific goal interacts with it in a specific organizational context.

This is where I want to push against the way most product reviews and technology blogs talk about software. Consider Notion. For a solo knowledge worker managing a research pipeline, Notion affords flexible knowledge organization, linking across projects, and rapid restructuring of a personal workflow. For a team of ten consultants forced to adopt it by management mandate without training, the same tool affords confusion, duplicated databases, and quiet resentment. The features are identical. The affordances are not. The actor, goal, and context are different, so the action possibilities are different. Calling Notion an "affordance-rich tool" without specifying for whom and for what is analytically empty.

Or consider Instagram Stories. For a Gen Z creative, Stories afford spontaneous self-expression, rapid visual storytelling, and social connection through ephemeral content. For a corporate communications executive assessing brand risk, the same feature affords surveillance anxiety, loss of message control, and the constant pressure of real-time reputation management. One feature, two affordances, depending on who is holding the phone and what they are trying to do. The symbolic expression also shifts. For the creative, posting Stories signals cultural fluency and social belonging. For the executive, mandating Stories signals to stakeholders that the brand is "modern," regardless of whether the Stories actually reach anyone. Markus and Silver (2008) would separate these into functional affordance and symbolic expression, and the separation is not academic trivia. Conflating them is how organizations end up measuring "engagement" without knowing whether anyone is actually doing anything meaningful with the tool.

Hospital EHR systems make this even sharper. An experienced nurse who has used the same EHR for five years navigates patient charts, medication orders, and care timelines with practiced efficiency. That EHR affords speed and coordination for her. A first-year resident, assigned to the same system on day one of a clinical rotation, faces a different reality. The same interface affords fear, slowdown, and the risk of medication errors because the action possibilities depend on the actor's prior knowledge, their goal in that moment, and the organizational context shaping how they are allowed to use the system. If you evaluate the EHR by feature count or system uptime, it looks fine. If you evaluate it by affordances for different actors with different goals, the picture fractures. And fractured pictures are the ones that matter.

Leonardi (2011) adds a temporal dimension that the feature list cannot capture. Human agency and material agency imbricate, meaning they interlock recursively over time. Neither one determines the other. As people use technology, they develop workarounds and innovations that change the role of the technology. As the technology is updated, it changes what people can do, which may change their practices. The recursive imbrication avoids the structural determinism sometimes attributed to structuration theory. An affordance that exists today may not exist tomorrow because the actor's goals shifted, the technology was redesigned, or the organizational context changed. When I see a product manager claim that a new feature "unlocks" a new affordance, I want to ask: for whom, doing what, in which context, with what outcome? Without those four answers, the claim is marketing, not theory.

Melville (2023) sharpens the specification even further. An affordance claim needs five elements: the actor, the action possibility, the machine or entity, the environment, and the outcome. An action possibility does not guarantee perception, enactment, or positive effects, because organizational context can block any of these steps. A feature in the interface does not mean anyone will notice it. Someone noticing it does not mean they will act on it. Acting on it does not mean the outcome will be positive. Each step is its own question, and the affordance framework forces you to ask all of them.

The biggest practical lesson I take from this literature is also the simplest. Before you call something an affordance, name the actor, name the goal, name the artifact, name the context, and name the outcome. If you cannot do that, you are probably just listing features. Features matter, but they do not explain differential outcomes. Affordances do, but only when they are properly scoped. The door handle is not for everyone, and the sooner IS research stops pretending otherwise, the sooner we can stop writing papers that list features and call it theory.

I keep thinking about what it means that the same technology can be a toy for one person and a lifeline for another. The question is never just what the technology can do. The question is what it can do for whom, toward what end, in which context, and with what result. When we mistake features for action possibilities, we end up measuring adoption instead of use, because counting logins is easier than specifying who is doing what and why. That error cascades. It shapes how we design systems, how we evaluate them, and how we theorize about them. Affordance theory, done right, is also the corrective to the IT artifact identity crisis: if you cannot remove the artifact from your explanation without the explanation falling apart, you have actually theorized the technology, not just used it as a setting.