Image and text source: City of Sound

May 23, 2006

Dan Saffer recently asked me to contribute some thoughts on adaptation, hackability and architecture to his forthcoming book Designing for Interaction (New Riders, 2006), alongside 10 other ‘interviewees’ such as Marc Rettig, Larry Tesler, Hugh Dubberly, Brenda Laurel etc. Dan’s been posting their various responses up at the official book site (see also UXMatters) yet he kindly agreed to let me post my full answers below (the book will feature an excerpt).

The questions he posed were: Can products be made hackable, or are all products hackable? What types of things can be designed into products to make them more hackable? What are the qualities of adaptive designs? You’ve spoken on putting “creative power in the hands of non-designers.” How do interaction designers go about doing that? What can interaction designers learn about adaptability from architecture?

Given this, Dan had inadvertently provided me with the impetus to get down a decent summary to a few years’ worth of thinking around this subject. So what follows directly addresses one of the stated purposes behind this blog: to see what we can draw from the culture and practice of architecture and design into this new arena of interaction design – and some of the issues in doing so. (An unstated purpose of the blog – of providing me with an indexed notebook – is also fulfilled!) Here goes:

Can products be made hackable, or are all products hackable?

At our panel at DIS2004, Anne Galloway defined designing for hackability as “allowing and encouraging people to make technologies be what they want them to be.” Yet, as the architect Cedric Price might have said,” technology is the answer, but what is the question”?

Because effectively, all products are hackable. If we define a hackable product as ‘a product capable of being modified by its user’ then we’ve seen pretty much everything hacked. That definition is fairly broad, but hacking itself has a long history. At MIT, ‘hacks’ consisted a wide repertoire ingenious pranks, mostly physical; it was taken simply to mean “an appropriate application of ingenuity”. In this sense, ‘hacking’ of products has a long as history as industrialised production itself. Adaptation in general predates it of course.

But if this definition appears too wide to be useful, it’s worth noting the range of products that have been hacked, apparently irrespective of size, solidity, complexity. Cars have been hacked – witness the ever-vibrant custom car movement; buildings are endlessly modified and customised from day one; clothes often are; musical instruments often are; even apparently perfectly finished ‘modernist’ products like Dieter Rams’s Braun hi-fis have been heavily modified. Likewise the iPod, despite its hermetically sealed appearance.

Software is incredibly malleable of course, even that which is explicitly designed not to be hacked (cf. operating systems, digital rights management software etc.).

Essentially, all products lives start when in the hands of the consumer, long after the designer has waved bye bye. Design is a social process. This reinforces the idea of adaptation as a basic human desire. This should really be a question of can products be purposefully made more or less hackable? If we take the starting point that all products are intrinsically hackable – as the life of a product starts with the user, not the designer – the question is how do we design products that engender useful hacking?

That word ‘useful’ means we should bring in Tom Moran’s thinking, as he suggests that designers have lately been obsessed with usability at the expense of usefulness. If we truly wish to design products that are useful, that may mean letting the user in to the creative process, into the life of the product. For users are the ultimate arbiter of usefulness. So we should ask, as designers, how can we make products more useful through enabling adaptation, aka ‘hacking’.

What types of things can be designed into products to make them more hackable?

For me, this indicates a reversal of some traditional design thinking. The maxim that “when design’s working properly you don’t notice it.” (this last from Germaine Greer, no less) is less useful with hackability in mind. If we are to invite the user in, we need to leave some of the seams and traces open for others to explore; some sense of what the process of design, or un-design, might entail. Naoto Fukasawa’s idea that “good design means not leaving traces of the designer” makes sense in terms of reinforcing humility in the designer, but leaving traces of the design itself may be very useful to users.

Matthew Chalmers suggests we indicate a product’s ‘seams’, in order that it might convey how it can be appropriated or adapted. This is beyond affordances (which concern predefined usage). This sense that the fabric of the product should communicate its constituent parts and how they are assembled runs counter to ‘invisible computing’ thinking and much user-centred design, which argues that interfaces should get out of the way. Yet Chalmers’ notion of “seamful systems (with beautiful seams)” is powerful when seen in the context of enabling hackability.

