There are lots of models of human behaviour, and as the design of systems becomes increasingly focused on people, modelling behaviour has become more important for designers. As Jon Froehlich, Leah Findlater and James Landay note, “even if it is not explicitly recognised, designers [necessarily] approach a problem with some model of human behaviour”, and, of course, “all models are wrong, but some are useful”. One of the points of the DwI toolkit (post-rationalised) was to try to give designers a few different models of human behaviour relevant to different situations, via pattern-like examples.

I’m not going to get into what models are ‘best’ / right / most predictive for designers’ use here. There are people doing that more clearly than I can; also, there’s more to say than I have time to do at present. What I am going to talk about is an approach which has emerged out of some of the ethnographic work I’ve been doing for the Empower project, working on CarbonCulture with More Associates, where asking users questions about how and why they behaved in certain ways with technology (in particular around energy-using systems) led to answers which were resolvable into something like rules: I’m talking about behavioural heuristics.

Behavioural heuristics

The term has some currency in game theory, other economic decision-making and even in games design, but all I really mean here is rules (of thumb) that people might follow when interacting with a system – things like:

▶ If someone I respect read this article, I should read it too

▶ If this email claiming to be from my bank uses language which makes me suspicious, I should ignore it

▶ If I’ve read something that makes me look intelligent, I should tell others

▶ If that Go Compare advert comes on, I should press ‘mute’

▶ If the base of my coffee cup might be wet, I should put it on something rather than directly on the polished wooden table

▶ If, when asked which of two cities has a bigger population, I have only heard of one of them, I should choose that one

▶ If my friend posts that she has a new job, I should congratulate her

▶ If there’s a puddle in front of me, I should walk round it

▶ If there’s a puddle in front of me, I should jump in it

▶ If I’m short of time, I should choose the brand name I recognise

▶ If I have some rubbish, and there’s a recycling bin nearby, I should recycle it

▶ If I have some rubbish, and there isn’t a recycling bin nearby, I should put it in a normal bin

▶ If that bench is wet or dirty, I should sit somewhere else

▶ If lots of my friends are using this app, I should try it too

▶ If there are lots of pairs of seats empty on the train, I should sit in one of them rather than sitting next to someone already occupying one of a pair

▶ If I can’t see the USB logo on the top of this connector, I should turn it over before trying to plug it in

▶ If I can’t get the USB cable to plug in properly, I should force it

▶ If seats are positioned round a table, I should sit at the table

▶ If I’m trying to lose weight, I should try to choose food with less fat in it

▶ If this envelope has HM Revenue & Customs on the back, I should open it

▶ If this envelope is from BT and printed on shiny paper, I should shred it immediately without bothering to open it

▶ If this website asks me to fill in a survey, I should click cancel immediately

▶ That urinal spacing thing. You know what I mean.

These are a mixture of instinctive or automatic reactions (a kind of ifttt for people) and those with more deliberative processes behind them: the elephant and rider or Systems 1 and 2 or whatever you like. Some are more abstract than others; most involve some degree of prior learning, whether purely through conditioning or a conscious decision, but in practice can be applied quickly and without too much in-context deliberation (hence at least some are ‘fast and frugal’, in Dan Goldstein and Gerd Gigerenzer’s terms). Some heuristics could lead to cognitive biases (or vice versa); some involve following plans, some are more like situated actions. And of course not all of them are true for everyone, and they would differ in different situations even for the same people, depending on a whole range of factors.

Truth tables for people

Regardless of the backstory, though, each of these rules or heuristics potentially has effects in practice in terms of the actual behaviour that occurs. They are almost like atomic black boxes of action, transducers* which when connected together in specific configurations result in ‘behaviour’.

We might construct ‘behavioural personas’ which put together compatible (whatever that means) heuristics into persona-like fictional users, described in terms of the rules they follow when interacting with things, and both (admittedly crudely) simulate** their behaviour in a situation, and, maybe more importantly, design systems which take account of the heuristics that users are employing.

If we know that our fictive user is following a “If someone I respect read this article, I should read it too” heuristic, then designing a system to show users that people they respect (however that’s determined) read or recommended an article ought to be a fairly obvious way to influence the fictive user to read the article. If we know that he or she also follows related heuristics in other parts of life, e.g. the “If I’ve read something that makes me look intelligent, I should tell others” rule, then this action could also be incorporated into the process.

There are two main objections to this. One: it’s obvious, and we do it anyway; and two: treating people like electronic components is horrible / grotesquely reductive / etc. I don’t disagree with either, but am nevertheless interested in exploring the possibilities of using this kind of modelling, simple and lacking in nuance as it is, to provide a way of navigating and exploring the many different ways that design can influence behaviour. If we could do contextual user research with this kind of heuristic as a unit of analysis, uncovering how many users in our situation are likely to be following different heuristics, we could design systems which are not just segmented but tailored much more directly to the things which ‘matter’ to people in terms of how they behave.

Trying it out: thank you, Dublin guinea-pigs

At Interaction 12 last week in Dublin, 41 wonderful people from organisations including Adaptive Path, Google and Chalmers University took part in a workshop exploring the idea of these heuristics and how they might be used in design for behaviour change.

What we did first was a kind of rapid functional decomposition (in the Christopher Alexander sense) on a few examples where systems have been designed expressly to try to influence user behaviour in multiple ways.

The example I worked through first though was a simple decomposition of Amazon’s ‘social proof’ recommendation system: the point was to try to think through some of the ‘assumptions’ about behaviour that can be read into the design, and using a kind of laddering / Five Whys process, end up with statements of possible heuristics.

So with the Amazon example here, what are the assumptions? Basically, what assumptions are present, that if true would explain how the system ‘works’ at influencing users’ behaviour? What I have glibly classified as simply social proof contains a number of assumptions, including things like:

▶ People will do what they see other people doing

▶ People want to learn more about a subject

▶ People will buy multiple books at the same time

And many others, probably. But let’s look in more detail at ‘People will do what they see other people doing’: Why? Why will people do what they see other people doing? If we break this down, asking ‘Why?’ a couple of times, we get to tease out some slightly different possible factors.

After a couple of iterations it’s possible to see some actual heuristics emerge:

Of course there are many possible heuristics here, but for the five uncovered, it’s not too difficult to think of design patterns or techniques which are directly relevant:

There’s nothing there that isn’t obvious, but I suppose my point is that each heuristic implies a specific design feature, and the process of unpicking what the actual decision-points might involve gives us a much more targeted set of design possibilities than simply saying ‘put some social proof there’. Depending on the heuristics uncovered, it might be that simple majority preference (the Whiskas ad), irritating pseudo-authority-based messaging (Klout), friend-based recommendation (Facebook apps), peer voting (Reddit) or even celebrity/expert endorsement (John Stalker and Drummer endorsing awnings) could match individual users’ heuristics better.

Sometimes a service will use more than one, to try to satisfy multiple heuristics, or perhaps because the designers are not sure which heuristics are really important to the user (e.g. the This Is My Jam example below). In some ways, this process is approaching the kind of ‘persuasion profiling’ being pioneered by Maurits Kaptein, Dean Eckles and Arjan Haring’s Persuasion API, although from a different direction.

In the workshop, groups did a similar decomposition on three examples: Codecademy, Opower and Foodprints, part of More Associates’ CarbonCulture platform – the introductory material is reproduced below.

For each of these, groups extracted a handful of statements of possible heuristics – for example, for Opower, these included:

▶ If my neighbour can do it, I can do it

