Interfaces as Tolerances

This chapter borrows the idea of tolerance from manufacturing and extends it to interaction design. The availability of a material is a constraint; its properties and permitted variations help establish its operating margin. People also show differences and limits that must be studied. That extension is an editorial proposal of this chapter: they are not technical synonyms and I do not use them as if they were.

Let us push the logic to the extreme. With the right machinery and materials it is possible to manufacture a toothbrush with metal bristles. Nothing in the process prevents it. And yet being able to make it does not show that the combination is appropriate for the intended contact: that a way to produce something exists does not answer whether it should exist. This is the point at which the possibility of production stops being enough to justify a design.

The user feels the consequence of these decisions every time they pick up the object and use it. In an application something similar happens, even if its materials are less visible.

Take a need everyone recognizes: finding your bearings and getting somewhere. A navigation service such as Google Maps serves it in a car, on a phone and on a tablet, and the need is the same in all three cases. What changes is everything surrounding the person who has it. I do not promise that every current version of the service offers exactly the same functions on every device; I use the example to compare scenarios, not to describe a product.

In a car, attention is shared with driving. Google’s design guidance for driving (Android Auto / Android Automotive OS) establishes that driving-related tasks take priority over any other, that information must be readable at a glance — it proposes a maximum of two seconds to read a piece of content and return to the road — and that no operation should require taking both hands off the wheel.² These are limits of context, not of screen: the same route calls for fewer steps, shorter instructions and voice.

On a phone, during a walk, the hand is occupied, daylight competes with the screen, battery matters and attention is divided with the surroundings: the street, other people, the next crossing. What the interface must achieve is that the next action is recognizable and can be handled with one hand.

The tablet, by contrast, tends to appear when someone is preparing a trip. There is more surface and room for unhurried browsing: comparing alternatives, seeing more context. But it is wise not to assume that every tablet has the same sensors or serves the same purpose as another.

That is why reducing the difference between these three scenarios to screen inches is a simplification. The device changes the available channels and also the effort that can be asked of the person; at bottom, it changes their acceptance threshold. And the interface is transformed even more when the interaction occupies the whole body.

To see this same problem in a physical object, I propose a conceptual multisensory seat for a 4D theater. It is a working example, not a portrait of a commercial installation: it lets us analyze movement, vibration, thermal effects and coupling with sound without attributing this whole configuration to every theater that exists, or assuming that each effect originates inside the seat. Part of the sound, the air or the heat may come from the room.

Taken apart, the seat shows that each part carries a design decision and that each decision has an aspect someone must evaluate.

All these variables need specification, testing and acceptance criteria. An intention of immersion does not by itself guarantee an experience that suits everyone: the backrest that supports one body well can leave another without support, a travel one person enjoys can bother another, and a vibration that is clear at the start of the show can turn into accumulated sensory load by the end. Here the idea of tolerance returns. The point is not that the seat works on average, but knowing within which variations it still works and for whom.

But the seat still has to be installed in a room, and there limits appear that the design of the seat alone cannot resolve.

Suppose the commercial goal is to have a certain number of seats. That number translates into a conversation with the available floor area, the spacing between rows, the motion envelope of each seat, the access routes and the space for maintenance. Accessibility and evacuation have to be considered from the outset and not at the end; the applicable dimensions depend on the project and its location, so I do not propose any here.

A seat that works well as a prototype can take up too much space, or cost too much, once many units are installed. The consequences chain together. Changing the width alters the capacity. Changing the base alters the movement and the maintenance. Reducing the space between rows changes access and the experience of the person seated. Each adjustment that resolves one limit pushes the problem toward another.

It helps to distinguish two volumes that are easily confused. Units manufactured affect the investment in tooling and the cost per part. Seats installed affect the capacity and revenue of the service. Whoever produces the seat thinks about the first; whoever operates the room, about the second; and the design has to speak to both.

Nor is the profitability of a room explained by counting seats. It depends on occupancy, price and operation. More seats do not mean more revenue if the experience forces occupancy down or makes maintenance more expensive.

In digital products, costs are also spread over an expected capacity of use. That capacity must be analyzed per platform and per function.

Back to the screens: mobile, tablet, television, smartwatch. A function can be technically feasible and still not add enough incremental value to sustain its development, its testing and its maintenance on a given platform. These are two different questions and it pays to ask them separately: what does the hardware allow, and what does the economics justify.

