Balancing Need and Technology

invention or design?
Does need drive invention? Or is invention really a mother?

Conventional wisdom tells us that we design technological artifacts in response to perceived needs; that is, needs drive technology.  The formidable Don Norman recently wrote a web article suggesting that, contrary to convention, technology can drive needs.  Norman’s article caused quite a fuss in the design research community, in which only some agreed with his novel perspective.

I don’t see the benefit of arguing one way or the other; it’s on par with trying to decide which side of a coin came first, the head or the tail of it.  I think a better way to view it is as an infinitely looping process whereby designers adjust reality to balance our needs with respect to a number of other forces, one of which is technological change.

Chestnuts are for Squirrels

We all know the old chestnut: necessity is the mother of invention.  It’s nice and rational, and advises us that inventions are there for a purpose.  More subtly, it supports the paradigm that everything must have a purpose (which is arguable at best).  This kind of thinking is behind a lot of our current understanding about how we get things done and why we do things as we do.

Don Norman’s article suggests that, especially in highly innovative designs, needs are driven by the invention – which is exactly not what the chestnut says.

Though it may sound weird, this is not an unreasonable proposition.  How could, for example, anyone guess the myriad things we could do with computers before computers even existed?  (This is a particularly good example, I think, because of the many computer “experts” who have made pronouncements that turned out to be utterly wrong.  Bill Gates once said that no one could ever need more than 640 kB of RAM memory in a PC.  Ken Olsen, founder of DEC, pronounced that no one would ever want a computer in their home.)  As Norman points out, needs can develop in response to a technological innovation.  Humanity got along quite nicely without toilets for millions of years; but now, toilets are considered a basic need.  People discover the usefulness – the necessity – of technology only after it’s been invented.

The Web is another example.  Not the parts of it that you see when you use it, but the parts you don’t see: XML, HTTP, RDF, and all these other technologies that enable things like WordPress, and Gmail, and Twitter, as well as the massive commercial enterprises (like eBay and Amazon) that are generating billions of dollars in revenue each year.  It all started with just HTTP and HTML.  Given this technology, people started finding new needs that could be satisfied with it.  Satisfying those needs prompted experimentation.  They wrote extensions and harmless hacks and extra bits of software.  Over time, it became apparent that there was a need to standardize all those extra bits of technology because the Web was becoming too inefficient.  XML, RDF, and whole bunch of other specifications were designed to meet those needs.  These designs were implemented in new web technologies, which, in turn, enabled the invention of social networking, bookmarking and annotation, online commerce, mash-ups, and so on.

The next Big Web Thing seems to be browser extensions – getting your browser to do more than just browse websites by downloading snippets of code right into the browser.  Many software packages – Firefox, for example – already support this.  But there is no standard for it yet, so an extension for one package is unlikely to work on another package.  So browser extension technology has given rise to a need for a standard.  So extensions is being built into the next version of HTML.  There’s a telling sentence in the Wikipedia page for HTML5:

“HTML5 introduces a number of new elements and attributes that reflect typical usage on modern Web sites.”

That is, typical web usage (technology) precedes standardization (addressing a need).

Those of you who have read Norman’s article may note that I’m not quite consistent with him here.  Norman suggests technology comes before need in only the most revolutionary or innovative cases.  I think that those cases are only the most glaring instances of the phenomenon, and that it can actually be quite commonplace on a smaller scale.

Here’s one small example with big consequences.  When I was a child and went to the bank with my Dad, there was a queue for each teller.  These days, there’s only a single queue that serves all the tellers.  And this hasn’t only happened in banks.  The reason for this is that queueing theory tells us that over multiple visits to the same service, the average person will spend less total time waiting in queue.  This same result also informs the development of computer networks, etc.  This is essentially a technological invention based on a mathematical discovery.  The result of this relatively un-revolutionary technology was a perceived need to redesign banks, computer networks, etc.  Up until then, bank managers were perfectly happy to have multiple queues and put up with irate customers who had to wait too long; there was, back then, no need.

So, sometimes needs come first; other times technology comes first.  I think technology comes first far more often than Norman suggests.  And I think that the old chestnut about necessity and invention is…just squirrel food.

An Alternative View

There is still the sense, however, that the conventional approach, putting needs before technology, is the “right” way, and that the other way is somehow anomalous.

I think that maybe there’s a better way to look at this, a way that can reconcile Norman’s idea with conventional wisdom:  the need was always there, and the new technology just made it visible.

