A General Theory of Human-System Interaction

Swarochish C Mnemos AI

Paper 3 in the Mnemos AI working-paper series.

Abstract

Felt ease is usually treated as a design problem. I think it is a regulation problem, and that treating it as a design problem is why so much effort produces so little change in what people actually experience. A system holds the difficulty a person encounters within some range while their capability changes, the environment produces disturbances, information arrives incomplete and late, institutions pursue objectives that conflict with each other, and everyone involved adapts strategically to whatever the system rewards. The interface is one actuator in that arrangement. Laws, incentives, defaults, architecture, enforcement, organisational process, physical environment and social norm are others, and several of them are stronger. This paper sets out the frame: five channels through which a system regulates behaviour, complexity as something allocated rather than removed, trust as the mechanism by which allocation holds, requisite variety as the constraint on how many situations a system can actually serve, and friction classified by what it produces rather than by how it feels. It closes on five tensions I have not resolved. The argument is deliberately general, which is also its main weakness: it explains a great deal and predicts less than I would like.

1. The claim

Ask what would make an interaction easier and you get one kind of answer. Ask what behaviour and outcome a system should produce, what effort and uncertainty are appropriate to it, who should carry the complexity that remains, and what has to be true before a person will rely on it, and you get a different kind of answer. The second question contains the first. The first does not contain the second.

The object being designed is not the interface, and it is not the journey either. It is the relationship between institutional intent, the rules and incentives that intent produces, the behaviour those rules produce in the system, how a person interprets that behaviour and acts on it, what happens in the world as a result, and what of that outcome finds its way back to the institution. Most of the interesting failures happen in the parts of that loop nobody thinks of as design.

2. Five channels

A system regulates the people who use it through five channels, and only one of them is the screen.

Information governs what a person can know, what is disclosed, and what stays hidden. Incentives govern what is rewarded, penalised, and quietly made not worth the effort. Effort governs how many steps, decisions and dependencies stand between an intention and an outcome. Feedback governs what a person learns about the consequences of their action, and critically, how late they learn it. Ambiguity governs how much of the interpretation the person has to do for themselves.

Most design attention goes to effort, because effort is the channel that is visible on a screen. Incentives and ambiguity are usually stronger, and they are the two most often adjusted by accident.

3. Complexity is allocated, not removed

Tesler's law is generally read as a statement about conservation. I think it is better read as a statement about allocation.

Every task has a floor of intrinsic complexity. What a system decides is who absorbs it: the user, the software, the builder, the operator, the support desk, the caseworker, the institution, or the failure tail. That is a real decision and it is usually made implicitly.

Complexity is not literally conserved, and the conservation reading has done some damage. Good abstractions remove complexity that the task never required. Bad systems manufacture complexity the task did not contain. The more useful decomposition is that total experienced complexity is the intrinsic complexity of the task, plus the extraneous complexity the system generates, plus exposure to the failure tail.

Intrinsic complexity is the real structure of the problem. Extraneous complexity comes from poor coordination, unclear language, redundant steps, lost state, organisational seams, arbitrary policy, bad defaults and misaligned incentives. The obligation is to attack the extraneous aggressively and to decide deliberately where the intrinsic belongs.

There is one audit question that does most of the work here. Who absorbs what was removed? If the answer is not the builder or the system, the complexity was probably not eliminated. It was moved.

A government simplifies its internal processing by requiring citizens to submit more evidence. A product reduces screen complexity by shifting work to support. Automation simplifies the routine case and concentrates the hard exceptions on an operator whose skills have decayed because the routine cases no longer reach them. Bainbridge described that last pattern in 1983 and it has not become less common since.

This is why the failure tail has to be treated as a first-class bearer of complexity rather than as an edge case. It is where displaced complexity accumulates, and it is the part of the system that nobody's metrics are watching.

4. Trust is the delegation mechanism

Trust is what allows complexity to stay allocated away from the person. Without it, they take the work back.