For example, the seams on a musical instrument are quite often visible, particularly those that have evolved over centuries. Pianos intrinsically communicate which aspects make noise – their basic affordances in this case – yet opening the lid reveals further hackable aspects. Numerous musicians have modified the keys and strings to produce different effects, essentially unintended by the instrument’s designers. Electric guitars quickly communicate their operational ‘noise-making’ components; while these instruments take a lifetime to master, their approachability means that a wide range of interaction is possible within minutes. And their obvious ‘seams’ clearly enable hackability, as witnessed in the vast numbers of guitars customised in apparently infinitely ways. (Related to this could be an appropriation of Kevin Lynch’s urban planning concept of ‘imageability’ i.e. how clearly the essential architecture of a system can be envisaged.)

Tangentially, the support structures around products enable hackability i.e. facilitating learning, creating communities of interests around products. This needn’t necessarily mean instruction manuals. Bearing in mind Brian Eno’s suggestion that manuals are to be immediately put away in a drawer, we have to find ways of communicating the possibilities of products in engaging ways. Eno is able to suggest this as the musical instruments he’s describing are often brilliantly designed interfaces, honed by hundreds of years of refinement, as noted above. Yet each is also supported by thriving communities, particularly online. Creating a discursive social space around products can enable hackability, and it’s important that designers show up here, in messageboards, blogs, community sites and other forms of discourse – many great architects and designers have been great communicators first and foremost.

These techniques work to varying degrees across objects, either hardware or software. In the latter, there is a huge amount of learning in code – as suggested above, its malleable essence means that hackability is almost a pre-requisite. Some of the basic conditions of code could be abstracted into useful analogues for hackability, as many products increasingly become the domain of code. For instance, the concepts of open source, object-oriented programming and relational databases, application programming interfaces (APIs) or representational state transfer (REST). The latter indicates the value of allowing distinct objects or resources (nouns) to communicate with and modify each other, using basic well-defined operations (verbs) without having any unnecessary detail of the other’s existence or particular operational requirements (polymorphism). In a sense, this suggests a set of interchangeable yet malleable Lego bricks: universally unique shapes; clearly defined ways of connecting; sets of basic operations which can be applied across numerous shapes and functional components in order to build numerous new shapes and functions …

At a more basic level, on a website, a hackable URL indicates both the structure of the site and some sense of how to move through it. A URL designed to be read only by machines presents no hooks for the user to try out. Deeper than URLs, more complex informational products, such as Amazon, Google etc., all offer varieties of web services to elements of their databases, over relatively controlled APIs. This encourages hackability with these products – with the end result that product design innovation blooms around their offerings and their services are increasingly thought of as the ‘wiring’ of the internet (in Stewart Brand’s terms, at the services layer). So this principle involves machines being able to interpret particular layers, and ignore – or not even see – others. This is another core feature of hackability and adaptation, which seem very close in definition here (perhaps the former indicates a less graceful, more earthily pragmatic way of appropriating and reconfiguring products. The vocabulary is littered with “hooks, sockets, plugs, handles etc” rather than stability through more stable layers or graceful refinement over time etc.). There are certain some basic architectural principles which apply i.e. enabling these different ‘layers’ to move independently of each other. More on this later.

As the distinction between hardware and software blurs, their behaviour approaches the malleability of software. Arguably the most interesting things about these emerging products and devices is their ability to create or contribute towards a sense of self – both in terms of the product and the owner. As products get smarter in terms of being aware of their behaviour – in some senses, becoming reflexive – and as their raison d’être gets increasingly close to personal, social functionality – in some senses, becoming involved in presentation of self and the behaviour of the users – there is huge potential to build devices which become increasingly, personally meaningful, which can adapt to personal context and preference like never before.

This requires that the products have at least some ‘understanding’ of both their own behaviour – essentially, tracking their behaviour, usage patterns, and context wherever possible – and are built by both designers/researchers who understand ‘the social’ in depth, and can ultimately be adapted by their own users. It strikes me that the basic condition for these products is to be essentially self-aware. For example, this means that mp3 players without in-built system clocks are unable to infer when particular tracks are played, and therefore cannot communicate essential characteristics of its usage. So, increasingly, another basic condition of a hackable product’s design is its ability to communicate its state or behaviour over time.

