The Cost of Invisible Friction in Enterprise Systems
During a usability consulting engagement, I encountered an organisation that had planned to remove pointer devices — mice, trackpads — from employee workstations at their stores. The rationale was productivity, with a decision grounded in what it believed would reduce time per user-computer interaction. On the basis of this assumption, the organisation had gone so far as to require employees to memorise keyboard shortcuts. The effect would have been regrettable: associates navigating complex software interfaces entirely by keyboard, would have ended up absorbing minutes of unnecessary effort into every routine task. In another engagement, a product team had structurally excluded end users from the research phase, designing around assumptions that the people using the system would have immediately corrected. Neither organisation had set out to create friction. Both had done so decisively, and invisibly.
These are not isolated incidents. They are representative of a pattern that runs through enterprise systems at every level of organisational complexity — a pattern in which decisions made without design intelligence at the table produce friction that embeds itself into workflows, compounds over time, and remains invisible to the people with the authority to address it. Understanding that pattern begins with a precise definition of what invisible friction actually is.
I. Defining Invisible Friction
Invisible friction is the cumulative cost of effort that serves the system rather than the work. In a project context, it is the resistance created when decisions about workflow, user inclusion, system interaction, or process design are made without sufficient understanding of how people actually operate within those systems. It does not announce itself. It does not generate an incident report or a line item on a budget review. It accumulates silently — in the extra steps, the workarounds, the manual reconciliations, the approval chains that add overhead without adding value — until its cost becomes undeniable, usually long after the decisions that created it have been forgotten. Over time, the absence of design intervention and the accumulation of unresolved experience failures contribute to what might be termed usability debt — the compounding cost of friction that was never addressed at its source. The consequences are not merely technical. If the system is customer-facing, satisfaction and engagement erode. If it is used internally, employees absorb the overhead silently, held accountable for inefficiencies that originate not in their performance but in the systems they are required to use — systems that remain unchanged, protected by the organisational politics that funded them.
The two engagements that open this article illustrate that pattern precisely. In the first, a decision about hardware was made on the basis of a productivity theory without anyone asking how associates actually interact with the software they use to perform their work. The friction was not in the absence of a mouse. It was in the gap between the decision-maker's model of how work happens and the reality of how it happens — a gap that design intelligence, applied at the right moment, would have closed before the decision was made. In the second, a product team designed a system around assumptions rather than evidence, because the people who held the evidence — the end users — had been excluded from the process. The friction was structural, embedded in the project methodology itself, invisible until the system met the reality it had been designed to serve.
What makes this category of friction invisible is not that it is subtle. It is that it lives in the space between functions, between decisions, between the intent of a system and the experience of using it. No single team owns that space. No standard metric captures what happens inside it. And in most enterprise projects, no one is structurally positioned to look into it — except design.
II. The Ownership Gap
Friction in enterprise projects does not become visible at inception. It becomes visible at stall — when deliveries are delayed, error rates climb, and project owners find themselves holding a problem that no one can fully account for. By that point, the friction has typically been operating for months, normalised into the daily routines of the people closest to it and invisible to the leadership layer that funded the project. When friction-laden systems reach employees without prior design intervention, the human cost follows a predictable pattern: silent absorption of overhead, erosion of confidence, and a growing disconnect between the people doing the work and the leadership layer responsible for the tools they use.
This timing is not incidental. It is a function of how enterprise projects distribute responsibility. Individual teams own their domains — IT owns the systems, operations owns the workflow, project management owns the timeline. Friction that lives between those domains, in the integration gaps and the assumption failures and the user experience no one formally tracks, belongs to none of them. It accumulates in the white space of the organisational chart, generating cost that shows up in everyone's metrics and appears in no one's mandate.
The consequences of this gap are most visible when projects stall — but the gap itself is most damaging in what happens next. In a consulting engagement with a large financial institution, the back office was experiencing significant error rates in forms submitted by corporate clients. The client's diagnosis was straightforward: the form needed to be redesigned. The assumption was that a better PDF would produce fewer errors.
It would not have. Research and analysis of the actual workflow revealed that the friction had nothing to do with the form. The back-office team was managing erroneous submissions across three separate systems, each requiring independent data entry, each introducing its own failure points. The team had become so absorbed in processing errors — compensating for the friction through sheer manual effort — that the source of those errors had become effectively invisible to them. They were not managing a form problem. They were managing the accumulated cost of a workflow that had never been designed to function as a unified system.
The recommended solution was to consolidate the workflow into a single portal. It was the correct intervention — addressing the friction at its source rather than its symptom. It was declined. The vice-president of back-office operations determined that the criticality of the embedded workflows made systemic change unacceptable. The risk to existing corporate client accounts was considered too significant. The engagement concluded with a user-interface improvement — a refinement of the very form whose redesign had been the client's original request, and the user interfaces of the back-office systems, which were owned by third-party system providers.
The PDF form was delivered. The friction remained.
This outcome is instructive not as a failure of consulting but as a precise illustration of how the ownership gap operates in practice. The friction had been identified, located, and evidenced. A solution had been proposed. The person with the authority to act chose not to — not because the findings were wrong, but because the cost of addressing the friction at its source was organisationally uncomfortable. Design was reassigned to the cosmetic layer at precisely the moment it should have been operating at the strategic one. The UI improved. The workflow did not. The error rate, in all likelihood, continued.
This is the ownership gap in its most consequential form: not the absence of awareness, but the presence of awareness without the organisational will to act on it. And it persists, in enterprise after enterprise, because the function best positioned to make friction visible and to argue for its resolution — design — is structurally excluded from the decisions where that argument needs to be made.
III. Design as the Accountability Function
If invisible friction is a design failure, then design is not merely a remediation tool. It is the function that should be holding the accountability question open from the first day of a project — asking how people actually work, what assumptions are being built into the system, where the integration gaps will create cost, and who will bear that cost when the project goes live.
This is not the role most enterprise organisations assign to design. In the majority of project structures, design enters the lifecycle as a delivery function — responsible for the interface, the visual language, the usability of the output. It is called in to make things look better, and occasionally to make them work better, but rarely to determine whether the right thing is being built in the first place. The consequence of that structural positioning is that the decisions most likely to create invisible friction — decisions about workflow, about user inclusion, about system architecture, about process logic — are made before design has a seat at the table.
Addressing this requires a different understanding of what design brings to a project. Design is not a production capability. It is a diagnostic methodology — a structured way of asking the questions that surface the assumptions, the gaps, and the friction points that other project functions are not positioned to see. Applied from the outset of a project, that methodology does not just improve the output. It changes the nature of the decisions that produce it.
In my consulting practice, this diagnostic approach is structured through the R.A.C.E. framework — Research, Analyse, Conceptualise, Educate — a methodology that maps onto the full project lifecycle precisely because friction does not live in a single phase. It accumulates across all of them.
At the Research stage, a preliminary analysis of systems, resources, and environment exposes the fault lines — the points at which the project's assumptions about how work happens diverge from the reality of how it actually happens. This is where the questions that no other function is asking get asked: Who are the people this system will serve? How do they currently perform the work this system is intended to support? Where does the existing process create overhead, workaround, or resistance?
At the Analyse stage, the insights gathered in research are examined for pattern and implication. By this point, the friction is evidently proven — whether it originates in the system, the management structure, or both. The analysis determines not just what the friction is but where it lives in the organisational structure, who is absorbing its cost, and what level of intervention is required to address it.
At the Conceptualise stage, design prototypes and validated findings translate the analysis into testable responses. This is where the abstract finding becomes a concrete proposal — where the friction identified in research becomes the workflow redesign, the system consolidation, or the process change that the Educate stage will need to make the case for.
The Educate stage is the accountability function made explicit. It is the moment at which research findings, analytical insights, and design proposals are presented to the project and management teams — not as a design deliverable, but as organisational intelligence. Its purpose is to make the invisible visible: to give the people with the authority to act a clear, evidenced account of where friction exists, what it is costing, and what addressing it would require. Whether they act on that intelligence is their decision. That they have it, clearly and without ambiguity, is design's responsibility.
The organisations that integrate this methodology from the start of a project do not eliminate friction entirely. But they encounter it earlier, when the cost of addressing it is lower and the range of available responses is wider. They make decisions with a more accurate model of how their systems will actually be used. And they build into their project structure the accountability function that the ownership gap, in its absence, consistently fails to provide.
IV. The AI Complication
The arrival of artificial intelligence in the enterprise context was received, in many organisations, as a definitive response to the friction problem. AI would automate the repetitive, compress the procedural, and return cognitive capacity to the people who needed it most. For executives who had watched operational overhead accumulate across decades of layered technology adoption, AI represented the systemic intervention that would finally address what incremental process improvement had failed to resolve.
The data tells a more complicated story. Between 2023 and 2025, mid-market enterprises added anywhere from five to fifteen AI-specific tools to their existing technology stacks. Each purchase was individually justifiable. Each solved a discrete problem. Together, they created a new layer of fragmentation on top of the old one — what technology leaders are now identifying as AI sprawl. The cure, in many organisations, became the disease.
The pattern is familiar. An organisation makes a series of decisions about technology adoption without sufficient understanding of how those technologies will interact with the systems and workflows already in place, or with the people who will be required to navigate them. The result is a new category of invisible friction — employees uncertain which tool to use, which output to trust, which workflow has been automated and which has not — layered over the friction that already existed before the AI investment was made.
This is the same failure as the organisation that removed the mice. A decision about productivity was made without design intelligence at the table — without anyone asking how the introduction of fifteen new tools would change the actual experience of doing work in this organisation. The technology was sound. The deployment was not designed.
The organisations that will realise the genuine productivity gains AI promises are not those that have deployed the most tools. They are those that have applied design intelligence to the question of how AI enters the workflow — ensuring that each implementation reduces the steps employees must take, rather than adding a new interface, a new decision point, and a new failure mode to a system already carrying more complexity than it was designed to bear.
Invisible friction is not an operational detail. It is a strategic variable — one that determines how much of an organisation's human capital is available for the work that creates value, how long high-performing people remain, and how clearly the leadership layer perceives the operational reality it is responsible for managing. It persists not because organisations lack the means to address it, but because they have not yet assigned to any function the responsibility of making it visible before it compounds.
Design is that function. Not design as a delivery service, not design as a UI refinement capability, but design as a strategic discipline that enters a project at the beginning, asks the questions other functions are not positioned to ask, and holds the accountability for surfaces that no one else is watching.
The organisation that trusts design strategy from the outset does not just build better products. It sets an expectation to achieve higher goals. A product derived from rigorous design strategy evolves with the organisation itself — the product's evolving expectations feed into the design strategy for answers, and the design strategy improves the product experience holistically through customer and stakeholder insight. It becomes a symbiotic relationship: each sustaining and advancing the other.
That relationship is available to any organisation willing to position design where it belongs — not at the end of the project lifecycle, where it arrives as a remedy, but at the beginning, where it functions as a conscience.