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.

Interaction in a Social Context

by Nick de Voil 3. May 2012 20:15
I've been interested for some time in how usability can be extended into, and integrated with, the field of enterprise systems design - not just in terms of the surface details of user interface, but also  at a deeper level of what Ronald Stamper calls "organisational semiotics", trying to get away from the Model Human Processor and taking into account things like social psychology, social anthropology, cultural analysis and discourse analysis.

The latest edition of Interfaces magazine has an intriguing article called Enterprise Usability Architecture, which talks about integrating usability with enterprise architecture. The interesting part comes at the end, where it says that "social models of HCI fill a gap that exists in both disciplines". It refers to the "Model of Interaction in a Social Context (MISC)".

This aroused my curiosity. I had never heard of MISC, and nor had Google, but eventually I found it in the PhD thesis of one of the article's authors, Sarah McDaid: "A model for human-computer interaction based on human-human communication in a social context".

MISC is an ambitious model identifying seven "layers" of the human-to-human communication process: task, presentation, session, control, cognition, effector and physical. Without going into all their meanings here, suffice it to say that this scheme is very helpful in showing some of the things that are often left out of consideration, both in ineffective person-to-person communication, and in traditional systems design. MISC then goes on to identify elements for consideration at each level. Some of these are familiar - for example, the Task level includes consideration of Goals, Sub-tasks etc. But others are less so. At the Presentation level, Roles, Relationships, Responsibilities, Social Rules and Social Norms are considered. The Session and Control levels deal with conversation structure.

Most interesting for me is the so-called Cognition layer. As McDaid writes, "This layer endeavours to take account of the personality and life-experiences of the participants and the impact that this has on their interpretation of the proceedings around them. These elements of the model are principally derived from work done in the field of social psychology." It includes elements like personality, emotional state, causal attribution, stereotyping and meta-perception.

The article in Interfaces does not specify how any of this is to be integrated into enterprise architecture, but I like McDaid's agenda and I do believe that this is a useful framework from which many good things might come.

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.