So creating hackable products could include the following techniques:

* Make sure affordances and seams are clear and malleable.
* Enable interrogation, cloning and manipulation on particular layers
* Learn from the malleability, object-oriented nature and social behaviour of code
* Enable products which are self-aware in terms of behaviour/usage, which then present those findings back to users
* Enable products to emerge from this behaviour, as well as from design research
* Enable social interaction around products

What are the qualities of adaptive designs?

To some extent, they’re listed above. And yet I suggested a difference in vocabulary may reveal a deeper distinction. The discourse around hackability is often littered with “hooks, sockets, plugs, handles” and so on. With adaptive design, drawing from the language of architecture more than code, we have a more graceful, refined vocabulary of “enabling change in fast layers building on stability in slow layers”, “designing space to evolve”, “time being the best designer” and so on. This suggests that there could be a distinction; that adaptive design is perhaps the process designed to enable careful articulation and evolution, as opposed to hackability’s more open-ended nature.

However, they still draw from the same basic concepts: of design being an ongoing social process between designer and user; of products evolving over time; of enabling the system to learn across an architecture of loosely-coupled layers; of not over-designing … They can be summarised from Tom Moran’s definition and extended thus:

* Think of platforms, not solutions – overbuild infrastructure, underbuild features
* Build with an architecture of layers; enable fast layers to change rapidly (learning); slower layers enable stability
* Create seamful experiences, based around behaviour not aesthetics; often includes modular design
* Undesigned products, or rather not overdesigned; to invite the user in, to encourage evolution
* Define vocabularies, or basic patterns of interaction
* Leave space to evolve (if physical/spatial, build with modular shapes which can extend easily)
* Enable users to manage the at-hand information and interactions; the surface layers
* Create an aesthetic of ongoing process (this could engender trust)
* This process implies that the designer provides support, engagement over time etc.

In adaptive design, designers must enable the experience/object to ‘learn’, and users to be able to ‘teach’ the experience/object. So, it’s a two-way interaction, in which the user wants to adapt the product, to make it useful to him or her. Therefore the designer must concentrate on enabling this adaptation in order to achieve a useful experience, rather than attempting to direct the experience towards usefulness themselves. Designers shouldn’t aim to control, but to enable.

Again, this implies a process long after the traditional ‘up-front design phase’ of projects. The process of design starts when the user gets their hands on it; ideally, the designer stays engaged in a collaboration, a support function, a modification function and so on. This last – modification – is hugely important, as it reinforces this idea that adaptive products are a process. There will be financial implications, positive and negative, of such an approach if based on standard business models.

You’ve spoken on putting “creative power in the hands of non-designers.” How do interaction designers go about doing that?

Two sides to this. Firstly, in order to create these more adaptable products, interaction designers will need to work within multidisciplinary environments, communicating coherently with software developers and other disciplines. This means really understanding code; doesn’t necessarily mean coding, although that can be a useful communications medium. Secondly, interaction designers will need to work with these non-designers, often directly. The notion of design being an ongoing, social process means that designers have a responsibility to work with products and experiences after they’ve launched. This doesn’t necessarily fit many of the development methodologies, and indeed business models, that interaction designers traditionally work in. But putting designers into direct contact with non-designers will enable them to truly adapt products to their own needs, creating genuinely engaging experiences. This is a form of design literacy, perhaps, but also product literacy. It should mean being transparent in one’s practice rather than obscuring the process of design.

There’s a theme of humility running through adaptive design; of making the ‘designer-as-personality’ invisible, foregrounding the design itself, as a shared terrain. This also invites the non-designer in. This partnership aims to nurture well-designed solutions from people, rather than attempting to complete generalised products. (In order to mitigate against damage, the architecture of layers should provide stability – in the slow layers (site, structure) – to enable change in fast layers (surface, skin etc.), as long as layers are not too tightly bound.)

