Disaffordances and engineering obedience

Based on Don Norman's famous teapot

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:

Usefulness and usability
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].


  1. Disaffordances and Engineering Obediences appeared to me as describing precisely what this blog is focusing on, *after* I read this post. I’m not sure whether I’d have seen that clear picture having come across the title for the first time.

    Although I fully subscribe to the belief that dumbing down content and underestimating one’s audience is wrong, I also believe in respecting the intelligence of a conversational partner who does not, perhaps, have extensive jargon or vocab in a given area.

    A favorite blog, Mixing Memory, has a newish post about teaching. There’s a comment on the post from a teacher who says that when she(?) has sent students there, they usually find the content over their heads. Just about all the content on that blog, however, could be presented in a more easily understandable manner to any child past the age of reason, and I get the impression that there are teachers reading it who do exactly that.

    My point here is that who you wish your audience to be and why is as important as an accurate title. An example of an easily grasped title might be Hidden Agendas in Design.

    My understanding is that your wonderful blog is written based on a number of agendas as well, including raising general awareness of the subject, engaging in conversation, and as part of a process toward publishing on the topic. A mix of agendas such as this, imo, makes a clear definition of the audience rather tricky.

    I should also mention that the myriad and subsequently fuzzy and diluted meanings of the word Design represent one of my pet peeves (which I wrote a whole meandering post on).


  2. Dan

    Thanks Vera, that’s a very thoughtful response.

    I suppose that as with many bloggers, my initial priority was to get anyone reading the blog. And, nearly a year later, from what I can tell there’s a fair cross-section of readers – mechanical engineers, product designers, architects, interaction designers, information theorists, user experience people, programmers, web developers, new media people, marketing people, academics, activists, people interested in intellectual property, people interested in a wide variety of issues on a non-professional level, and so on. Certain posts – such as the one with the downloadable high-frequency sounds have had a very different visitor profile to others.

    What all that means, of course, is that there isn’t really a ‘typical’ reader at whom the blog is aimed – and as you say, the mix of aims (“raising general awareness of the subject, engaging in conversation, and as part of a process toward publishing on the topic”) again makes it difficult to be definitive about what the audience ‘should’ be. I know I’m guilty in many posts of making assumptions about certain jargon, mindsets (or indeed, sarcasm) being more widespread than they are; equally, I know I have a lot of catching up to do in learning about academic precedents in many of the fields I talk about, particularly the ‘philosophy of control’.

    Your post on the meanings of ‘design’ is very interesting and to some extent this is a major ‘elephant in the room’ which few want to tackle. ‘Design’ has become such a catch-all term for creative endeavour, and especially now that ‘design thinking’ is becoming a new buzz-phrase in business, we do perhaps risk the term becoming meaningless, if only because it’s not longer clear what skills a ‘designer’ should/would/could have.

    When I was choosing what to do at university, I deliberately chose the course which seemed to be the most inter- and multi-disciplinary thing possible, quite simply because I wanted to know about, and how to do, as much stuff as possible. Industrial Design Engineering at Brunel covered everything from [jargon alert] engineering mathematics to cognitive theory, blindfolded charcoal sketching to brand evaluation, rapid prototyping to wood veneering, marker rendering to finite element analysis, photographic aesthetics to presentation skills, Matlab to CSS, environmental chemistry to factory layout planning, Japanese quality methods to PIC programming, welding to computational fluid dynamics, complex numbers to political art. We had it all, though much of it was necessarily in fairly shallow detail.

    But that’s part of the problem: I’m a ‘designer’ and have supposedly learned all of this stuff, and hence I see it all as ‘design’, even though when I look at job ads for designers they typically either mean “Adobe Illustrator user” or “Pro/Engineer user”. That’s an over-simplification, but I would think it’s going to cause a bit of difficulty among employers in the near future faced with so many ‘designers’ who may have entirely diverse, and separate skill sets, but who still operate under the ‘designer’ banner.

  3. lol, Dan, that’s the first time anyone specifically pegged my predeliction for tackling elephants. I’d no idea when I decided to try out blogging recently that it would be an outlet for that. Changing my suddenly common name is something to do when I move to my own domain, so I’d like your permission to put elephants in the hopper, although my first reference might be to the parable about the blind men.

    Your courses, and the reasons for your choice, sound most attractive. I really believe that we all need much more cross-disciplinary thinking everywhere: academia, business, the web, life…

    I don’t find your writing overfull of jargon or pretentious in the least. In fact, I enjoy your direct and matter of fact handling of what could easily be considered (and shouldn’t be) an esoteric subject very much.

    The extent to which I encounter the label design in web development topics, about visual presentation, usability, and actual functionality, is highly magnified for me because of my own initial references to the word. I come from a business background of commercial real estate development, where ‘design’ has many applications, and have also been an avid collector and afficionado of art, decorative arts (150 year evolution of industrial design), graphic design & illustration, as well as the history of costume (fashion design – which is a melding of utilitarianism & fantasy) for a few decades.

    I’m wondering, as I write this, why architectures of control isn’t satisfying? Is it perhaps, that the word architecture connotes rigidity, whereas your topic is more about manipulation, and relevant as much to discussion of political and social agendas as to the meaning of structures?


  4. I have a suggestion of my own. Let’s face it — most of the times, what’s going on is either malicious, misguided, or at best insulting to the intelligence of the user. An awful lot of it has ulterior motives that have nothing to do with the user’s interests at all, including all truly obtrusive examples.

    So how about “Orwellian engineering”? Particularly if it actually involves spyware functionality or thinks it’s RoboCop, but more generally because it invariably involves insidious, pervasive control and — even more so — manipulation by unelected, unaccountable authorities of some kind or another.

  5. Dan,

    Very thoughtful post and discussion. I’m pleased that suggesting ‘disaffordances’ has provided some food for thought.

    I feel your and Vera’s pain regarding the dilution of the meaning of design. If it’s any consolation, this happened to those who call ourselves engineers a long time ago.


  6. “Hacker” is another meaning that’s been abused, to the point of making it ambiguous and confusing. Of course, you’re unlikely to appreciate “software engineer” as a substitute, although truth be told it doesn’t seem inappropriate to me. It is, after all, the construction of a kind of machine, sometimes with tight tolerances (ever seen IEEE specs and the past controversy over Java’s adherence thereto?), albeit a virtual machine. (In the more general sense than when that machine is, specifically, a computer, as it is in an emulator, or in the case of Java’s runtime environment.)

    Of course, calling VB jocks who draw pretty pictures and bolt the resulting faceplate onto a database client backend “software engineers” turns my stomach, too. They’re more akin to the guys that design the front art and button labels for a vending machine, and the people poking records into the DB to the deliverymen who stock it. The engineer is the one who designed and built the actual machine, and he’s probably working for Oracle. And he’s probably a whole team, some of them architecting, some writing the code.

    Of course, now that we stretch the analogy this far, some of the coders amount to steelworkers welding the thing together. It depends on how much they’re actually anticipating, figuring out how to solve, and then solving problems and writing down the solutions in the form of algorithms, rather than just gluing stuff together.

Comments are closed.