Empathy and Human(e) Digitalities

by Nick de Voil 21. May 2013 11:14

For people who design products, services and systems, it's pretty clear by now that empathy is a vital attribute.

By the way, some psychologists like to make a distinction between cognitive empathy and affective empathy. The first is the ability to see the world the way others see it, the second is the ability to feel what others are feeling. I'm not too sure about this distinction - I'm with George Kelly when he says of cognition and affect, "The classic distinction which separates these two constructs has, in the manner of most classic distinctions that once were useful, become a barrier to sensitive psychological inquiry".

How do we develop and fine-tune our capacity for empathy, whether cognitive or affective? One answer, of course, is through the arts - literature, fine art, performance, music - and the study of language. Studying a foreign language means learning to express ideas according to a different set of cultural norms. In the process of doing this, you learn that many ideas that come naturally to an English speaker are literally unthinkable in another language, and vice versa. This is a first step towards the ability, so important for designers, to navigate between multiple ontologies or construct systems. It's not the only way of learning it, but it's a good way.

Languages aren't static. People's linguistic categories don't reflect a clearly indisputable objective reality, but are individually and above all socially constructed in an ongoing process. When someone says something, it's never a simple assertion of a fact. Far from it. We have a context, we have an agenda, we have feelings. And yet when we work on eliciting requirements for systems, the underlying assumption is that that's the case. Intentions, politics and emotions aren't just annoyances that get in the way sometimes, they are intrinsic to the way people experience the world and talk about it.

Great creative writers intuitively understand these processes and expose them in their work. Every piece of dialogue in a good novel or play demonstrates the complex ways in which people convey and construe meaning within a context.

This is why I always find it mystifying when policy-makers and educationalists can't see the practical value of languages and literature studies. The next time someone asks you, "What is the economic value of the humanities?" for goodness' sake don't come up with some feeble stuff about how being able to speak Mandarin or German will help exports. Point them at this post.

At the moment, the most visible area of interdisciplinary research between arts researchers and digital specialists is digital humanities, which seems to mean using technology in the arts. I'd be much more interested in seeing "human(e) digitalities" - the exploration of ways in which hermeneutics, linguistics, social psychology, social theory and philosophy can inform the design of information systems.

Objectively Correct Requirements

by Nick de Voil 23. May 2012 15:23

I've been reading a piece by Tal Bloom on the excellent UXmatters site about triangulation of requirements to ensure that "objectively true" requirements are defined. It's a nice article but I do object to some of the ideas implicit in the terminology.

Without people necessarily realising it, the chimera of "objectively true" or “correct” requirements has bedevilled development projects for decades and there's a widespread but largely unspoken belief in the validity of the concept.  I don't believe it's helpful. A requirement is not a neutral fact and the idea of objective truth is simply not applicable when speaking of requirements.

A requirement is in reality a complex speech act [1] within a complex context. I would formalise this as follows.

Part 1 (Context): Person or group of people A asks and/or pays another person or group B to design, construct and/or deliver a product or service C, which will be used for functions D1..Dn by a person or group E in context F.*

Part 2: (Speech act): A says to B, “you will have fulfilled our contract if and when the situation G, i.e. the use of C by E in F, is characterized by attributes H1..Hn when perceived by person or group I.” **

Now, if we're talking about the engineering of a physical deliverable such as a building, a bridge or an aircraft, then D1..Dn and F are stable and don't vary depending on the identity of E, and we can define H1..Hn in ways that are relatively uncontroversial and don't vary depending on the identity of I. In this context, D1..Dn support simple and universal physical human activities such as locomotion and shelter. F is bounded by well-known laws of physics, physiology, meteorology, geology, mechanics and so on.

However, if the system under consideration is a human activity system, or an information system that is to support a human activity system, then D1..Dn and F are subject to unpredictable change and H1..Hn are hard to define in a reliable and uncontroversial way. In this context, D1..Dn support activities, tasks and objectives which can often only be defined in terms whose meaning is individually or socially constructed. The same applies to F.

