Revisiting Adaptive Design, a lost design movement

15.22, Wednesday 26 Aug 2020

I was reminded today of Dan Hill’s work in the early 2000s on Adaptive Design – and it feels to me like this movement, focused on re-use, modularity, and unintended customisation, is one worth revisiting, almost 20 years on.

I’ll cover some history and then talk about why this matters.

One caveat: I was there but I can’t remember the references. Were there great introductory essays and brilliant reading lists, still relevant today? I don’t know. So I’m starting my archeology here.

The starting point is architecture

Adaptive Design was where I first heard of the book How Buildings Learn: What Happens After They’re Built by Stewart Brand (1994). It’s here that Brand introduces his “Shearing Layers” (here’s his diagram) which summarise the 6 layers of a building, and their different rates of change.

Site – geographical setting, eternal.

Structure – foundation and load bearing elements, 30-300 years.

Skin – 20ish years.

Services – 7-15 years.

Space plan – interior layout, from three (commercial) to 30 (domestic) years.

Stuff – furniture and belongings.

(The above taken from Phil Gyford’s notes on How Buildings Learn.)

Relevance to design? The architect creates the building up to the Space plan; the occupier adds their Stuff. But the occupier can also change the house, with some work, by changing the Space – knocking down interior walls and so on.

Critically, part to job of the architect is to design the Services (the electricity conduits, the water, the windows for light) to accommodate changes to the Space. The architect creates a platform for adaptation.

Concretely, take Levittown.

Levittown, New York (built 1947-1951) kickstarted American suburbia. And, um, refused to sell houses to people of colour…

The homes (there were four models) were built factory-style, on an assembly line.

And they were built for adaptation:

The houses were built unfinished. They had space on the side to build a garage. The ground floor was the only one delivered finished. There was space for a first floor, but it was left as an attic, and the stairs were incomplete and ran up to a blank wall.

(Quoting one of my own old presentations there.)

So the house can be extended. But, from an Adaptive Design perspective, the key is that house has the affordance of being extendable.

What does “affordance” mean? It means that the design visibly shows what is possible. Affordance is originally a term from biology and animal cognition, and it made its way into being design jargon.

As the house owner, you’d sit in your front room and notice that blank wall. It would give you the idea that extending into the attic was possible, even if you’d never have thought of it yourself. The blank wall would remind you, would entice you.

Not just architecture but the web too

The leap that Hill made with Adaptive Design was to talk about physical and digital in the same breath.

The early 2000s was the era of websites with APIs (an API is a way to automatically control a website with code, instead of doing it by hand). The photosharing website Flickr launched their API in 2004, which meant it could be adapted to all kinds of unexpected uses.

For example: The Royal Observatory, Greenwich, used the API to integrate the Flickr group with the museum’s Web site, develop a sophisticated competition administration tool, and produce interactive exhibits.

The web was made for Adaptive Design: from View Source (so people could learn how to make their own websites), to web feeds and APIs – websites could be pulled apart and recombined, and that was encouraged.

And there’s a dilemma with software, definitely. Would you prefer the 100% ideal to-do list user experience of a custom-made app, but you can’t copy-and-paste your lists anyway, or a powerful but often janky hacked-together Excel spreadsheet? Over the last 20 years, collectively, we opted for the former.

The question Adaptive Design poses:

How to enable not users but adaptors? How can people move from using a product, to understanding how it hangs together and making their own changes? How do you design products with, metaphorically, screws not nails?

How can our apps, our cameras, our furniture, our cars, and our home gadgets be less like closed-box appliances, and more like Levittown houses – allowing and even encouraging end user adaptation?

More reading: three essays from Dan Hill

This is a must-read essay by Dan Hill, introducing Adaptive Design: Insanely great, or just good enough? Originally published in Core77 in 2004, it’s a critique of the unadaptable, glued-closed Apple iPod and its non-user-replaceable battery.

Hill quotes Brian Eno:

An important aspect of design is the degree to which the object involves you in its own completion. Some work invites you into itself by not offering a finished, glossy, one-reading-only surface. This is what makes old buildings interesting to me.

Also check out:

Me? I got into the idea that hardware products could be adaptable too. What if cameras and photocopiers had hackable hardware APIs? We even built a radio for the BBC with a hardware API.

Adaptive Design developed language around modularity, layers, rough edges, and widgets. It went from architecture to APIs, via affordances and co-creation.

Why is this important now

We’re in an era of No User-Serviceable Parts Inside.

  • Laptops and phones that invent new types of weird screws to prevent you from opening them up and changing the battery
  • Apps that hang on to your data, like posts or photos or your social network, and never let it go (we forget how open and scriptable both websites and desktop applications were).
  • We no longer own our movies, books, and software, but rent them, with our rights tightly constrained.

And so it’s a challenging and provocative question to ask of any product design right now:

  • How can the end user adapt this product?
  • How can the end user know they can adapt this product?
  • How can the end user be encouraged? How can friction be reduced? How can an amateur learn, and an expert develop? How can adaptations and expertise alike be shared?
  • And how can this adaptability be in alignment with business model of the developer/manufacturer, not fight it?

Looking around me right now, I have Sonos speakers in three rooms in the house. In my imagined 2020, the BBC would produce a podcast feed of 2 minute radio news bulletins, updated on the hour. I would write a short script to grab that podcast, and send the latest bulletin to the speakers, interrupting whatever is currently playing.

I’d be able to write an app for my TV as simply as writing a webpage. It would be an example of personal software and take over “Standby” mode for me and my family, wherever we are in the world, providing one-click to FaceTime whenever we’re online at the same time.

I want to take a photo of my bookshelves, OCR it, and link every book to Amazon’s “Search Inside” functionality because - in my imaginary 2020 - they have an open API for book ISBNs. All in a couple lines of code.

I want my house to come with a wiki that I write on, and my electricity meter writes on too, and that my front door lock consults for a list of people who are allowed in. I recently touched on why the smart home failed for strategic reasons: every big tech company wants to ‘own’ voice interactions, and be a gatekeeper to all smart devices. The smart home failed because it ignored the lessons of Adaptive Design.


That early work on Adaptive Design has already done the hard digging of finding reference points and developing frameworks to guide product design for adaptation - it’s the anti Apple, the anti Amazon, the anti DRM. I’d love to see designers share their ideas for future adaptable iPhones and adaptable apps, expanding the discourse, and pushing back on the status quo. Adaptive Design is a movement worth reviving in 2020.


Update 1 Sept.

Hill’s 2006 essay Architecture and interaction design, via adaptation and hackability is a great standalone piece, and has a ton of takeaways about what Adaptive Design means as a concrete approach (rather than just saying “hey, here’s a perspective” which is what my post does above).

For me, I’ve found it helpful to think about different interactions with a product almost as different “modes” – for instance, with the web browser, there’s regular browsing and also the developer mode. Then Hill’s architectural terms, highlighted in this essay, come into play: “threshold” (how does a user consciously move between models); wayfinding (how are routes between modes signposted); screens (to mask depth).

This kind of thinking makes a product powerful and adaptable, but also not overwhelming.

And so on.

More posts tagged:
Follow-up posts: