Most people, for most of their day, are trying to get by. Every day is essentially a series of problems, some minor, some major, some requiring more thought than others. Some we care a lot about; some we wish we didn’t have to. Some are welcome; some we even bring on ourselves because we enjoy solving them; others are deeply unwelcome. Some we care about initially, but then find we no longer do; some we don’t care about to start with, but they become important to us over time.

Many are repeating problems we recognise, and we can use stock responses to solve them — we learn from our experiences, and others’, where we can. A few seem new, but after a bit of thought, we realise we recognise them, and can use those stock responses again (perhaps modified slightly). Some are new, and require us to work out what to do — we might ask others, seek information, try to copy others’ actions, or other approaches. Some are new and we can’t work out how to solve them. Some are old problems that we still can’t solve, or don’t want to. With some, we find a solution that works, even if it’s not very good, and stick with it. It might even be the first one that ‘works’ by some criteria: it works, so it’s good enough. Sometimes we build things (‘tools‘) that enable us, or others, to solve similar problems again. Some are other people’s problems, but they become ours too. Others are ours, but someone else tries to solve them for us.
Often, solving one problem just creates more. It’s almost like our lives are a mesh of interwoven problem threads, some ours, some others’, some collective problems, some individual, some long threads, some short, some made of different materials, but all there. We can’t get from one bit of the cloth to another without travelling along or across the threads.
Sometimes we have a number of different ways we can solve a problem. Often, the way of solving it we choose is the way that’s easiest, or that doesn’t (seem to) cause as many other problems (for us).
And lots of problems never get solved. Some disappear by themselves, but others are just kicked into the future for ourselves (or someone else) to deal with.

It’s very easy to pick holes in the above, but it’s a model which summarises, to some extent at least, what I took away from many of the interviews I did as part of the Empower project during 2010-12. It’s taken me a while to reflect on the findings, some necessary distance for a coherent abstraction to form, but it’s coalesced and it’s actually relatively simple (and obvious). It is also intensely relevant to design for behaviour change, and indeed interaction design in general.
The context of our particular research was asking people about aspects of everyday energy use and sustainability at home and at work, interaction with energy-using systems such as heating, air conditioning, lighting, IT equipment, etc, and people’s understanding of those systems. And the point came across, again and again, that however much people cared, in theory, about their behaviour — and most people in our samples would have scored very highly in any kind of survey about attitudes towards the environment — the challenges people face in everyday life are about getting things done, getting through the day. If ‘saving energy’ or ‘doing things more sustainably’ (whatever that means) becomes another problem loaded onto people’s days, they’ll solve easier problems instead.
Is this ‘laziness’ (or, perhaps more diplomatically, Zipf’s least effort)? It depends how you frame it. If we’re thinking about someone else’s behaviour, we have a tendency to frame it somewhat differently to when we explain our own. I think it’s fairer to take the non-judgemental approach Steve Krug did in Don’t Make Me Think: people are busy, and if you can make it easier for them to solve their problems in a way which reflects the constraints and priorities of the context they’re in (and the other problems they’re trying to solve), that’s a behaviour change approach which might meet with more success than trying to persuade people of the importance of behaving differently as a goal in itself, removed from the context of interaction.
That’s not to say, of course, that people can’t learn through using things, and shape and re-shape their understanding of the world: making things easier does not preclude this, and indeed potentially provides more ‘teachable moments’ than something divorced from context. Equally, in some situations, pre-existing attitudes dominate how someone solves the problems faced, but there are many where it is elements of the context which dominate how people get by [PDF]. It’s certainly not either denying the importance of people having strong motivations and vision to solve problems in non-mundane, non-easiest-route ways. That’s what changes the world, and I’m grateful for it. I’m just interested in the extent to which mundane decision-making is recognised and understood, since many of the things people interact with every day are designed systems.

A few years ago on the blog, I contrasted an ‘enabling’ approach to motivating and constraining as ways to influence behaviour through design, drawing on a particular Buckminster Fuller quote. At the time, I didn’t necessarily consider all the implications of the different approaches in practice, but now the power of the enabling approach strikes me very clearly — from choice of default settings to prominence, this is about helping people solve their problems in ways which are easy and yet which also achieve a ‘good’ outcome for at least one party. In a paper from CHI 2010 [PDF], Carl DiSalvo, Phoebe Sengers and Hrönn Brynjarsdóttir contrasted seeing people as the problem (in sustainability) with trying to solve people’s problems. This strikes me as a fundamentally useful distinction to be made for ‘behaviour change’ work in general.
There are a few directions this discussion can go. I hope to explore some of these in due course, and work out, practically, how the approach can be of use to designers investigating people’s behaviour, and in many cases hoping to influence it.
Cubicles image by Michael Lokner, used under Creative Commons licence.