Image based on Don Norman‘s famous teapot, and the Obey Giant face
Last month I asked, in response to some criticism, whether there was a better term than ‘architectures of control’ for the loose category of stuff discussed on this site. The response was great – thanks to all who got in touch or commented.
James Young, an artist & designer from Oregon, thoughtfully suggested obedience engineering (along with ‘restrictive’, ‘regulatory’ and ‘supervisory’ engineering – as extensions to the term ‘functional engineering’, which I understand but have always thought was something of a tautology!). Obedience engineering has a neat ring to it – implying external authority – and describes most of the examples on this site pretty well, both politically- and economically-motivated control.
In most cases the ‘obedience’ is to serve a higher power’s strategy in some way, whether that’s forcing customers to buy razor blades more often or stopping the homeless sleeping in a park. In some cases, though, the obedience serves the user him or herself (usually in addition to a higher power in one way or another), such as various forcing functions and mistake-proofing aimed at ensuring safe operation of products or machines – it’s a similar kind of obedience to obeying your parents’ instructions not to put those fireworks in your pocket: for your own safety as well as their peace of mind. I’m aware that most of the examples I use come across as rather negative (and usually paranoid), so it’s important to remember that a lot of ‘control’ can have beneficial intentions (at least) for the user or society as a whole.
Reversing the phrase, ‘engineering/ed obedience’ and ‘designing/ed obedience’ also have a lot of merit, either as titles themselves or as explanatory subtitles/taglines. Architectures of control: engineered obedience?
(I don’t necessarily want to get into the design-or-engineering debate here. Both terms mean many different things to different people, and the use of either could immediately put off or attract people who would find something of interest here. There are readers here from a fair variety of fields; I know people whose eyes go blank when engineering is mentioned, and others who would assume that a site about design must be dealing purely with aesthetics or artisan furniture. Personally I see all design and engineering (and art and programming – as Paul Graham recognised) as pretty much the same subject, and indeed, perhaps the intersection of the physical and cognitive sciences with the environment, history and culture, but that’s something for another day…)
Jim Lipsey, a project engineer from Chicago, suggests disaffordances as a synonym for architectures of control – again, a neat and clever suggestion which also has the benefit of immediately conveying some understanding of the concept to product design and usability professionals and academics.
Nevertheless, it’s worth running over briefly what ‘affordances’ are in the first place, to explain why ‘disaffordances’ might be a good term. In its original definition, an affordance is a possible function of, or interaction with, a device. A chair gives me the affordance of sitting on it, but also standing on it, or hitting someone with it. This is a simplification of psychologist James J. Gibson‘s definition of affordances. Donald Norman – author of the legendary The Design of Everyday Things – extended the concept to what he later called perceived affordances: while I might use a chair to hit someone, my cultural conditioning, together with the form of the chair, suggest that I should sit on it. Norman’s affordances are thus what people think they can do (or should) with objects, which may be different to what they actually can do with them:

From ‘Affordances‘ by Mads Soegaard: ‘Separating affordances from the perceptual information that specifies affordances. Adapted from Gaver (1991).’
This Interaction-Design.org encyclopaedia article (from which the above diagram comes) is a very clear treatment fo the subject, as are Don Norman’s own ‘Affordances and design‘, and indeed Wikipedia’s entry.
Disaffordances, then, would imply either products with functionality deliberately removed (which fits many architectures of control example well – most obviously ‘feature deletion‘) or with the functionality deliberately hidden or obscured to reduce users’ ability to use the product in certain ways, or a combination of the two. That does take care of most of the examples I’ve looked at on this site, though I worry a bit about having to concatenate the two definitions. I also feel that quite a lot of architectures of control are actively attempting to force users to change their behaviour, whilst disaffordance implies a more passive state of affairs.
I think it may be best to use the term ‘disaffordance’ specifically to describe the practice of ‘disenfranchising’ users from the functions their products, systems or environments might otherwise provide (or have previously provided). This covers a lot of the things we discuss here (though it’s important to remember that architectures of control are deliberate, intentional, often strategic disaffordances, rather than something that’s difficult to use or hides its features through incompetent design); the the term doesn’t have much currency (yet), but I’ve done as Jim suggests and registered disaffordances.com and disaffordances.co.uk.
This blog is still maturing, and evolving, as is the field of thinking and practice which it charts. I’m sure plenty of new terminology (and jargon) will become commonplace in the years ahead. And the site will continue, in the words of the fantastic Gossip, ‘standing in the way of control‘ [mp3 link].