The watch serves for the first: brief interaction, small controls, limited battery and capabilities that vary between models. On television, reading distance, the remote control and the diversity of devices all count. Those are constraints of hardware and context. That a function is not built there for reasons of cost is another kind of constraint, and mixing them leads us to justify with technology what is really an economic decision, or the reverse.

The audience that matters is that of this product and this function on that device, not that of the platform in general. It is not correct to say that watches or televisions always have insufficient critical mass: a small audience can justify a high-value solution, and a large audience may not use the function.

With those assumptions the calculation is a division: 600,000 divided by 120 is 5,000. What matters is what gets counted. It is the users who use the function, not downloads or total users, which neither substitute for effective adoption nor demonstrate that contribution.

When the value of the function is an operating saving, retention or a service obligation, the case is built with that evidence and not with a per-user calculation. And there is a limit no calculation moves: the necessary safety and accessibility are not removed by a popularity calculation.⁷

Beyond being able to build and sustain the function, we need to understand how much change the person receiving it will accept.

That question has a name in industrial design: MAYA, for Most Advanced Yet Acceptable, a phrase associated with Raymond Loewy. I use it as a guideline to balance novelty and familiarity, not as a mathematical formula. The study by Hekkert, Snelders and van Wieringen examines how typicality and novelty contribute together to aesthetic preference for industrial products.³ Its scope is aesthetic preference; it does not warrant concluding that MAYA by itself predicts adoption, health or financial return.

What I propose is applying it to features. Keep the core benefit of a feature and adapt its complexity to the device, to the task and to what the user can recognize and learn. A smartwatch can offer a brief action and offload extensive setup to the phone, provided the continuity between them is clear and useful. If it is not, the watch merely added a step.

The decision to include, simplify, transfer or discard a feature combines four questions. Is it safe and accessible for the intended use? Does the device sustain it? Does the user understand and accept the interaction? Does the value justify sustaining it? MAYA contributes to the third question, and only to that one. That combination is the method this chapter proposes; it is not an extension attributed to Loewy.

That acceptance also depends on small decisions that repeat, such as a connection chime.

A concrete example of a branded audio signal appears in Marshall’s Major IV headphones. Its support page, explaining how to pair via Bluetooth, notes that the brand’s pairing sound should be heard.⁴ From that fact, and only from that fact, we can examine the function of recognizable confirmation: it communicates a state (“connected”) and builds identity. I do not extend that behavior to other models, to a wired connection or to other events without verifying it.

The difference matters between an occasional alert and repetition throughout a working day. Hearing a signal once, when unboxing a device, is one thing; hearing it dozens of times a day is another. Intensity, duration, frequency, context and user control are all part of the design decision. Whether a sound pleases or annoys is not a universal constant: it is a response that requires research with diverse users across representative situations.

The same applies to notifications, sounds and vibrations in software applications. Choosing categories, timing, frequency and delivery channels, grouping messages and distinguishing between confirmations, marketing promotions and critical alerts are decisions that distribute effort: either the product absorbs it by filtering and prioritizing, or the user absorbs it by dismissing and silencing. Personalization is, at bottom, the control a user holds over their experience.

That control includes exit routes. Deleting personal data and closing an account belong to the same relationship and demand clear consequences and understandable interactions: anyone deciding to leave should know what is retained, what is purged, and when. It also pays to distinguish between system errors, task recovery and user frustration, because they are not identical: an error corrected in a single step does not weigh the same as one that forces starting over from scratch.

And there is a trap in product metrics. Tracking who abandons, who silences and who continues using the product despite frustration reveals far more than counting aggregate sessions. High frequency of use, by itself, does not demonstrate acceptance: people often continue using what irritates them simply because they have no viable alternative.

In enterprise tools and workplace hardware, the operator may have even less latitude to choose whether to keep using it.

This entire progression yields an actionable engineering method. I propose maintaining a Map of Limits for every critical interaction. The map documents the task and its environmental context, the observed variable, the explicit acceptance threshold, the empirical evidence available, who validates that criterion, and what remedial action triggers if the threshold is breached. When no validated limit exists, teams must not fabricate one: they document the uncertainty and commission the necessary study.