▶ If life’s a competition, I want to win it

▶ If I set myself goals, I want to meet them

▶ I don’t want to be the ‘weak link’, so I should do it

▶ I want to be ‘normal’, so I should do it

▶ [If I do it] I will be better than other people

▶ If I get apprecation from others, I will continue to do it

▶ If it stops me being the ‘bad guy’, I will do it

▶ If it stops me feeling guilty, I will do it

▶ [If I do it] I will improve myself

▶ If I don’t do it, I won’t fit in

▶ If I save money, I’ll have it for other things

▶ [If I do it] I will be a ‘good’ person

▶ [If I don't do it] bad things will happen

We went on to swap some of the heuristics among groups, and build them up into relatively plausible (if completely fake) personas, ranging from a “goth who doesn’t want to do what others do”, to Fido, a guide dog intent on helping his partially-sighted owner Bob (as SVA’s Lizzy Showman mentions here).

In turn, the groups then used the DwI cards as inspiration to generate some possible concepts in response to a brief about keeping that person (or dog) engaged and motivated as part of a behaviour change programme at work, around behaviours such as exercise, giving better feedback and so on. Finally, groups acted these out (photo below shows Fido and Bob!).

Where does all this fit into a design process?

What was the point of all this? The aim, really, is ultimately to provide a way of helping designers choose the most appropriate methods for influencing user behaviour in particular contexts, for particular people. This is what much design for behaviour change research is evolving towards, from Stanford’s Behaviour Wizard to Johannes Zachrisson’s development of a framework.

I would envisage that with user research framed and phrased in the right way, observation, interviews and actual behavioural data, it would be possible to extract heuristics in a form which are useful for selecting design patterns to apply. While in the workshop we ‘decomposed’ existing systems without doing any real user research, doing this alongside would enable the heuristics extracted to be compared and discrepancies investigated and resolved. The redesigned system could thus match much better the heuristics being followed by users, or, if necessary, help to shift those heuristics to more appropriate ones.

Ultimately, each design pattern in some future version of the DwI toolkit will be matched to relevant heuristics, so that there’s at least a more reasoned (if not proven) process for doing design for behaviour change, using heuristics as a kind of common currency between user behaviour and design patterns: user research → extracting heuristics → matching heuristics to design patterns → redesigning system by applying patterns → testing → back to the start if needed

In the meantime, my next step with this is to do some more extraction of heuristics from actual behavioural data for some particular parts of CarbonCulture, and (as my job requires) put this process into a more formal write-up for an academic journal. I will try to make some properly theoretical bridges with the heuristics work of Gerd Gigerenzer, Dan Goldstein and (as always) Herbert Simon. But if you have any thoughts, suggestions, objections or otherwise, please do get in touch.

Thanks to everyone who came to the workshop, and thanks too to the Interaction 12 organisers for an impressively organised conference.

* In reality, the rules have to be able to degrade if the conditions are not met: people are maybe following nested IF…THEN…ELSE loops rather than individual IF…THEN rules. Or perhaps more likely (this thought occurred while talking to Sebastian Deterding on a bus from Dun Laoghaire last week) a kind of CASE statement – which would take us into pattern recognition and recognition-primed decision models…
**Matt Jones suggests I should read Manuel deLanda’s Philosophy and Simulation, which fills me with both excitement and fear…

Image sources: ‘If…’ movie poster; Whiskas ad; Nationwide awnings

A couple of weeks ago, at dConstruct 2011 in Brighton, 15 brave participants took part in my full-day workshop ‘Influencing behaviour: people, products, services and systems’, with which I was very kindly assisted by Sadhna Jain from Central Saint Martins. As a reference for the people who took part, for me, and for anyone else who might be intrigued, I thought I would write up what we did. The conference itself was extremely interesting, as usual, with a few talks which provoked more discussion than others, as much about presentation style as content, I think (others have covered the conference better than I can). And, of course, I met (and re-connected with) some brilliant people.

I’ve run quite a few workshops in both corporate and educational settings using the Design with Intent cards or worksheets (now also available as a free iPad app from James Christie) but this workshop aimed to look more broadly at how designers can understand and influence people’s behaviour. This is also the first ‘public’ workshop that I’ve done under the Requisite Variety name, which doesn’t mean much different in practice, but is something of a milestone for me as a freelancer.

In the previous post I outlined what I had planned, and while in the event the programme deviated somewhat from this, I think overall it was reasonably successful. Rather than using a case study (I feel uneasy, when people are paying to come to a workshop, to ask them effectively to do work for someone else) we ran through a series of exercises intended to explore different aspects of how design and people’s behaviour relate to each other, and perhaps uncover some insights which would make it easier to incorporate a consideration of this into a design process.

Heuristics and decision-making exercise

After a brief introduction to how design has been and is being used to influence people’s behaviour, we ran through a few questions together intended to explore the idea of heuristics and biases in decision-making. Some questions addressed ‘classic’ behavioural economics issues such as sunk costs, loss aversion and recency/primacy effects—which can all affect users’ interaction with a system. Drawing on the project around energy use in which I’m currently involved with More Associates, we also looked at some heuristics issues relating to users’ interaction with systems across physical/digital interfaces, such as whether the salience of ‘visible’ things such as lighting leads people to overestimate how much energy they use compared with ‘invisible’ systems such as heating and air-conditioning. We briefly looked at anchoring effects and how menu designers use them, and discussed the potential upside of certain heuristics in certain circumstances, such as Gerd Gigerenzer’s ‘fast and frugal’ heuristic [PDF], and how thinking along these lines might result in more intuitive interfaces.

The main insights from this first session were:

• people use heuristics—sets of simple decision-making rules—to work out what to do in different situations, including using products and services

• they’re often relatively sensible and efficient, based on experience and pattern recognition, but can sometimes lead to biases and poor decisions

• so, understanding the heuristics your users use in making decisions about how to interact with your system is important, especially if you’re seeking to influence their behaviour in some way

Black boxes and mental models

Each group received a ‘black box’, an unknown electronic device with an unlabelled interface of buttons, ‘volume’ controls and LEDs. The boxes were children’s lunchboxes from Poundland. Internally—and thus secretly—each box also contained a wireless transmitter, receiver, sound chip and speaker (basically, a wireless doorbell), and in one box, an additional combined buzzer and klaxon. The aim was to work out what was going on—what did the controls do?—and record your group’s model of how the system worked in some form that could explain it to a new user who hadn’t been able to experiment with the device.

Because of the hidden functionality, the boxes’ operation was more complex than might initially have been apparent, and as it was realised that the boxes ‘interacted’ with each other, by setting off sounds in response to particular button-presses, the models generated by groups became more complex. Each group used slightly different methods to investigate and illustrate the system model—an exhaustive kind of state transition table/truth table, a user manual-style annotated diagram of the device, and a diagram focusing on each button or control in turn and elaborating its function. The investigation methods themselves differed slightly, with unexpected behaviour or coincidences (one group’s box setting off the doorbell in another, but coinciding with a button being pressed or a volume control being turned) leading to some rapidly escalating complex models.

The intended outcomes from this session were:

• trying to understand a new or unknown device essentially involves a user applying a number of heuristics to arrive at a mental model which seems OK, or satisfices

• representing and understanding models of system behaviour is difficult if you haven’t done it before, and there’s no universally agreed way of how best to do it to make sense to users

• models of complex systems may need to take into account the behaviour (or effects on) other actors, systems or contexts: very little in the world works entirely in isolation, and a systems approach to understanding technology needs to recognise the effects it has on society, and society on it

These three photos above by Sadhna Jain

Rules of interaction

Inspired by ‘Wizard of Oz’ testing and Eric Berne’s Games People Play, this exercise involved, in pairs, each person playing the role of either ‘device’ or ‘user’. Facing each other via a ‘screen’ made out of card, and each having a bowl of mixed sweets and toffees, each person picked up a (randomly drawn) set of rules for how to interact with the other—both an objective and a strategy for how to achieve it. The device’s objectives all involved ‘behaviour change’ in some way. The full list of objectives and strategies was as follows:

Device: Objectives
• Try to get all of a particular kind of sweet from the user—for example, all of the shiny-wrappered toffees.
• Try to get the user to eat as many sweets as possible—they can be yours or his/hers.
• Try to get the user not to eat any sweets at all.
• Try to get the user to get up and give his or her sweets to another user somewhere else in the room.

Device: Strategies
• Ignore the user’s understanding or attempts to engage with the situation. Don’t answer any questions, ignore everything the user says, and just keep demanding what you want to try to achieve your objective
• Ask questions to try to understand the user’s perspective, and try to come to an agreement which brings you both closer to your objectives.
• Try to trick the user somehow, e.g. by lying about what you’re trying to achieve
• Try to persuade the user to comply with your objective, by using reasoned, polite arguments to show that you are right.
• Assume the user just wants everything done as quickly and easily as possible, and emphasise that it’s easy to achieve that by doing what you say.
• Assume the user is very greedy, and will readily give up some sweets in return for ones he/she perceives as better. Make them seem desirable.

User: Objectives
• You want to keep as many as possible of your sweets, while acquiring the ones the device has got.
• You don’t want any of your sweets, but you do want the ones the device has got.
• You only want certain types of sweet (e.g. you want only ones with shiny wrappers).
• You want to find out more about the pros and cons of eating sweets, and you expect the device to tell you.

User: Strategies
• You just want things to be as easy as possible. Accept suggestions from the device as long as they’re reasonable.
• Ask lots of questions of the device. You want to understand and find out more about the options available to you, whatever they might be.
• Be open to trading / swapping sweets with the device, but don’t let it get the better of you.
• The device is your servant. Treat it accordingly.

The combination of objectives and strategies was intended to embody ‘assumptions’ about how the other (user or device) would act—in each case, to some extent a mental model of the system and the behaviour of its components. A device which, for example, assumes that “the user just wants everything done as quickly and easily as possible” is embodying a certain ‘designer’s model’ of how the user thinks and will behave.

When the interaction was ‘run’, some pairs quickly arrived at a negotiated result where both were happy, in the sense of their objectives and strategies being mutually compatible, while others reached a kind of stalemate. In at least one case, the device ‘won’ in persuading a user to give up her sweets against her own objectives. In practice, some pairs told each other what their objectives and strategies were, while others kept this secret; some possible lied about their objectives, consistent with the strategies given. Sometimes one person told the other his or her objectives, but the other ignored this (as per the strategy given). Some of the combinations were expected to lead to a degree of recursive second-guessing (the user assuming that the device is assuming that the user is assuming…) or knots, using R.D. Laing’s terminology, although it seems that the workshop participants were too sensible to let this happen!

The intended insights from this exercise were:

• when designers are trying to influence users’ behaviour, they do so with some model embodying assumptions about how users will behave and react to the way the product or service behaves (this is something we explored briefly in a workshop at UX London in 2010, which led to this paper and a forthcoming article in the Journal of Design Research)

• a product or service influencing a user’s behaviour can work best when the objectives of each side and the designer’s and user’s model of the system are compatible

• so, it is important to:
    • try to understand the models that users have of your system
    • design using strategies that match them

Exploring the environment

In the afternoon, we first went on a quick exploratory tour of streets around the workshop venue in the centre of Brighton, looking at some examples of designed situations or ‘interventions’ which aim to influence public behaviour in some way. (My direct inspiration here was Adam Greenfield and Nurri Kim’s excellent Systems/Layers Walkshop concept.) The main examples we examined and discussed were the (remains of the) Tidy Street energy graph, a CCTV camera on a tall pole with anti-climb spikes in the heart of one of the most ‘liberal’ towns in the UK, a ‘Scores on the Doors’ food hygiene rating scheme using stickers on the doors of restaurants and cafes, the conflicts between pedestrians, cyclists and drivers in shopping streets which may appear pedestrianised but aren’t (neatly illustrated by an irate driver shouting at us), and a touchscreen cider advertisement at a bus stop, which invites the public to rearrange ‘fridge magnet’ words to create a limited set of mostly positive messages about the cider which are then apparently submitted to the brand’s Facebook page.

In each case, the aim was to look at the situation from both the designers’ and the users’ points of view: what assumptions do the designers appear to have made about how the public will understand or interact with the product/service/thing? What behaviours are they trying to influence? What is the result? Who are the stakeholders in each situation? Are the designers aiming to target everyone, or only particular groups? (e.g., by asking an older lady waiting at the bus stop about the interactive touchscreen advert, we found that she had no idea that it was anything more than a static ad.) From a design perspective, what kind of research would need to be done to make the interventions more effective? We also considered briefly whether some of the techniques used might translate into other contexts—e.g., could the Tidy Street idea be applied to other statistics or figures in public space? (Marking crime hotspots was suggested.) Which sorts of physical interventions might translate easily into a digital context, and vice-versa?

Tools and processes exercise

Returning to the workshop venue, we spent the rest of the afternoon exploring the processes that each participant uses to research, design and evaluate whatever it is that he or she does, and through discussion together, identify how explicit consideration of user behaviour, mental models and heuristics might be incorporated if influencing behaviour is to be part of the designer’s brief. What tools do people use to incorporate insights from user research into the design process? What assumptions are made about how users think, and how are these assumptions tested? The thinking here was that not only did we have a room full of very experienced people working in a range of digital and other design disciplines, but that they all used slightly different processes, and some cross-pollination between that expertise might be valuable for everyone involved.

In particular, the issue of how the use of personas relates to understanding (and influencing) user behaviour arose from the discussion, since a number of participants’ processes make use of them: some of the main points raised were:

• How much determinism is inherent in rigid use of personas, designing with particular assumptions in mind about how people behave? Is there retrofitting of finished product behaviour to particular persona assumptions?

• The depth or superficiality of personas: do they include any real consideration of behaviour? Has any attempt been made to include a representation of users’ mental models as part of the persona? How might this be done?

• How fixed are personas? How often are they revised? Is there a feedback loop as part of your design process? Could you plan it to incorporate them? Can gathering behavioural data be designed into the product?

• How are edge cases / troublemakers / extreme users included in your personas?

• What about emergent or unexpected behaviours? Can the personas cope with these? How do you even find out what behaviours are emerging?

• Do your personas incorporate a treatment of the history and future relationship of the individual with the product / service / brand? What might this involve if you took changes in behaviour into account?

There were some great anecdotes about personas which I’d probably better not share as they’ll incriminate the participants, but the point to which much of this discussion seemed to be converging was essentially, what might a behavioural persona look like? Could personas even be defined in terms of mental models (“this is how a user with this mental model might behave”)?

Some other points raised in the discussion included:

• How might cultural probes and story construction be used to explore behavioural factors?

• Are different approaches to behaviour used at different levels of the design process? Are assumptions made at once stage which have to be ignored at another?

• Could there be a kind of cross-disciplinary checklist of heuristics or behavioural considerations to address at different stages?

• How much can the designers question the assumptions about users made by a client?

• Is bringing in external specialists such as ethnographers the best way to investigate user behaviour or could the ability be developed by the design team?

• In some cases, designers know exactly who their users are (e.g. for developing products used internally within a company). Could this be extended to consumer products?

• Is it possible for designers to experience products from a user’s point of view? How could you facilitate this?

In summary, then, the last session tried to look at how a treatment of behaviour, the factors affecting it, and how to influence it, might be built into the design processes that organisations currently use. While the Design with Intent toolkit and other great resources such as the Behavior Wizard, Mental Notes or Brains, Behavior and Design seem to have proved useful to many designers facing ‘behavioural’ briefs, I’m under no illusions that they offer a complete process. They don’t: they need proper research with users, to understand the contexts of behaviour and the ways that decisions are made, before trying to influence that behaviour through design. As the ‘Rules of interaction’ exercise demonstrated very simply, when the designer’s and user’s strategies and objectives aren’t aligned, behaviour is unlikely to change in the way the designer intends.

More photos on Flickr.

Thanks to Andy Budd and Kate Bulpitt at Clearleft for inviting me and organising things so well respectively, and to Sadhna Jain for helping out. Do have a look at some of her recent student projects. And thanks too to the participants for being so enthusiastic about what , on the face of it, might have seemed a rag-bag collection of exercises!

Photo by Sadhna Jain

I’m running a workshop on Wednesday 31st August at dConstruct 2011 in Brighton, and I thought it would be worthwhile explaining in a bit more detail what it’s about, and what we’ll be doing.

Here’s the summary from the dConstruct website:

 

Whether we choose to do it or not, what we design is going to affect how users behave, so we might as well think about it, and—if we can—actually get good at it. Bridging the gap between physical and digital product design, a systems approach can help us understand how people interact with the different touchpoints they experience, how mental models and cognitive biases and heuristics influence the way people make decisions about what to do, and hence how we might apply that knowledge (for good).

In this full-day practical workshop, we’ll try a novel approach to design and behaviour, using ourselves as both designers and cybernetic guinea pigs in exploring and developing a combination of physical and digital experiences. You’ll learn how to improve your own decision-making and understanding of how your behaviour is influenced by the systems around you, as well as ways to influence others’ behaviour, through a new approach to designing at the intersection of people, products, services and systems.
 

So what will the day actually involve? (You’re entitled to ask: the above is admittedly vague.) I’ve run quite a lot of workshops in the last couple of years, mainly using the Design with Intent toolkit in one form or another to help groups generate concepts for specific behaviour change contexts, but this one is slightly different, taking advantage of a full day to explore more areas of how design and behaviour interact, in a way which I hope complements dConstruct’s overall theme this year of “bridging the gap between physical and digital product design” usefully and interestingly. Also, the concept of ‘design for behaviour change’ is probably no longer new and exciting (at least to the dConstruct audience) in quite the way it might have been a few years ago: a more nuanced, developed, thoughtful exploration is needed. We’ll be using some of the Design with Intent cards throughout the workshop, but they’re not the main focus.

My plan is for the workshop to have four stages (3 shorter ones in the morning, 1 longer one for the afternoon):

1) Exploring cognitive biases, heuristics and bounded rationality in a design context