They verify the recommendation. They screenshot the confirmation. They call to check. They keep a parallel spreadsheet. They redo the calculation by hand. They keep paper. They avoid the automated path entirely. They hire someone to deal with it.

A system can automate an action in full and still fail to reduce what the person actually experiences, because the person keeps monitoring it. That is the case that makes automation metrics misleading: the task is automated and the burden is not gone.

So the honest version of user burden is explicit effort, plus verification effort, plus whatever preparation the person makes in case it fails, plus the residual uncertainty they carry around. Only the first is usually measured.

How much a person will delegate depends on how much they trust the system, and trust here is not an attitude that gets added after usability is sorted out. It is closer to a running estimate: given what I know about this system, how safe is it to depend on what it does next. Trust is a prediction rather than a feeling, which is why it responds to evidence and why it can be lost in one event.

5. What trust is actually made of

Five properties, and they are not interchangeable.

Competence. The system produces correct and useful outcomes, handles the ordinary case, and recognises when a case is outside what it can do. Competence is not the absence of failure. It includes detecting failure and containing it.

Predictability. A person can form a stable expectation of what the system will do. They do not need every outcome to be identical. They need the variation to be intelligible, which is a much weaker and much more achievable requirement.

Transparency. The system makes its important internal state visible: what it understood, what it is doing, what it has done, and what it will do next. This is the property most often replaced by a progress indicator.

Control. The person keeps meaningful authority over consequential decisions, including the ability to stop, reverse or override. The escape hatch is not a feature to be added if there is time. It is the error-correction loop for the regulator itself, and a system without one cannot be corrected by the people it affects.

Alignment. The person believes the system's incentives are compatible enough with their own. This is the layer that survives least well under commercial pressure, and it is the one I understand least. A system can be competent, predictable, transparent and controllable while being pointed at an objective the person would not choose. Nothing in the other four catches that.

6. Calibrated, not maximised

The goal is not maximum trust. Maximum trust in a system that does not deserve it is how people get hurt.

The goal is calibration: trust that tracks actual reliability, so that reliance is appropriate rather than merely high. That means a system sometimes has to reduce a person's confidence in it, which no product organisation is incentivised to do. Communicating uncertainty honestly costs conversion in the short run and is the only thing that survives the first serious failure.

Under-trust is also a failure, and a more common one than the literature suggests. A person who verifies everything the system does has gained nothing from the automation and has paid for it.

7. State, not persona

Systems should respond to runtime state rather than to fixed categories of user.

Personas are a planning tool that quietly becomes a runtime model, and as a runtime model they are wrong in a specific way: they assign a person a fixed identity when what actually varies is their situation. The same person is expert on Tuesday and confused on Thursday because the case is unusual, or because they are doing this at eleven at night, or because the last three attempts failed and they no longer trust the result.

What matters at runtime is the state: how much the person knows about this particular task, how much time they have, how much is at stake, how many times they have tried, whether they are recovering from an error, and how much of what the system needs is already known. None of that is a demographic.

The system should also represent its own state, and be able to say what it knows, what it is uncertain about, and what it is waiting on.

8. Behaviour modes

Rasmussen's distinction between skill-based, rule-based and knowledge-based behaviour is a stronger model than novice and expert, because it describes what a person is doing rather than who they are.

In skill-based behaviour the person acts automatically through learned patterns. Consistency and stable layout matter, and warnings are weak, because automatic behaviour bypasses conscious reading. This is why the confirmation dialogue that everyone clicks through is not a safety mechanism.

In rule-based behaviour the person recognises a familiar situation and applies a known procedure. The system's job is to help them identify which rule applies, which is mostly a matter of making the situation legible rather than making the procedure available.

In knowledge-based behaviour the person is in a situation they do not recognise and has to reason from first principles. They do not need another sequence of steps. They need to understand what is happening. Almost all help systems are built for rule-based behaviour and deployed at people who are in knowledge-based mode.

9. Requisite variety