So Part 1 presents some difficulties of its own where "objective truth" is concerned, although the requirements engineering and business analysis fraternities have gone a long way towards developing solutions. But the real problem is Part 2. A speech act of this type isn't amenable to evaluation in terms of truth. It's a performative [2] utterance rather than a constative one - in other words, it doesn't purport to be a statement of fact. Rather, it constitutes the taking of a position by an actor. To complicate matters further, a truly holistic view would recognise that in practice there are often multiple contracts negotiated between different pairs of stakeholders.

It's curious that the way we often talk about requirements seems to owe a lot to the ancient Greek philosophers. To speak of "impurities" in requirements suggests that a requirement is a substance like iron or gold with an inherent essence, as Aristotle might have said. In view of the complex web of meanings implied by the above, this is clearly wrong. Likewise, language such as “vision”, “lift individuals beyond their own personal, limited perspective into a place of true collaboration” and “objectively true project requirements” implies a belief in a Platonic ideal which the deliverable should approximate or tend towards. I think we need to look at things a different way and recognise that no such ideal ever exists except for very "hard" systems engineering problems.

All that said, I agree with the central point of the article, which I would put this way: the most reliable way of reaching an outcome which is satisfactory to all parties is to ensure that A1..n, B1..n, E1..n, I1..n all have the opportunity to reach a shared understanding of what constitutes G and H1..n. I would add that, for a complex product, this is a cyclical process informed by experience and dialogue, like all human meaning-making (hence the value of prototyping and perpetual beta). It might be tempting to suggest that something must be objectively true if a large number of people agree on it, but that consensus will often only be a fleeting one.

 

*Note on Part 1: This definition can be broken down further as follows:

 Part 1.1 (Contracting context) ): Person or group of people A asks and/or pays another person or group B to design, construct and/or deliver a product or service C1

Part 1.2 (Usage context): Product or service C2 is used for functions D1..Dn by a person or group E in context F.

 

**Note on the whole definition: This describes the situation where the supplier is contracted to provide a product to a customer. A different but increasingly common situation involves a supplier designing a product which it hopes to sell to multiple customers, as follows:

Part 1 (Context): Person or group B decides to design and construct a product or service C, which will be used for functions D1..Dn by a person or group E in context F, in the hope that person or group A will buy it.

Part 2: (Speech act): B say to themselves, "A would wish the situation G, i.e. the use of C by E in F, to be characterized by attributes H1..Hn when perceived by person or group I."

User-centred design adds another perspective to this definition of Part 2:

I says to B, "A would wish the situation G, i.e. the use of C by E in F, to be characterized by attributes H1..Hn when perceived by person or group I".

 

References

[1] Searle, J. (1969). Speech Acts. Cambridge, UK: Cambridge University Press.

[2] Austin, J.L.  (1962). How to Do Things with Words. Oxford: Clarendon Press.

Ration the Passion, Please

by Nick de Voil 9. February 2011 15:01
The number one attribute that any jobseeker must display these days is "passion". And any enterprise that wants your business will swear that they are "passionate" about what they do. I'm not sure when this craze started – I think it was some time in the 1990's. By now, it’s completely out of control. Passion is de rigueur. To be suspected of a lack of passion for one’s work is considered a failing on a par with being "un-American" in the USA of the 1950's or "un-Communist" in the USSR of the 1930's.

The latest manifestation to attract my attention is this article by John Hagel and John Seely Brown entitled "What is your IT organisation doing to fuel workers' passion?" In it, they lament a recent survey’s finding that four out of five US workers are "not passionate about their jobs".

Please, let's get real. Look. The word "passion" means "suffering". You're experiencing passion if you're in the grip of an uncontrollable emotion. Do we really expect workers in a call centre or a burger joint to feel like that about their work? Really?

I think it’s reasonable to expect a footballer to feel passionate about his work when he’s actually engaged in it. Or a musician. But a software developer? A real estate salesman? Don’t be silly. Most of us work to live, rather than live to work.

Is this just a typical old-fashioned Englishman's sang-froid? Maybe. Certainly, when I was younger, it was considered desirable to minimise public displays of emotion, not manufacture them.