Through a short group exercise, we’ll investigate our own decision-making and thought processes—biases and heuristics which might mislead us, but which can also help us, in the context of using products and services (and how we assume users may use them). This section attempts to translate ideas which may be familiar from behavioural economics—Kahneman, Tversky, Thaler, Sunstein, Ariely and others—into technology applications, but also includes the work of people such as Gigerenzer and Goldstein, taking a different perspective on the idea of ‘bounded rationality’ and what it might mean when understanding how people really interact with products and services.

2) Black boxes, cybernetics and users’ mental models of systems

I’m not going to give too many details of this stage, since it’ll spoil the surprise. But (in groups) we’ll be trying to work out what’s going on with a set of unknown products—how they work, and how our behaviour (as users) affects what happens as part of a wider system. There will be breadboards, and LEDs, and cardboard boxes (probably not black), and maybe unexpected things. And Post-It notes, I expect.

3) Designers’ mental models of people’s behaviour

Again, I don’t want to give away too much here, but imagine a cross between a Wizard of Oz experiment, metagames, and some of the ideas discussed here. Basically, in pairs we’ll be playing users and products/services intended to influence behaviour, following our own strategies and seeing what happens. The outcomes of this will be compared (in structure if not in content) to some of R D Laing’s Knots, not to complicate them further(!) but to link them back to the systems/cybernetics perspective which emerged from 2).