Increasingly, there’s a role for designers to create systems which in turn enable design, offering tools, not solutions. Paul Dourish has described this fundamental change in the “designer’s stance”. Dourish wrote:

“The precise way in which the artifact will be used to accomplish the work will be determined by the user, rather than by the designer. Instead of designing ways for the artifact to be used, the designer instead needs to focus on ways for the user to understand the tool and understand how to apply it to each situation. The designer’s stance is revised as the design is less directly “present” in the interaction between the user and the artifact. So in turn, the revised stance will result in a different set of design activities and concerns … In particular, the designer’s attention is now focused on the resources that a design should provide to users in order for them to appropriate the artifact and incorporate it into their practice.” (From ‘Where the Action Is: The Foundations of Embodied Interaction’, Paul Dourish, MIT Press 2001)

We can see evidence here of designers and developers producing frameworks for others to create with. (Dourish also writes perceptively of the need to provide users with a conceptual understanding of the fundamental artefacts of computer science.) At the entry level, an example of this kind of work would include creating an interface and system for Blogger that didn’t necessarily extend its functionality, but did extend the type of users who could use it; creating a system that enables meaningful design opportunities for others. An example of a more complex offering would be Ning, the social web app generator, which creates a community around building web applications. After providing many of the basic feature-sets of web applications, Ning enables non-developers to create applications by assembling them in numerous ways, or simply cloning. At the most complex end, frameworks for software engineering, Ruby On Rails takes a similar ‘toolkit’ or ‘framework’ approach to development. All these products attempt to make previously complex things easier and quicker; all involve designers and developers collaborating to produce layered systems which enable users – non-designers – to explore creativity at faster-moving layers.

Professional designers have little to fear here. The premise is: everyone is a designer, yet some of us do it for a living. In this sense, interaction design may emerge as the kind of variegated practice that we see in more mature activities e.g. home-improvement and vernacular architecture. Many people practice DIY home improvement, with home-makers able to construct and modify many things for themselves – indeed using tools and guidelines set by professionals – but if they want something more complex, they get professional designers, builders and architects involved. Amateur practice, literacy, toolkits and professionalism; all present simultaneously.

What can interaction designers learn about adaptability from architecture?

This is a complex question, as people veer back and forth on this: on the one hand reading too much into the parallels between architecture and interaction design; on the other, saying it’s so radically different that we have nothing to learn. Yet rather than creating some kind of grand unified theory of construction, I prefer to pick and choose elements of architectural practice, theory and history; then try them on for size. Here’s a few examples:

Of course, much of the thinking behind adaptive design is influenced by a few key architectural principles, embodied in a couple of books: Stewart Brand’s ‘How Buildings Learn’ and Christopher Alexander’s ‘A Pattern Language’. (Neither of which appear to be particularly widely accepted/respected by the mainstream architectural community, interestingly.) Both place design, architecture and building closer to the hands of non-designers than architects, essentially highlighting the beauty and usefulness of vernacular architecture based on hundreds of thousands of years of refinement of practice. (Although Brand covers the area of vernacular architecture thoroughly, other books are relevant here, such as Bernard Rudofsky’s ‘Architecture without Architects’, or perhaps Robert Venturi’s ‘Learning From Las Vegas’ which covers a more contemporary vernacular.)

Additionally, I’d add in the work of 1960s British architects Cedric Price, Archigram and The Smithsons, all of whom attempted to develop architectural systems which were modular, adaptive, malleable, reactive, indicating development over time, and so on.

Some recent ‘interactive architectural’ thinking around learning from biological systems is highly apposite here too – Janine Benyus has suggested that natural organisms adapt brilliantly, taking the ‘long view’, and all without creating unsightly areas or industrial zones too! She believes that “life creates conditions conducive to life” and talks of “a pattern language for survival”, echoing Christopher Alexander. Watch that space.

The above have demonstrated various aspects of adaptability in architecture. Most of these concepts – layers moving at different paces; patterns being reused; products evolving over time etc – are inspired by architecture, such that while hackability has a basis in code, adaptability is essentially associated with this slower process of physical architecture. So the basic practice of designing for adaptation is largely learnt from architecture, whether that’s those emotionally resonant, genuinely useful, ‘good enough’ vernacular solutions or carefully articulated, highly complex systems built by professionals.