And that's the problem I have with this passion business. It is manufactured. It's a fake. A lie. Why do we all go along with it? Maybe because each of us is afraid that we'll be considered inadequate if we aren't "passionate" about our work. Well, to be honest, some days I like my work, and some days I don't. To be truthful, most people I've worked with are the same.

As someone who runs software projects for a living, I have a professional interest in being truthful about people. Robert N. Charette wrote in 2005, "If there's a theme that runs through the tortured history of bad software, it's a failure to confront reality." Nowadays, the rise of the User Experience profession holds out the hope that systems in future will be designed on the basis of a firmer grasp of reality. But that hope will prove illusory if we don't acknowledge what people are really like. We can't design systems that help people in their work if we're designing for "correct" but unrealistic stereotypes rather than real people.

Personas Considered Harmful

by Nick de Voil 3. March 2010 11:37

Personas are one of the staples of current UX practice. Although they are useful in some ways, I've always felt uncomfortable with them and have put some of my objections into this paper. What do you think?

Since writing the paper, I've come across another recent one by Adrienne Massanari which expresses similar ideas. She presents her argument as an application of discourse analysis, which I find very interesting. She says, "IA discourse continues to reinscribe many of the tropes traditionally associated with user-centered and systems-centered design, both of which implicitly marginalize the individuals interacting with technological devices".

Massanari's focus on the discourse of UX (and IA) is helpful. It's the discourse that I object to, rather than the technique itself. I would say the same thing about Agile and Object Orientation - the ideas are great, but some of the things people say about them, and the claims they make for them, are unhelpful.  I referred to this in my talks to the IIBA at their conference and London meeting back in the autumn, where I also made the same distinction between User-Centred Design and Participatory Design that Massanari emphasises in her paper.

User experience for software engineers

by Nick de Voil 1. May 2009 09:48

Bill Buxton has written a good article about co-operation between software engineers and user experience specialists.

I like Sam's comment about needing Engineering Design leaders, because that's exactly what I do.

When you say "design"... what do you mean?

by Nick de Voil 6. February 2009 15:39

George Bernard Shaw (I think) said "England and America are two nations divided by a common language".

He was referring, I suppose, to the jarring experience when you think you're speaking the same language as someone else, only to find them using an unfamiliar word, pronunciation or construction. Or, worse still, when they use familiar words with the "wrong" meanings. As we all know, if you send an Englishman and an American to a clothing shop (apparel store?) to buy pants and vests, they'll come back with quite different things.

There's a similar linguistic problem with some of the communities of practice to which I belong - software engineering, web development and HCI. Take the word "design", for example.

Many people in the digital world are familiar with the distinction between a (graphic) designer, meaning someone who creates visual designs, and a (software) designer, meaning someone who takes system requirements and turns them into program specifications and database schemas. But it's recently dawned on me that in the HCI community "design" has a third distinct meaning. It apparently refers to the entire system creation process, including problem definition, requirements specification and analysis. That comes as quite a surprise to someone from the software engineering community, where the word specifically identifies one step in the process. You can see this in the Rational Unified Process (RUP), for example, where there's an "analysis and design" workflow separate from the "business modelling" workflow and the "requirements" workflow; or in SSADM, whose name itself - Systems Analysis and Design Method - accurately indicates a similar interpretation of the word.

I don't think this is just linguistic nitpicking. It seems to me to be symptomatic of a lack of communication between the two sets of people. Unfortunately this is self-reinforcing, because the two communities won't even notice that they have something to say to each other if they're using the same words to mean different things. For example, I'm currently reading two of the most interesting books I've ever come across about identifying requirements - an activity which I've always referred to under the heading of "analysis" or something similar. They're respectively entitled "Contextual Design" (Beyer & Holtzblatt) and "Interactive System Design" by William Newman and Mik Lamming. Before opening them I never would have guessed that they talked about requirements analysis at all, let alone offered the level of valuable original insight that they do, and which is sadly lacking from most "systems analysis" texts.

Meeting the requirements