4) Prototyping tools for understanding users and influencing behaviour

In the afternoon, the aim is—building on the insights from the morning—to create and develop tools for uncovering and understanding how users think and behave (and match these to design strategies), in a system context. We will have a ‘behaviour’ scenario to investigate, and the scope to examine it from different perspectives. Hopefully this will take in the existing knowledge and expertise some participants will have on user research methods, and build on this with some more explicitly behaviour-related insights. The result will be a set of methods and approaches which ought to be useful and applicable outside the workshop wherever understanding and influencing user behaviour, as part of a system, is needed, and which participants have played a part in creating. These will be documented so you’ll have something after the event as a reference.

If all that sounds like the sort of thing you’d find useful and interesting, there are still (at time of writing) a few workshop tickets available, which also get you into the conference. The workshop takes place at Clearleft’s offices at 28 Kensington Street, Brighton. Any questions / suggestions / ideas please do comment below.

Thanks to Clearleft for organising the conference—it’s been great the last couple of years, and I feel privileged to be part of it this year.

PS: Brighton Dome are right to ask you not to sit on the radiators, really. They’re old, and beautiful.

But there’s a lot of room for improvement. They’re systems where (unlike, say, a car) we don’t generally get instantaneous feedback on the changes we make to settings or the interactions we have with the interface. It’s a slow feedback loop. We don’t necessarily have correct mental models of how they work, yet the systems cost us (a lot of) money. How effectively do we use them? Around 60% of UK domestic energy use goes on space heating, and 24% on water heating. (See this Building Research Establishment report [PDF] for more detailed breakdowns.) That 84% cost me and my girlfriend £430 last year. It’s worth thinking about from a financial point of view, regardless of the environmental aspects.

Frankie Roberto and colleagues at Rattle Research have carried out a brilliant exercise in exploratory design thinking about central heating*:

Heating systems are something we all interact with, especially in the depths of winter where we depend on them, and yet there seems to have been very little evolution in the design of their interfaces. What’s more, with an ever increasing focus on energy efficiency, both from an environmental and economic standpoint, there’s a need for heating systems and their interfaces to be smarter, more efficient and transparent.

Design Monday #1 – Central Heating (short version) from Rattle on Vimeo.

Read the full post.

The Rattle team think through existing systems and consider a number of possible revisions to improve the way that information is presented to users, and the level of control that it might be useful for users to have. This is a great piece of work, impressive and very thorough, and it’s interesting to see how their thinking evolved: I get the impression that (as service designers) they’re a lot more focused on users’ needs than the designers of many heating systems are. It’s also an exciting thing for a design company to be able to take time to address problems outside their immediate sphere, since they’re bringing a whole new level of domain expertise to it.