Ashby's law of requisite variety says that only variety can destroy variety. The paraphrase usually heard, that only variety can absorb variety, is Beer's rather than Ashby's, and the softer verb hides how strong the constraint is. It is the most useful constraint I know of for deciding what a system can honestly claim to serve.

If people arrive in twenty meaningfully different states and the system has three responses, most of those states will be handled badly regardless of how well the three responses are executed. Polish does not substitute for range. This is worth stating because most quality effort goes into improving existing responses rather than into asking how many distinct situations the system can actually distinguish.

Conant and Ashby's addition is that every good regulator of a system must contain a model of that system. A system that adapts to people therefore requires an explicit model of the person, the task and its own state, and if that model is implicit it cannot be inspected or corrected. The uncomfortable implication is that adaptive systems and surveillance systems require the same machinery. I come back to that in section 14.

10. Friction is not one thing

Friction should be removed when it produces nothing and preserved when it produces something. The question is not how much friction there is but what each piece of it is doing.

Shared-space road design is the clearest example. Ambiguity and cognitive load are deliberately increased because attention is the safety mechanism. Removing that effort makes the interaction feel smoother and the system less safe, and no usability metric would catch it.

So before removing friction, ask what it produces. If the answer is nothing, remove it. If it produces safety, comprehension, consent, skill or legitimate deliberation, optimise it instead.

11. Error routing

Not every failure should be met with more explanation. Reason's classification is useful here because each class has a different remedy and applying the wrong one reliably fails.

A slip is a correct intention executed wrongly. It is an effort or constraint problem, and the responses are undo, separation of destructive controls, forcing functions, sensible defaults and immediate feedback. Warnings are weak against slips for the reason given in section 8.

A mistake is a correct execution of a wrong intention, formed from a wrong mental model. It is an information problem. The fix is to repair the model by showing causal structure and why the expected outcome differs from the actual one. More warnings do nothing.

A violation is a knowing departure from procedure. It is usually an incentive, legitimacy or feasibility problem. If the approved process takes ten days and the deadline is tomorrow, the workaround is rational, and training will not fix a rational violation. Repeated violations are evidence about where the formal system and the operating system have diverged, which makes them worth instrumenting rather than punishing.

12. Seams

Felt cost concentrates at boundaries.

A person moves across departments, databases, jurisdictions, vendors, offices, portals, caseworkers and legal regimes. The institution sees a set of separate processes that each work. The person experiences one problem that does not.

Every seam can drop state, require re-identification, change terminology, reset trust, add delay, and make ownership ambiguous. So the unit of analysis is not the screen sequence. It is the path across the organisation.

At each boundary the questions are what state is lost, what the person has to repeat, who owns the outcome now, whether completing the previous step actually triggers the next one, what the person believes is happening, what each institution believes is happening, and who is responsible when those two beliefs differ.

Administrative burden concentrates at seams because no single actor owns the whole experience. Sometimes that is accidental. Sometimes it is a rationing mechanism: an institution can reduce take-up without changing eligibility by raising learning costs, documentation requirements, uncertainty and delay. Where that is the case the friction is not a usability defect. It is policy implemented through interaction cost, and treating it as a usability defect is a category error that will waste a great deal of effort.

13. Dynamics

Static maps miss most of what goes wrong, because several clocks are running at once.

Delayed feedback causes overcorrection, oscillation, and false beliefs about cause. Capability changes: people learn, and they also forget, and skills decay fastest in exactly the systems that automate the routine case. Behaviour adapts to measurement, so any metric that becomes a target stops measuring what it did. And the environment moves underneath all of it.

A system tuned to the state of the world at the moment it was designed is already drifting by the time it ships. That is not an argument against design. It is an argument for instrumentation, and for treating the model of the user as something that has to be maintained rather than established.

14. What I have not resolved

Five tensions. I do not think any of them has a general answer, and I am suspicious of anyone who says otherwise.