In terms of drawing further, there are some basic architectural concepts which can be useful items of vocabulary, or suggest different ways of thinking. For example, the following architectural terms:

* ‘threshold’ (articulating the transition between spaces)
* ‘view’ and ‘route’ (basic wayfinding components)
* ‘screen’ (a masked element, usefully concealing depth)

And so on. These are several architectural concepts that could provide insight when applied to interaction design problems.

The practice of ‘post-occupancy evaluations’ (POEs), highly recommended by Brand, also seems relevant. This entails visiting and evaluating the building sometime after it has been constructed, when the occupants have been firmly ensconced. The POE is intended to see how people actually used the building, both in order to modify the environment if necessary but also for the architects to learn. This echoes the idea of design as process, and reminds designers to engage as much as possible with products or experiences after they’re constructed; that the life of the design starts with the user, as opposed to ending with the designer. Most architectural projects do not conduct thorough regular POEs, due to financial constraints; it would be worth thinking about how interaction design can perform the equivalent POEs in such a way that makes financial sense.

A further learning from architecture is one of context. Good architecture considers the environment the building is to be situated within, and designs accordingly. The context of buildings in a city, or rural/natural environment, should shape the project significantly. The Finnish architect Eliel Saarinen said: “Always design a thing by considering it in its next larger context – a chair in a room, a room in a house, a house in an environment, an environment in a city plan.” Interaction design can learn much from this, whether that’s the context of use of objects – backed up by ethnographic design research – or from the multiple entry points or adjoining experiences of work on the web. In the latter, too many design projects have sharp ‘edges’ around the site; and yet few sites are hermetically sealed, coherent experiences from the users point-of-view.

Cities and urban theory provides much of use here, in addition to the Kevin Lynch ‘imageability’ concept mentioned earlier. Richard Sennett wrote:

“Cities are places where learning to live with strangers can happen directly, bodily, physically, on the ground. The size, density, and diversity of urban populations makes this sensate contact possible – but not inevitable. One of the key issues in urban life, and in urban studies, is how to make the complexities a city contains actually interact.” [‘Capitalism and the City’, Richard Sennett, Zentrum für Kunst und Medientechnologie Karlsruhe]

Interaction design is often working in such a “dense, diverse” interactive environment, and so a sense of adaptation should be front of mind. This sense of plasticity and malleability of identity in cities and their citizens is also described well in Jonathan Raban’s book ‘Soft City’.

Given the lengthy history of architecture, and the comparative embryonic development of interaction design, there are some things we should pull from its organisation too. It’s useful that architecture has an intrinsically multidisciplinary nature – hovering between science and art – as this echoes the multidisciplinary nature of interaction design, comprising elements of information architecture, interface design, graphic design, software development, design research and so on. Architecture provides a useful counterpoint to the ‘Two Cultures’ split between science and humanities often witnessed in other professions. The emphasis on the architectural team, and the agency of the engineering firm within this process too, helps balance the sometimes unhelpful amount of column inches that the ‘starchitects’ can get. There is also a healthy discourse, with an ancient history, around architecture, ranging from industry publications through to thriving blog scene. Again, all things for the profession of interaction design to aspire to.

However, we should be wary of aping architecture for the sake of it; some of the above would apply equally to other professions; other professions may provide equally inspirational yet entirely different learning. There’s no need to lift some of the more depressing or stultifying elements of architecture into a relatively young field, too. For instance, risk will always be managed differently across the two disciplines, given architecture’s intrinsic ability to fall over. (Only elements of interaction design would have similar impact, albeit increasing amounts). Equally, criticism and discussion in architecture can be infuriating; witness the rhetoric around the New Urbanist battlefront. (See also Geoff Manaugh’s impassioned and constructive broadside on the paucity of much writing about architecture.)

Yet, in my view, drawing selectively from the riches of thousands of years of architectural development, both professional and vernacular, can only be a good thing in such a nascent field as interaction design.