The ‘I’m working’ indicator is a really good idea – it reminds me of some higher-end car tyre air pumps at petrol stations where you can just set the pressure you want to achieve, and the pump cuts out (and alerts you) when it reaches it. But the idea of doing away with the ‘desired temperature’ setting and just having warmer/colder is also interesting – “forc[ing] people to always make decisions based upon how they’re feeling right now”.

Equally the ‘shift to service’ approach of having an API and making clever use of it has a big potential to help in energy saving (and cost saving for the user), especially if the usage data were (anonymised or otherwise) available for analysis. Just being able to tell users “it’s costing you £X more to heat your home than it does for a similar family in a similar house down the road – if you insulated better you could save £X every month” would be an interesting mechanism for persuasion. As with so many things, it relies on having that API or other interface available in the first place…

Folk theory of thermostats

The ‘folk theory of thermostats’ which Frankie mentions, popularised in Don Norman’s The Psychology / Design of Everday Things, has long intrigued me:

There are two commonly held folk theories about thermostats: the timer theory and the valve theory. The timer theory proposes that the thermostat simply controls the relative proportion of time that the device stays on. Set the thermostat midway, and the device is on about half the time; set it all the way up and the device is on all the time. Hence, to heat or cool something most quickly, set the thermostat so that the device is on all the time. The valve theory proposes that the thermostat controls how much heat (or cold) comes out of the device. Turn the thermostat all the way up, and you get the maximum heating or cooling. The correct story is that the thermostat is just an on-off switch. Setting the thermostat at one extreme cannot affect how long it takes to reach the desired temperature.

People’s mental models of heating systems are often stereotyped or played with (as we’ve discussed before here), but as Willett Kempton found out in a classic study, there are some nuanced versions of the theories, which, in practice, are perhaps not as silly as Norman suggests. People satisfice.

Say you come in from outdoors, and are cold. Because of the delay in your exposed skin warming up to room temperature, it surely does warm you more quickly if you stand near something that’s hotter than you actually want to be, e.g. a log fire / stove. So the heuristic of ‘turning up the heat to more than you need, in order to feel warmer more quickly’ is pretty understandable, especially when the temperature controlling the thermostat is the temperature of the thermocouple/probe/whatever and not actually the body temperature of the users themselves. (That would be a good innovation in itself, of course!) Am I wrong?

Given that a lot of people do try to control heating systems as if they worked on the valve model, would it be sensible to develop one which did? Do they already exist?

*Rattle’s second ‘Design Monday’ session, on ‘Lunch’, is also well worth a look.

The liquid detection stickers in mobile phones, which allow manufacturers and retailers to ascertain if a phone has got wet, and thus reject warranty claims (whether judiciously/appropriately or not), seem to be concerning a lot of people worldwide. Around a quarter of this site’s visitors are searching for information on this subject, and the comments on last October’s post on the subject contain a wealth of useful experience and advice.

This current thread on uk.legal.moderated goes into more depth on the issue, and how the burden of proof works in this case (at least in the UK). While informed opinion seems to be that the stickers will only change colour when actual liquid is present within the phone, rather than mere moisture or damp, this may well include condensation forming within the casing, as well as the more obvious dropping-of-phone-into-puddle and so on. The main point of contention seems to be that the sticker may change colour (perhaps gradually) and the phone continue working perfectly, but when an unrelated problem occurs and the phone is taken in for repairs under warranty, the presence of the ‘voided’ sticker may be used as a universal warranty get-out even if the actual problem is something different.

Tilt detection
Along these lines, one of the posts tells of a similarly interesting design tactic – tilt-detectors on larger hardware:

30 years in the IT industry and associated customer service tells me they are trying it on and most people buy it. In the olden days, hardware used to come with a similar red dot system indicating the kit had been tilted more than 45 degrees and the manufacturers claimed the kit could not be installed and had to be written off.

Of course, 99.9% of the time the kit was fine, but they had a get-out from a warranty claim or so they thought. When the buyers tried to claim on their insurance or against the transport companies insurers the loss adjusters got involved and invariably the kit was installed and worked fine for years rather than the insurers paying out.

In some cases, of course, tilt-detectors were (are still?) necessary in this role. A piece of equipment with multiple vertically cantilevered PCBs laden with heavy components – relays, for example – might well be damaged if the PCBs were tilted away from the vertical. Certainly some devices with small moving coil components would seem as though they may be damaged by being turned upside down, for example. (Do the ultra-fine damper wires on an aperture-grille CRT monitor such as a Trinitron need to be kept in a particular orientation when handling the monitor?)

This patent, published in 1984, from which the above images were extracted, describes an especially clever ‘interlock’ system using two liquid-based detectors arranged so that if the device/package is tilted and then tilted back again, the second detector will then be triggered:

…it is desirable that the tilt detectors not be resettable. In particular, it must be possible to combine a package with at least a pair of the tilt detectors such that attempting to reset one would cause the other to be tilted beyond its pre-determined maximum angle so that the total combination would always afford an indication that the tilt beyond that allowed had been effected.

This is something of a poka-yoke – but as with the phone liquid-detection stickers, it’s being used to detect undesirable customer/handler behaviour rather than actually to prevent it happening. Other than making a package too heavy to tilt, I am not sure exactly how we might design something which actually prevents the tilting problem, aside from rectifying the design problem which makes tilting a problem in the first place (even filling the airspace in the case with non-conductive, low-density foam might help here).

But there’s certainly a way the tilt-detector could be improved to help and inform the handler rather than simply ‘condemn’ the device. For example, it could let out an audible alarm if the package or device is tilted, say, 20 degrees, to allow the handler to rectify his or her mistake before reaching the damaging 45 degrees, whilst still permanently changing colour if 45 degrees is reached. In the long run, it would probably help educated users about how to handle the device rather than just ‘punishing’ them for an infraction. I’m sure that mercury-switch (or whatever the current non-toxic equivalent is) alarms have been used in this way (e.g. on a vending machine), but how often are they used to help the user rather than alert security?

The patent description goes on to mention using tamper-evident methods of attaching the detectors to the device or packaging – this is another interesting area, which I am sure we will cover at some point on the blog.

Henry e-mails:

“Perhaps this is too obvious: parking meters; and I mean modern digital ones, enforce arbitrary limits on how much you can pay for at a time (4 hours). Is this to share the enjoyment of democratic parking (at a dollar an hour), or some social engineering ploy to force productive members of the workforce to enter the valet service economy, and thus a reminder of the fact that if they work harder, they could afford a driver?”

Tongue-in-cheek aside, there is something unhelpful, to some extent manipulative, designed into a lot of parking ticket machines (as well as some other vending machines). Take a look at the following machine I photographed this morning in a shoppers’ car park in Pinner, Middlesex, UK:

What’s the excuse for the ‘No change given – Overpayment accepted’ policy? It’s not as though it’s technically too difficult to give change: these aren’t mechanical penny gobstopper machines from the 1950s. Sure, it would make each machine a bit more expensive to include the change-giving function, but so what? If every one of the hundreds of people who park each day paid, say, 5 pence extra the cost of the more expensive machine would be recouped within a week or two, surely?

Of course, the real reason for the ‘no change given’ policy is that many customers who arrive at the machine without the 50p + 20p (or other combinations needed to make 70p) will put in £1 instead. Thus for a certain percentage of customers, the machine receives 1.43 times the revenue it ought to. I don’t know how many people overpay, but the point is, none of them can underpay. The system is asymmetric. The house always wins.