Consider the example of flush toilets, and let’s start by thinking about the time before their invention.  Society was in a certain situation that we might describe with a number of “forces” that were at work. On the one hand were forces that represent instinctive needs. People wanted to live well, be happy, safe, secure, and healthy. We can think of these as internal (to humans) forces. Working against these internal needs-forces were other, external forces: technological limits, costs and the general economic situation, social norms, and political issues, to name a few.

A balanced set of forces without toilets
Figure 1: A graphical representation of the situation before flush toilets.

We might render this situation graphically (Figure 1) by drawing each force as an arrow acting on the “current state of the world” (the central blue dot against which  all the arrows are pressing).  The thickness of the arrow represents the strength of the force.  The needs-force (in green) are   cancelled out, or balanced, by the opposing forces (including the red technology force).

Another way to think of it is as a bunch of elastics (rubber bands), each with one end pinned to a fixed base. Each arrow is an elastic, and each elastic is pinned at its arrow’s tail. The free ends of the elastics are all connected together at the central dot, but they aren’t pinned to the base. Where the elastics join together is where the “current state” of the world is located.  The elastics are of different strengths, so each will pull on the joining point differently. Nevertheless, when left free to stretch naturally, the elastics will arrange themselves such that the net force at the joining point is zero. That’s the balancing point.

Balance Forces 2
Figure 2: After the invention of the flush toilet, the forces, and thus the balance point, change.

Now let’s introduce the flush toilet. This changes the technology force, which changes the balancing point of the combined forces.  I’ve shown this in Figure 2.  You see that the balance point has moved.  You also see that all the forces have changed a little, in response to our change of technology.  This is what would happen with elastics and, I believe, this is a reasonable qualitative model of the impact of technology on a situation.

The new balancing point is, however, only hypothetical: it takes time to go from invention to ubiquity – we might call this a hysteresis of design. Having invented the flush toilet, one must now develop the infrastructure to support it, the manufacturing capacity to produce it in volume, and the capacity to install and maintain it wherever possible.

So, at first, the location of the current situation (the blue dot) remains unchanged even though the flush toilet changes the balance point. This means that even though the current situation has not changed, it is no longer balanced.

If we superimpose the two diagrams, we can see more clearly the difference in the situations and the difference in the forces.  This is shown in Figure 3. The faded parts of the superimposed image is the original configuration from Figure 1.

Balance Forces 3
The "before-toilet" and "after-toilet" configurations superimposed.

The difference between the original balance point (faded) and the new balance point is a model of a new need. It’s the difference between where we are (the faded point) and where we could be given flush toilets.  The existent needs-force – which has not changed throughout this process – now has less resistance and can push the current situation toward the new balance point.  The needs-force now become visible as the difference between the two balance points – we recognize a need that we had been unable to recognize before.  Recognizing that need, we can now address it through design aided by the technology of flush toilets.

There are four important points here.

The first point is that the need must be recognized by individuals who have the ability and resources to take action.  If no such persons recognize the need, then the imbalance will not be addressed, and the situation will remain so, perhaps indefinitely.  This can describe a number of situations that exist today.  For instance, too many people starve to death.  Most of us recognize that we need to solve this problem, but no one has yet found a way to act so as to address the imbalance.

The second point is that the nature of the newly perceived need depends on the nature of the introduced technology. Every time the technology arrow changes, you get a new and different balance point. Introducing a different technology may lead to a different balance point.  Different balance points indicate different perceived needs. Different needs are satisfied by different designs, which lead to different future situations, which will enable the development of different future technologies.  Wash, rinse, and repeat.  The introduction of a single technology now – even a minor one – can have repercussions that will echo through future situations for a very long time.

We’ve created a cycle here that includes designing for needs that arise from new technologies.  Because of this, I think it’s senseless to say that needs come before technology, or vice versa. After all, where does a circle start?  It’s not a matter of what comes first; it’s a matter of where you start – and you can start anywhere.

Note that this same model accommodates the conventional needs-first approach; in those cases, you don’t start with a technology, but with a perceived need.

The third point is that a change in any of the forces will cause a perceived need to arise.  That is, it’s not only a new technology that can trigger the emergence of a “new” need.  It could be a change in economic circumstances, or in government regulation, or in environmental conditions.  All these kinds of changes, when viewed through this balance-based model, cause changes that give rise to imbalances that indicate needs.

