The Gap Between What a System Can Do and What People Do With It

Two hospitals. Same EHR vendor. Same version of the software. One hospital uses it primarily as a documentation system, capturing what was done after the fact. The other uses it to coordinate care in real time, with team members pulling the same patient record simultaneously and using the alert system to flag deteriorating vitals before anyone calls. Five years in, the outcomes data looks different between the two hospitals, and the IT vendor is tempted to take credit for the second hospital's results while quietly not mentioning the first.

The vendor did not produce those outcomes. The users and their context did. The EHR afforded both uses. Neither was automatic. That is the core argument behind affordance actualization, and I think it is one of the most practically important ideas in IS theory for anyone who has ever wondered why the same system produces such wildly different results across deployments.

The affordance concept I am building on here comes from the IS literature on technology affordances. Markus and Silver (2008) drew the hard distinction between a technical object, the physical artifact, a functional affordance, what the artifact enables for a specific actor with a specific goal, and a symbolic expression, what the artifact signals about identity and status. The critical move is the relational definition: affordances are not properties of the system alone. They exist in the relationship between the system and the actor and the goal and the context. The same system affords different things to different users with different goals.

My study materials confirm Markus and Silver (2008) as local paper evidence, alongside Leonardi (2011), as the core affordance citations in the studyhub library. The Melville (2023) paper in the library sharpens this further: an affordance claim needs a named actor, a named action possibility, a named artifact or environment, and a named outcome. An action possibility that sits in the interface but is never perceived by any user is not an actualized affordance. It is a design choice that went nowhere.

This is the gap that affordance actualization describes. Between the affordance potential that a system makes possible and the affordance actualization that actually occurs, a lot of things can go wrong. Users may not perceive the affordance. They may perceive it but lack the skill to enact it. They may enact it but in a context where the organizational conditions block the beneficial outcome. Leonardi (2011) gives this a temporal dimension: human and material agencies imbricate recursively, meaning that what users do with a system in round one shapes what the system seems to afford in round two. Actualization is not a one-time perception event. It unfolds.

The research implication is that measuring "system use" without asking what affordances are being actualized conflates very different behaviors under one label. Heavy use of an EHR for documentation and heavy use of the same EHR for real-time care coordination are both "high adoption" by any standard usage metric. They produce different outcomes because they are actualizing different affordances. A study that treats them as the same independent variable will find a muddy relationship between adoption and outcome. That muddy relationship is not bad luck. It is the measurement framework failing to capture the relevant variation.

The same argument applies at the platform level. Twitter, which is now called X, was designed for short status updates. It became the dominant medium for breaking news, real-time event commentary, and crisis communication. Instagram was designed for photo sharing. It became an influencer marketing platform, an e-commerce channel, and a mental health crisis for teenagers. These were not design failures. The platforms afforded multiple uses, and the uses that got actualized were determined by the users, their goals, and the social contexts that shaped what the platforms came to mean. The designers could not have fully predicted these actualizations because actualization is a social process, not a design decision.

Majchrzak and Markus (2013) wrote specifically about the technology affordances for organizations, extending the concept into how organizations as collective actors actualize affordances from enterprise systems. My study-hub materials reference this work in the context of the affordance actualization research tradition. The organizational-level claim is important: actualization is not just individual. It is collective, shaped by routines, norms, management priorities, and the distribution of skill across the workforce. A sophisticated data analytics platform deployed in a company where data literacy is low will actualize different affordances than the same platform in a data-literate organization. The platform is identical. The organizational capacity to perceive and enact its affordances is not.

This connects directly to what I wrote in the earlier post on affordance theory. That post focused on the relational definition: an affordance is not a feature. This post is about the next step: even correctly defined affordances do not actualize themselves. The gap between potential and actualization is where most implementation theory lives. It is also where most implementation failure lives. Organizations buy systems with a specific set of use cases in mind. Users perceive different affordances, or they perceive the intended affordances but cannot enact them without organizational support, or they enact affordances that produce outcomes nobody anticipated. All three of these are affordance actualization dynamics, and all three are common.

Gartner's analysis of enterprise technology adoption frequently observes that actual use cases for new technology diverge from the use cases vendors envisioned. This pattern shows up consistently in coverage of AI tools, enterprise software, and platform deployments on the Gartner newsroom at https://www.gartner.com/en/newsroom. What the vendor designed and what the customer actually does with it are reliably different, and the gap between them is often where the most interesting value, or the most significant risk, ends up living.

The practical lesson for IS researchers is methodological. If affordance actualization is the phenomenon of interest, the measurement instrument has to get below the surface of "adoption" and "use." It has to ask: what specific actions are users taking with this system? Toward what goals? With what perceived possibilities? In what organizational context? That is a harder research design than a survey with a use frequency item. It is also the only research design that can actually explain why the same system produces different outcomes across different contexts, which is one of the most durable and important puzzles in the IS field.