Does the car park operator (in this case Harrow Council) factor the extra revenue it receives from forcing overpayment into its projected revenues from the machines? Do they record how many people overpay, and use that statistic to plan next year’s budget? Or is overpayment treated as an ‘unexpected’ windfall? Or perhaps, just perhaps, without the overpayment the car park would make a loss?

Any more examples of awful ‘no change given’ implementations, or related anecdotes, musings, etc, much appreciated!

“This is the paradox of social media that has been bothering me lately: an ‘empowering’ media that provides increased opportunities for communication, education and online participation, but which at the same time further isolates individuals and aggregates them into masses —more prone to control, and by extension more prone to discipline.”

Slashdot on ‘A working economy without DRM?’ – same debate as ever, but some very insightful comments

Slashdot on ‘Explaining DRM to a less-experienced PC user’ – I particularly like SmallFurryCreature’s ‘Sugar cube’ analogy

‘The Promise of a Post-Copyright World’ by Karl Fogel – extremely clear analysis of the history of copyright and, especially, the way it has been presented to the public over the centuries

(Via BoingBoing) The Entertrainer – a heart monitor-linked TV controller: your TV stays on with the volume at a usable level only while you keep exercising at the required rate. Similar concept to Gillian Swan’s Square-Eyes

Scott Adams recounts an anecdote illustrating the ‘illusion of control’ and how important it is to many people – even to the extent that it is the single defining characteristic of mankind which one might use to explain human behaviour to aliens:

“The maintenance man is moving the thermostat in our office today. I started talking with him about the “Thermostat Wars” [from Dilbert comics]. He told me about one office with 30 women where they could never get the temperature to an agreeable level. At his suggestion they installed 20 dummy thermostats around the office. Everyone was told that each thermostat controlled the zone around itself.

Problem solved. Now that everyone has “control” of their own thermostat there is no problem.”

To what extent is the illusion of control, rather than real control, what most people really want in their products?

Do they care that their personal data may be encrypted and held to ransom by a software company, so long as they feel ‘in control’ in everyday use (e.g. the ability to change the colour scheme)?

And how should designers respond to this issue? Are there any examples of products (other than, say, children’s toys) deliberately designed with fake controls to make the user feel in charge even though he/she isn’t? (Fake solar cell calculators are interesting, but not quite the same issue)

P.S. On the other hand, it’s worth considering the opinion expressed by the Audi A2 owner, that she didn’t find it a disadvantage having to take her Audi to a ‘specialist’ in order to open the bonnet (hood). Is even that basic level of control (being able to see the engine) too much for some people? Is it because, say, a thermostat affects people personally (temperature) whereas a car engine is something dirty, difficult, complex, for someone else to worry about?

According to Reuters,

“The [US] government will not require recorders in autos but said on Monday that car makers must tell consumers when technology that tracks speed, braking and other measurements is in the new vehicles they buy.

The National Highway Traffic Safety Administration regulation standardizes recorder content and sets guidelines for how the information should be disclosed.

…

Safety experts, consumer groups and insurance companies have long pressed the agency to mandate recorders in cars, but industry has responded voluntarily in recent years. About two-thirds of the new vehicles now produced each year contain the device that is connected to air bag systems.

…

Under the new rules, auto recorders must track vehicle speed, acceleration, and deceleration, braking, steering and some air bag functions. In some cases data on vehicle roll angle, steering inputs, and passenger safety belt use will be recorded.

…

Rae Tyson, a NHTSA spokesman, said… that recorder information is private property that cannot be downloaded without permission of the vehicle owner.”

Let’s get this straight: these are black boxes intended to help compile safety data and undestand accidents, and the data will not be shared with insurance companies except with the car owner’s pemission, so drivers have nothing to worry about?

Or will it simply be the case that signing up for car insurance will require you “voluntarily” to allow the insurance company to access your data?

Are these actually that different to insurance black boxes??

Another point which stands out of the story, since reading Scott Craver‘s Privacy Ceiling outline, is that the black box is legally optional yet two-thirds of all new cars in the US have them.

In a liability culture, that violates Scott’s 3rd principle:

Do not bother to design a system or business model that balances user privacy with [potential external] demands. All this does is insert an architecture of monitoring or control, for later abuse. In other words, design an architecture for privacy alone. Anything you put in there… will one day be used to its full extent.

If the black boxes are in every car a company (such as GM) makes, that leaves the company open to certain, ah, liability issues. Say NHTSA analysis of accident data shows that a particular model has peculiarities related to, e.g. “vehicle roll angle and steering inputs” as tracked by the black box (or, even worse, inconsistencies related to this issue, with some cars having a problem and others not).

That car manufacturer is instantly plunged into the spotlight as a maker of dangerous products, even if the problem is not necessarily as simple as it seems (certain types of car attract better drivers than others, for example), and it will be very difficult to defend the issue and deal with lawsuits, since the information is now publicly available. (Conversely, having that amount of information should also make it easier for the company to analyse and respond to the problem).

Yet they could have “got away with it” by not fitting the black boxes in the first place. That may be a Ford Pinto-esque, bury-your-head-in-the-sand approach, but when company planners look at the potential upside and downside of any strategy decision, the decision to fit black boxes voluntarily may not seem such a sensible one in view of the liabilities to which it exposes the company.

(Reuters link via Open Rights Group discussion)

“This is an economic limit on privacy violation by companies, owing to the liability of having too much information about (or control over) users.”

It’s the “control over users” that immediately makes this something especially relevant for designers and technologists to consider: that control is designed, consciously, into products and systems, but how much thought is given to the extremes of how it might be exercised, especially in conjunction with the wealth of information that is gathered on users?

“Liability can come from various sources… [including]

Vicarious infringement liability.

Imagine: you write a music player (like iTunes) that can check the Internet when I place a CD in my computer. You decide to collect this data for market research. Now the RIAA discovers that this data can also identify unauthorized copies. Can they compel you to hand over data on user listening habits?

Your company is liable for vicarious infringement if (1) infringement happens, (2) you benefit from it, and (3) you had the power to do something about it—which I assume includes reporting the infringement. So now you are possibly liable because you have damning information about your users. This also applies to DRM technologies that let you restrict users.

Note that you can’t solve this problem simply by adopting a policy of only keeping the data for 1 month, or being gentle and consumer-friendly with your DRM. The fact is, you have the architecture for monitoring and/or control, and you may not get to choose how you use it.

Other sources of liability described include: being drawn into criminal investigations based on certain data which a company or other organisation may have – or be compelled to obtain – on its users; customers suing in relation to the leaking of supposedly private data (as in the AOL débâcle); and “random incompetence”, e.g. an employee accidentally releasing data or arbitrarily exercising some designed-in control with undesirable consequences.

Scott goes on:

“Okay, so there is a penalty to having too much knowledge or too much control over customers. What should companies do to stay beneath this ceiling?

1. Design an architecture for your business/software that naturally prevents this problem.

It is much easier for someone to compel you to violate users’ privacy if it’s just a matter of using capabilities you already have. Mind, you have to convince a judge, not a software engineer, that adding monitoring or control is difficult. But you have a better shot in court if you must drastically alter your product in order to give in to demands.

…

2. Assume you will monitor and control to the full extent of your architecture. In fact, don’t just assume this, but go to the trouble to monitor or control your users.

Why? Because in an infringement lawsuit you don’t want to appear to be acting in bad faith… if you have the ability to monitor users and refuse to use it, you’re giving ammunition to a copyright holder who accuses you of inducement and complicity.

…