Variety against simplicity. Serving more states means more branches, and more branches mean maintenance cost, inconsistency and eventual leakage. Requisite variety says you need the range. Engineering says the range will rot. There is no universal optimum, so the choice has to be made explicitly rather than drifted into.

Remembered effort against actual welfare. Optimising for the peak and the end improves how an experience is remembered without necessarily improving the person's condition. A system can feel smooth and produce a bad outcome. This is why outcome metrics have to act as a constraint on experience metrics rather than sitting alongside them.

Sensing against surveillance. The technical act required to adapt to a person is the same technical act required to classify and control them. There is no version of adaptive systems that avoids this, which means the distinction cannot be technical. It has to be governance: whether the model is visible, whether it can be corrected, whether collection is proportionate, whether the model gates access, whether the person can opt out, how long data is kept, and who else can use it. I find this the least satisfying answer in the paper, because governance is exactly the thing that erodes quietly.

Trust against dependence. Successful delegation becomes dependency. If a person loses the skill or the means to operate without the system, their trust is no longer fully voluntary. Where failure would be consequential, the system should preserve fallback capacity, which is a direct cost with no visible benefit until the day it matters.

Institutional goals against human goals. The institution optimises compliance, throughput, fraud reduction, cost, or political defensibility. The person optimises dignity, fairness, speed, certainty, autonomy or access. Design cannot reconcile these silently, and attempting to is how interfaces come to feel dishonest. Where the objectives conflict, the resolution is a policy choice and should be argued as one.

15. What this is and is not

The frame is general, and that is both the point and the problem. It explains a lot: why simplification programmes displace rather than remove work, why automation can fail to reduce burden, why warnings do not prevent slips, why help systems fail the people who most need help, why administrative burden clusters at organisational boundaries, and why some friction should survive.

It predicts less than I would like. A theory that accommodates every observation is weaker than one that forbids some, and I cannot yet state what this frame forbids. The nearest thing to a falsifiable claim I can offer is the allocation audit: if you remove effort from one party and cannot name the party that absorbed it, either the removal was genuine abstraction or the complexity reappeared somewhere you are not measuring, and in my experience it is far more often the second. That is checkable. Most of the rest of this is a way of looking rather than a way of predicting, and it should be held accordingly.

References

Ashby, W. R. (1956). An introduction to cybernetics. Chapman & Hall.

Bainbridge, L. (1983). Ironies of automation. Automatica, 19(6), 775--779. https://doi.org/10.1016/0005-1098(83)90046-8

Conant, R. C., & Ashby, W. R. (1970). Every good regulator of a system must be a model of that system. International Journal of Systems Science, 1(2), 89--97. https://doi.org/10.1080/00207727008920220

Lee, J. D., & See, K. A. (2004). Trust in automation: Designing for appropriate reliance. Human Factors, 46(1), 50--80. https://doi.org/10.1518/hfes.46.1.50_30392

Parasuraman, R., Sheridan, T. B., & Wickens, C. D. (2000). A model for types and levels of human interaction with automation. IEEE Transactions on Systems, Man, and Cybernetics -- Part A: Systems and Humans, 30(3), 286--297. https://doi.org/10.1109/3468.844354

Rasmussen, J. (1983). Skills, rules, and knowledge; signals, signs, and symbols, and other distinctions in human performance models. IEEE Transactions on Systems, Man, and Cybernetics, SMC-13(3), 257--266. https://doi.org/10.1109/TSMC.1983.6313160

Reason, J. (1990). Human error. Cambridge University Press.

Reason, J., Manstead, A., Stradling, S., Baxter, J., & Campbell, K. (1990). Errors and violations on the roads: A real distinction? Ergonomics, 33(10--11), 1315--1332. https://doi.org/10.1080/00140139008925335

Sweller, J., van Merriënboer, J. J. G., & Paas, F. G. W. C. (1998). Cognitive architecture and instructional design. Educational Psychology Review, 10(3), 251--296. https://doi.org/10.1023/A:1022193728205