Examples

Ambient computing spent two decades promising interfaces that would vanish into the room, and mostly produced demonstrations nobody had asked for. INTUITEX took the opposite order: build the textiles first, then study acceptance as seriously as the sensing.

The technical side produced textile input controllers, curtain and furniture interfaces, and Gardeene!, a fabric control for the home. The empirical side asked who would actually put such a thing in their living room. Age, gender and general technology attitude turned out to predict acceptance strongly; adopters and rejecters formed two distinguishable groups rather than a continuum; and a conjoint study separated the product attributes people will pay for from the ones they merely rate highly.

The result I still find most useful is a paradox in the design guidelines. An invisible interface has to announce that it exists, and how it announces itself decides whether it is adopted at all.

This is the strand my doctorate came out of: motion-based exercise games and cognitive-training games for older adults living in technology-assisted environments. The games were built and evaluated for usability and performance, and in the motion-based case for whether play actually mitigated pain.

The harder question was never whether the games worked. It was whether the intended players would have them. Older adults are the group most often designed for and least often designed with, and technology aimed at them is routinely justified by a demographic argument rather than by anything the intended users said. So each system was studied through an acceptance lens as well as a performance one — individual factors, motivation, and the social acceptability of being seen to need such a device at all, which turns out to matter more than the interface does.

That is also the argument behind the responsible-research position I have taken here: the distinction between a product and a well-meant imposition is drawn by the people who have to live with it.

Most acceptance research studies one technology at a time, which makes the findings hard to compare and easy to over-read. This strand asks the question the other way round: measure many technologies with one instrument, and see where they land relative to each other.

The method uses micro scenarios — short, concrete descriptions of a technology in use — rated on risk, benefit and value. Because every technology passes through the same instrument, the results can be laid out as a map: a shared space in which self-driving cars, AI diagnosis, smart meters and social scoring all have coordinates, and in which distance means something. A dual-perspective design separates what people think society at large believes from what they themselves believe, and the gap between those two is often the more interesting number.

The maps have since been drawn for artificial intelligence, for technologies in society generally, and for health technologies. The one finding I would put first: expert and lay maps of AI diverge sharply, and they diverge on value rather than on risk.

Conjoint analysis is the sharpest tool we have for the question people answer badly when asked directly: what would you actually give up to get this? Its limit has always been the stimuli. Attributes and levels have to be written by hand in advance, which caps how large and how concrete a design can get.

The platform closes that gap by generating the stimuli from prompts, so a study can vary a product description along dimensions that would be impractical to enumerate by hand, and can present them as something a participant reads rather than a grid of levels. It is open source, because an instrument nobody can inspect is not much of an instrument.

The applied study behind it looks at employee attitudes toward personal-data use in smart factories — a case where the trade-off is real, the stakes are asymmetric, and asking directly reliably produces the socially acceptable answer instead of the true one.

You cannot run a controlled experiment on a real supply chain. You can, however, build one small enough to fit in a browser and large enough to be genuinely hard, put people in it, and watch what they do.

That was the approach here: business simulation games as a research instrument rather than a training product. Players make ordering and quality decisions under complexity and risk, and the game records the decisions — which turns questions about human factors in production networks into questions with data behind them. Decision complexity, the effect of correct and defective decision support, and how compliance shifts when a system has been wrong once are all measurable this way.

The games did double duty as teaching tools, and the later work generalises the method: a design process model for building serious games for the human-centric digital transformation of production, so the instrument can be rebuilt for a different question rather than reinvented.

More technical and conceptual work I did in the Cluster of Excellence Internet of Production addressed data-to-knowledge and knowledge-to-data pipelines: a reproducible and open system that lets a foundation model be trained from multiple distributed sources held by different organisations, by means of digital shadows.

A digital shadow is not a digital twin, and the difference is the point. A twin aims at a complete, faithful model of one system; a shadow is a task-specific reduction, carrying only what some particular question needs. That makes shadows the more versatile object — cheaper to produce, and composable across systems that were never designed to be modelled together.

The demonstrator puts that to work across three laboratories: laser material processing, automated assembly, and the draping of carbon fibres. Each records robot trajectories and deposits them, with semantic annotations, on a central open research data infrastructure. That is what makes the pooling tractable: rather than negotiating access between institutes one pair at a time, the data is published once, findable by anyone with a use for it, and a fourth site can train an inverse dynamics model across all three.

Both directions are engineered. Getting data into knowledge is the direction everyone builds; getting knowledge back to where it can be acted on — the trained model returning to the shop floor, usable for tasks none of the three sites had in mind — is the one that decides whether any of it is used again.