But … the real message is that you should go back to design principle 1. If you want to protect users, think about the architecture; don’t just assume you can take a principled stand not to abuse your own power.

The third principle is really a restatement of the first two, but deserves restating:

3. Do not attempt to strike a balance.

Do not bother to design a system or business model that balances user privacy with copyright holder demands. All this does is insert an architecture of monitoring or control, for later abuse. In other words, design an architecture for privacy alone. Anything you put in there, under rule #2, will one day be used to its full extent.

I have seen many many papers over the years, in watermarking tracks, proposing an end-to-end media distribution system balancing DRM with privacy. Usually, the approach is that watermarks are embedded in music/movies/images by a trusted third party, the marks are kept secret from the copyright holder, and personal information is revealed only under specific circumstances in which infringement is clear. This idea is basically BS. Your trusted third party does not have the legal authority to decide when to reveal information. What will likely happen instead: if a copyright holder feels infringement is happening, the trusted third party will be liable for vicarious infringement.“

Summing it up: any capability you design into a product or system will be used at some point – even if you are forced to use it against the best interests of your business. So it is better to design deliberately to avoid being drawn into this: design systems not to have the ability to monitor or control users, and that will keep you much safer from liability issues.

The privacy ceiling concept – which Scott is going to present in a paper along with Lorrie Cranor and Janice Tsai at the ACM DRM 2006 workshop – really does seem to have a significant implications for many of the architectures of control examples I’ve looked at on this site.

For example, the Car Insurance Black Boxes mostly record mileage and time data to allow insurance to be charged according to risk factors that interest the insurance company; but the boxes clearly also record speed, and whether that information would be released to, say, law enforcement authorities, if requested, is an immediate issue of interest/concern.

Looking further, though, the patent covering the box used by a major insurer mentions an enormous number of possible types of data that could be monitored and reported by the device, including exact position, weights of occupants, driving styles, use of brakes, what radio station is tuned in, and so on. Whether any insurance company would ever implement them, of course, is another question, and it would require a lot tighter integration into a vehicle’s systems; nevertheless, as Scott makes clear, whatever possibilities are designed into the architecture, will be exploited at some point, whether through pressure (external or internal) or incompetence.

I look forward to reading the full paper when it is available.

At Freedom to Tinker, Ed Felten has posted a summary of a talk he gave at the Usenix Security Symposium, called “DRM Wars: The Next Generation”. The two installments so far (Part 1, Part 2) trace a possible trend in the (stated) intentions of DRM’s proponents, from it being largely promoted as a tool to help enforce copyright law (and defeat ‘illegal pirates’) to the current stirrings of DRM’s being explicitly acknowledged as a tool to facilitate discrimination and lock-in — and the apparent ‘benefits of this’:

“First, they argue that DRM enables price discrimination — business models that charge different customers different prices for a product — and that price discrimination benefits society, at least sometimes. Second, they argue that DRM helps platform developers lock in their customers, as Apple has done with its iPod/iTunes products, and that lock-in increases the incentive to develop platforms.

Interestingly, these new arguments have little or nothing to do with copyright. The maker of almost any product would like to price discriminate, or to lock customers in to its product. Accordingly, we can expect the debate over DRM policy to come unmoored from copyright, with people on both sides making arguments unrelated to copyright and its goals.”

As noted by some of the commenters, that unmooring also unmoors the DRM debate from being presented as an ‘honest content providers vs illegal pirating freeloaders’ one. Price-fixing, lock-ins and so on are difficult to defend, and I find it hard to think of convincing examples where “price discrimination benefits society” or “lock-in increases the incentive to develop platforms”. If customers are locked in to a platform, there is no incentive to innovate for the locker-in, and much higher barriers for competitors to draw them away. Path dependency is rarely good for companies, and rarely good for society, and lock-ins would seem to be a major contributor to path dependency. The argument that “Apple wouldn’t have developed the iPod (and the record companies wouldn’t have let Apple develop iTunes) if DRM didn’t exist to lock customers in” is specious: there were plenty of portable music players before they came on the scene, and surely most 40GB music iPods were always intended to be largely filled with music acquired from somewhere other than iTunes.

Ed goes on to talk about the trend “toward the use of DRM-like technologies on traditional physical products.” (Long-term followers – if any! – of my research might remember this is very similar to the phrase “Architectures of control: DRM in hardware” which Cory Doctorow used to link to my original web-page on the subject), and uses the example of printer cartridge lock-ins (see also here):

“A good example is the use of cryptographic lockout codes in computer printers and their toner cartridges. Printer manufacturers want to sell printers at a low price and compensate by charging more for toner cartridges. To do this, they want to stop consumers from buying cheap third-party toner cartridges. So some printer makers have their printers do a cryptographic handshake with a chip in their cartridges, and they lock out third-party cartridges by programming the printers not to operate with cartridges that can’t do the secret handshake.

Doing this requires having some minimal level of computing functionality in both devices (e.g., the printer and cartridge). Moore’s Law is driving the size and price of that functionality to zero, so it will become economical to put secret-handshake functions into more and more products. Just as traditional DRM operates by limiting and controlling interoperation (i.e., compatibility) between digital products, these technologies will limit and control interoperation between ordinary products. We can call this Property Rights Management, or PRM.”

Not too sure about that term myself, as I feel the affordances the technology is controlling are moving further and further away from actual ‘rights’. DRM is bad enough as a catch-all term for technology which in many cases is denying users rights they may legally hold in some countries (e.g. fair use or backup copies). I think “technology lock-ins” or “technology razor-blade models” might be a more descriptive label than ‘PRM’. (Or ‘architectures of control’, of course, but my definition of these is much broader than simply lock-ins).

Ed gives three examples of possible future extensions of technology lock-ins, none of which seem at all unlikely; in fact they’re all easily possible right now:

“(1) A pen may refuse to dispense ink unless it’s being used with licensed paper. The pen would handshake with the paper by short-range RFID or through physical contact.

(2) A shoe may refuse to provide some features, such as high-tech cushioning of the sole, unless used with licensed shoelaces. Again, this could be done by short-range RFID or physical contact.

(3) The scratchy side of a velcro connector may refuse to stick to the fuzzy size unless the fuzzy side is licensed. The scratchy side of velcro has little hooks to grab loops on the fuzzy side; the hooks may refuse to function unless the license is in order [hence my photo at the top of this post! - Dan] For example, Apple could put PRMed scratchy-velcro onto the iPod, in the hope of extracting license fees from companies that make fuzzy-velcro for the iPod to stick to.

Will these things actually happen? I can’t say for sure. I chose these examples to illustrate how far PRM might go. The examples will be feasible to implement, eventually. Whether PRM gets used in these particular markets depends on market conditions and business decisions by the vendors. What we can say, I think, is that as PRM becomes practical in more product areas, its use will widen and we’ll face policy decisions about how to treat it.”

The comments on both posts (Part 1 | Part 2) go into some extremely interesting discussion of the ideas and examples, with the ‘pen/licensed paper’ one being conclusively noted as ‘baked’ with Bill Higgins explaining the Anoto* technology.

(*And no, I don’t think the “www.anotofunctionality.com” of that link is deliberately in the same league as “www.powergenitalia.com,” “www.expertsexchange.com,” etc, but it’s still oddly apposite given the “no to functionality” with which so many lock-ins shed users when they’re fed up with paying over the odds for replacement parts.)

I look forward to the third part of Ed’s talk summary: this is a fascinating area of discussion which is central to much of the ‘architectures of control’ phenomenon.