by Nick de Voil 4. February 2009 15:12

My house is about 160 years old. It has a certain Victorian charm, but a couple of years ago the roof started leaking. Actually, there had been small leaks for years previously, which we had fixed, but it was only then that the small leak turned into a big one in bad weather. I feared that the time might have come to bite the bullet and get the main roof replaced. The smaller, higher roof at the front of the house had been replaced perhaps 25 years ago, before we bought the house.

We called a reputable local company, and a man came to look at the leak. Naturally, I didn't tell him that we needed a new roof - instead, I showed him the leak and asked what to do about it. Surprise! He told me that we needed a new roof. I placed the order and we made a date for the work to be done.

A few weeks later, after we had cleared everything out of the loft space, the team arrived to do the job. They worked fast and efficiently, and by the end of the day we had a handsome new roof.

Then it rained.

Guess what? The leak was still there. We had spent thousands of pounds on - as we thought - solving the problem once and for all, but to no avail. The leak was still right there.

I won't go into all the painful details of the phone calls, letters etc. that followed. Suffice it to say that eventually they fixed it. Apparently the root cause of the leak was in the 25-year-old roof, not the 160-year-old one. The water was running down inside an inaccessible part of the roof space from the higher roof to the lower one, giving a misleading impression of the leak's origin.

Afterwards, I started thinking about this as a project. It has a lot in common with systems projects I've seen.

  • The customer (me) had a problem - the roof was leaking. I wanted the problem fixed - I wanted to have a situation where water was not coming into my house.
  • I turned to a supplier with expertise in this problem domain.
  • I told them the problem.
  • They proposed a solution to the problem - supply a product, i.e. build a new roof.
  • I accepted their proposal.
  • They carried out the work. Note that, as far as creating the deliverable was concerned, they did a fine job, apparently using trained staff, good materials and best practice techniques.
  • We tested the product by waiting for it to rain (and hoping that this would happen before payment was due).
  • The product comprehensively failed the test.

What conclusions can we draw?

The first thing that occurred to me was that I had failed to communicate the requirements correctly. It wasn't quite as simple as that - rather, I had failed to ensure that the agreement between customer and supplier was specified in terms of the requirement, rather than the product. Should I have accepted the proposal with a letter stating that I considered the absence of incoming water to be the key performance indicator, or critical parameter, for the project? Perhaps. Do systems project contracts get drawn up this way? Very seldom, in my experience.

What guarantee did I have that the product was the correct solution? Was this a classic case of the customer being sold an expensive product that they didn't need and didn't meet the requirements? Was the (prima facie) high intrinsic quality of the deliverable irrelevant? Well, actually I wanted a new roof because I knew that the old one had reached the end of its life and would have become a source of increasing frequent problems. So no, it wasn't irrelevant. But it is true that I got something I hadn't asked for to begin with, even though I wanted it.

Did we have a good user acceptance testing strategy? Well, it was risky, because it might not have rained before we were compelled to pay for the work. Note also that we needed to wait for rain a second time in order to carry out a second, successful test. But it would have been impracticable to simulate the rain before putting the new "system" into production.

How did we manage to reach a satisfactory conclusion? The honest answer is that I'm not sure. Was it because of the leverage we had obtained by not paying too soon? Was it because the supplier felt an obligation to satisfy the customer? Maybe a bit of both. But in the software world, it's quite normal for suppliers to charge extra for remedying problems which aren't within the contracted product scope.

And finally, how typical that the test failure was caused by a problem at the interface between two components!

My advice? Don't buy a Victorian house.

Start here

by Nick de Voil 13. January 2009 19:34

I'll be honest - I've resisted the idea of a blog ever since I first came across the idea. It just seemed big-headed to think that people in general should be interested in my thoughts on things. Anyway, as you see, I've succumbed to the Zeitgeist.

I'm going to talk about my experiences as a practitioner and student of human-computer interaction (HCI) in the context of my background as a systems analyst, project manager and management consultant. I hope I'll also be able to find out what you think about how to make systems that are useful as well as usable. Maybe some of this will be interesting after all.