Indeed, I believe that it’s changes in these other, non-technology forces that drive the perception of needs in the conventional, needs-first perspective.  Let’s say that Norman is right, and that new technologies can give rise to new needs.  Needs are inherently human things.  You can’t go out and point at a need.  They exist only in our minds.  So, if some needs arise from some external factor, like a new technology, then why don’t all needs arise from external factors?  So it doesn’t matter whether needs come before technology or vice versa, this one model covers it.  One could even argue using this balance-based model that needs only ever arise because of changes in one of the other, external forces; that is, that needs are always last.

The fourth point is that the perceived need accounts for only the difference between what is and what could be. A sizable portion of the actual need remains hidden by other forces. The exact nature of these hidden needs is not clear, precisely because the are so difficult to elicit. I believe that they are all rooted in the survival instinct, moderated and modified by societal and cultural pressures, but I won’t push that particular view here.  The question of how we might expose more of the actual need-force is an interesting research issue, but I’m not sure it’s especially relevant to the practise of design, or to this particular article.

A First Step?

So there you have it: a brand new (as far as I can tell) way of thinking about how things change.  If there’s anything to this, then it could impact on how we think about, and practise, design.

In future articles, I will explore the implications of a balance-based model on design.

10 thoughts on “Balancing Need and Technology”

  1. Very nice analysis. Precisely what I was hoping might result: informed discussion and debate, perhaps new formulations. Alas, most of the debate has been uninformed.

    Thank you, Filippo. This is the best analysis I have seen. I couldn’t have said it better myself. In fact, I obviusly didn’t.

    Don Norman

    1. Don,
      I really appreciate that you took the time to read it so quickly and that you appreciate it. Hopefully, it will stimulate further discussion.

    1. I appreciate your comments. I did some more research about the quotations. I’m willing to admit that the Gates quote is questionable at best, but I did find some evidence that some people say they were present when he said it at an early microcomputer trade show in Seattle in mid 1981. Sorry; I don’t have the source at hand, but if I find it, I’ll certainly post it.

      The Olsen quotation, on the other hand, seems to be true (see Many people say it was taken out of context because he was talking about a computer that would CONTROL the house. That might be, but consider: it seems extremely likely that in the near future, there WILL be “smart homes” that are controlled by a whole network of computers. So I’m willing to let this one stand.

      Thanks for making me hunt these down. I certainly didn’t intend to spread urban legends, and it’s definitely only my problem to look up proper sources.

  2. This is a good article, Fil.

    It got me thinking of genre theory and how you reason about genre change in that theory. Another association I made was to Bolter’s & Grusin’s thinking in relation to remediation. Now, both of these trails of thought belong to media, but can to some degree be transferred to technology in general.

  3. Lots to think about here, thanks. I apologize for failing to grasp the nuances, but what do you think about needs that can’t be identified until a solution is made available? When presenting customer insights and strategic opportunities to clients recently, we got into this discussion about these sort of things. I was pleased to see one member of this needs-first organization cite the Henry Ford chestnut (and go ahead and tell me it’s urban legend too 😦 ) about people asking for a faster horse. This group was really big on having contextual research identifying specific pain points that they could go and FIX, but we were trying to shift the conversation more to understanding leading to opportunities. Anyway, my pleasure was short-lived when our gatekeeper took us aside afterwards and explained that this individual was new to the organization and didn’t understand how things worked.

    1. Steve,
      I too have been in situations similar to the one you describe.

      Your situation of not identifying needs till a solution is available may be analogous to tech-before-needs. Instead of introducing a technology that brings needs to light, you’re suggesting introducing a “solution” (which I suppose could be a design). In my model, that’s just changing one of the other forces. Nothing else need change.

      There’s other effects here, though, that might be simpler explanations. If the thing that got labelled “solution” already existed when the need was identified, then you might have a case of someone finding an unintended affordance of the solution.

      There’s a bit of an issue here. You say the solution is presented before the need is identified. Who, in that case, knew it was a “solution”? Could it be that an object was presented, and then the need was identified, and then the object was identified as the solution?

      If the solution existed before the need was identified, then I wonder how many agents are involved. It could be one of those rather common situations where the designer knows what the client’s real need is, but the client doesn’t, won’t, or can’t recognize the real need for themselves. The designer then suggests a solution to the real need and then the clouds part and finally the client understands.

      Is that something akin to your experience?

      This would a “special case” because someone was an imperfect reasoner. My model, as I wrote about it in this post, assumes every agent will act rationally and ethically. I know that’s not real life, but that’s how I learnt model-building. Start with a simplified model to capture the core ideas, then gradually relax your assumptions and account for them in the model. I do want to build bounded rationality into the model, but that will take time.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.