“Many of us, who may find ourselves arguing based on public reasons for public policies that protect the freedom to tinker, also have a private reason to favor such policies. The private reason is that we ourselves care more about tinkering than the public at large does, and we would therefore be happier in a protected-tinkering world than the public at large would be.”

Many of the comments – and those on the follow-up post – look in more detail at the legal issues, with some very interesting analogies to freedom of expression and points made about the impact on innovation – which benefits everyone – when power users are prevented from innovating.

I felt I had to comment, since this is an issue central to the architectures of control research; here’s what I said:

“I think I’d ask the question, “Even if it becomes illegal to tinker with a device, what is there to to stop someone doing it?”

If it is purely the fear of getting caught, then tinkering will be stifled, to some extent. But power users will form groups just as they do now, and some tinkering will still go on. (If the tinkering is advanced enough, it will be too difficult for law enforcement to detect/understand it anyway).

At present much file-sharing activity is illegal, but it still goes on in vast quantities. The fear of getting caught is a major retardation to that activity, I’d suggest; there may also be an ethical component to the decision in many people’s minds. They’re told it’s analogous to stealing a CD from a store, and they believe or are persuaded, partially at least, by that. It seems immoral or unethical.

But does anyone seriously believe that tinkering with devices is unethical? (There are probably a few people who do, e.g. ZDNet’s Adrian Kingsley)

Tinkering with devices will never seem immoral or unethical to the vast majority of the public, hence the only barriers to stop them doing it are a) fear of getting caught and b) lack of knowledge or desire. Most people don’t bother tuning up their cars or tinkering with their computers, even though they could.

Power users do, and in a future where tinkering is illegal, it will again only be power users who do it, and fear of getting caught will be the only reason for not doing it.

So what about this fear of getting caught? How likely is it that one’s modifications or tinkering will be detected by some kind of enforcement agency? The only way I can see that this could be carried out in any kind of systematic way would be if observation/reporting devices were embedded in every product, e.g. every PC reporting home every few hours to squeal if it’s been modified.

But we already have that! Or at least we will soon, and therefore it seems irrelevant whether or not it becomes illegal to tinker with devices. If every computer is ‘trusted’ and spies and reports on its user’s behaviour, whether it reports to Microsoft or a Federal Anti-Tinkering Agency is, perhaps, beside the point.

Architectures to prevent or stifle tinkering can be designed into products and technologies whether or not there is a law requiring them. The user agrees to
have his/her behaviour and interactions monitored and controlled by the act of purchasing the device.

Even if the law went the other way, and there were a legally guaranteed right to tinker, all that would happen is that manufacturers will make it more difficult
to do so by the design of products. Hoods (bonnets) would start to be welded shut, in Cory Doctorow’s phrase, (the Audi A2 already has this, sort of), backed up by stringent warranty provisions. You might have a right to tinker with your device, but no law is going to compel the manufacturers to honour the warranty if you do so.

This, I think, is the crucial issue: the points Lessig makes about the designed structure of the internet, the code, superseding statute law as the dominant shaper of behaviour in the medium, apply just as strongly to technology hardware. Architectures of control in design will control users’ behaviour, however the laws themselves evolve.”

Now, the immediate response of most of us is probably “razor blade model!” or even “stifling democratic innovation!” (as Hal Varian or Eric von Hippel might put it), and indeed that was probably my own instinctive reaction.

It’s not clear, though, that this is a standard architectures-of-control-enforced-razor-blade-model of the kind we’ve seen with printer cartridges. Most phone owners surely don’t ever replace their batteries during the life of the phone, so I can’t believe that selling owners batteries can be a major part of the business plan for a new phone. I’ve never bought new batteries for any phone I’ve owned. A friend did, though by that time his phone was six or seven years old and he had to resort to eBay to find the correct type.

No, the promulgators of battery authentication claim that battery authentication is all about ensuring consumer safety:

“Battery-pack authentication is necessary because the lithium-ion cells that are the building blocks of all such packs are changing, and, although they still may have the same physical dimension, their input charging voltage and required charging rates are changing and fragmenting across markets. If the cells charge at the wrong voltage or too quickly, they may explode.“

My reaction, as a design engineer, would be: Why not standardise those characteristics, then? Standards don’t “fragment across markets” without someone causing that fragmentation. (It is true, though, that advancing battery technology does make charging patterns much more important to the life of the battery.)

“Vendors can ship their products with the proper battery pack, only to find that customers go the after-market route to replace or back up battery packs because after-market packs are easy to find and usually cheaper. Counterfeit battery packs pose a threat to user safety.”

Make the ‘proper’ packs cheaper and easier to find, then. Surely that’s cheaper and easier than developing a 64-bit key code battery authentication system, and keeping “its secret key in an 8×8-ft vault with 3-ft-thick walls, [with] only two people in the company hav[ing] vault keys,” as described in the EDN article?

Also, quit using the term ‘counterfeit’ to mean ‘all non-manufacturer-approved parts’. That’s a slippery slope to Newspeak. If I buy Fujifilm for a Kodak camera, is that film ‘counterfeit’? Of course not. It would be if it were being passed off as Kodak film, but that only seems to be the case with some of the batteries mentioned in the article (the Kyocera and LG ones near the start). If that’s the real problem – counterfeit batteries with the manufacturer’s logo on them – then be honest about it.

Greater, cheaper availability of the correct, manufacturer-approved batteries would be beneficial for the manufacturer in terms of aftermarket sales. If it means selling them with reduced margins in order to drive other manufacturers out of the market, then so be it. If the other manufacturers really are counterfeiters, passing off their products with the phone manufacturers’ logos, and the batteries really are dangerous as claimed, then there’s (potentially) a lot of brand damage going on.

The problem of exploding lithium batteries clearly isn’t insignificant – the following images are from a US Army/Naval Surface Warfare Center presentation [PDF] linked in the MAKE post:

Images from http://proceedings.ndia.org/5670/Lithium_Battery-Winchester.pdf

But, as commenter ‘unterhausen’ points out on the MAKE post:

“The risk of Li-poly batteries is independent of the manufacturer to a large degree. The problems come when they are damaged, shorted, overheated, or overcharged… Any Li-poly of the current generation will have the same problems… The chips are anti-competitive nonsense.”

This is an interesting area of debate, and likely only to become more prevalent as energy storage technology becomes more advanced. Will fuel cells for vehicles have authentication ICs built in? You bet.

How will ‘they’ do it with hydrogen fuelling stations, though? Will the pumps/dispensers themselves have a chip which ‘handshakes’ with the vehicle? Will you have to use ‘Toyota’ branded hydrogen for your Toyota to start?

The opportunity’s there, in a way that it never was for standard batteries, petrol, etc, in the past. Few people were naïve enough to buy solely Duracell batteries for their Duracell-branded torch (flashlight) because they thought it ‘would work better’, but when it comes to a device which only works when the manufacturer’s own branded batteries are used

It does make me wonder, though, why Henry Ford never got into the gas station business – was it just antitrust legislation that would have prevented it? General Motors and Standard Oil apparently colluded, and GM also co-owned the Ethyl Gasoline Corporation that held patents for the tetra-ethyl lead added to fuels from the 1920s onwards – which surely provided a large degree of economic lock-in (more GM cars sold = more TEL sold = even more money for GM) – but there was no technological lock-in.

Today we have technology that does allow technological lock-in, and it’s becoming cheaper and cheaper to deploy.