Kevin Cheng  

Type Mismatch: HCI and Programmer Communication Barriers

October 9th, 2004 by Kevin Cheng :: see related comic

A friend of mine once answered, when asked why he joined an MSc program in HCI, “I studied computer science in my undergraduate and I want to become bilingual.” The term is interesting because it implies the two roles speak different languages. If that is indeed the case, how can any communication occur? In software, these teams must work closely together. Overcoming communication barriers is not only about understanding each other but also, perhaps more importantly, avoiding misunderstanding each other.

Basic Vocabulary

When one learns a new language, whether it’s a programming language or a spoken dialect, some basic principles apply. Grammar, vocabulary, structure are all elements that build a foundation for learning the language. To learn the language, these elements are often compared to existing knowledge; “How do I say ‘where is the toilet’ en francais?”, “What does this term mean in English?”, etc. are examples of these parallels being made.

A basic view of each other’s vocabulary is important for both sides to possess for real progress to be made. Lacking this understanding could leave the programmer with, “it can’t be done” and the HCI responding with, “it’s unusable” - without further clarification from either side, it’s a stalemate. The responsibility lies in both camps to understand the mapping between the two languages. Just as one need not be fluent in a language to understand the message being conveyed, neither does the professional need to know the other’s job in depth to communicate more effectively.

One possible start is to compare vocabularies and find similarities. Some ideas for vocabulary mappings, but certainly not a comprehensive list:

Prototype - In a recent discussion on the Interaction Design mailing list, a distinction between technological and design prototypes was discussed. Different languages can often use the same word to mean different things. In a technological sense, a prototype is a proof of concept (POC) - used to determine the feasibility of a technology or design. In the HCI and design sense, prototypes are often iterations towards a final solution, intended simply to solicit feedback or facilitate discussions.

Scenarios - most development organizations now require their programmers to also design and program test cases for their own programs, sometimes before even writing the program itself. HCI approaches this in a similar fashion by creating scenarios they expect users to encounter or run through. One major distinction is that scenarios cover the most likely of cases and only sometimes include the edge cases. They will never, ever, cover every possible scenario. Programmer test cases, on the other hand, frequently place emphasis on the edge cases and can be much more comprehensive in the test coverage.

(UI) Code Review/Read - typically a process in which a peer reviews the code of a programmer. The criteria of the evaluation can vary depending but the purpose is a peer sanity check. In HCI, it’s also necessary to review interfaces to ensure the implemented interface matches the original designs not just visually, but in the nuances of the interaction. Call it a User Interface Code Read if you will.

On Being Bilingual

What about those who are bilingual? Who speak both languages? I also have a technical undergraduate background prior to my move into HCI several year ago. I pride myself in having enough of an understanding of programming to discuss limitations and compromises with those developing my designs. However, there is a difference in being bilingual and being dual role. Some take bilingualism to mean they develop the application or tool as well as execute on the HCI aspects. While this is certainly possible and has been done successfully by some, caution should be taken.

Ever learned a language and then gotten the vocabulary or grammar mixed up with another familiarized language? When one performs both duties of HCI and programmer with an assumption of understanding both, it’s quite easy to be blinded by one and forget the other. For example, when put in a similar situation, I have found myself limiting my design choices based on what I knew to be technically feasible. Instead of coming up with the optimal design, I was doing so within the constraints of what I believed to be most optimal and possible. While pragmatism has its place, such an approach is akin to shooting yourself in the foot before starting the race.

Not Just Language

When one visits a country on holiday for a weekend, do they feel they know the place, even if they can speak the language? Certainly not. Beyond understanding the language of each other, the culture must also be taken into consideration. To perform the duties of programmer requires different approaches and thought processes from HCI. Similarities exist, of course, as the vocabulary mapping suggests, but it’s easy to mistaken similarities for identical mappings. Subtle differences in priorities, methodologies and rigor aren’t immediately obvious and require time, patience and most importantly, an open mind, to absorb and integrate into a cohesive team.

Learning another language is sure hard work.

7 Responses to “Type Mismatch: HCI and Programmer Communication Barriers”
Graham Storrs wrote:

I’m sure we all struggle with this all the time. Probably the most fundamental difference of understanding is when the two groups use the term ‘user interface’. To the UI specialist, the term is immensely rich, implying all kinds of things about how interaction unfolds and work is structured. To the developers, the term just means ’screen’ - a wafer-thin interface where commands are collected and interpreted and data is presented. To someone who uses ‘user interface’ to mean this, telling them you are a UI designer says something like “I lay out controls on screens - like any newly-graduated programmer can do - only I do it from a position of total ignorance of the requirements of the underlying system.” It’s no wonder our profession gets so little respect from them!

Bob Salmon wrote:

A general point about language is how it’s tied to culture and identity.

Why do school children have their own slang? Why do script kiddies use l33t etc? Knowing the language defines the group, and by implication, not knowing the language defines who’s outside. Every group, including programmers, HCI practitioners and managers, will tend to define itself by language (and other things like rituals and customs).

I think it’s useful to recognise that there is a different group from you (in my case HCI practitioners), that it has equal value to yours, that it isn’t necessarily a threat to yours, and then you might stop feeling the need to use language as a barrier.

Knowing another group’s jargon is useful. If you’re confident you know it properly, you can communicate effectively with someone in that group. An odd example. Once, at college, a group of us were preparing a lunch for lots of people. A mathmetician friend of mine came to help, and had to chop nuts into a salad. He was chopping them quite large, and I knew that they had to be small in order to be distributed around the salad. I told him “We’re trying to approximate a continuus distribution with a discreet one.” Lightbulb goes on above his head and he chopped them finely.

dave wrote:

I find the biggest vocabulary problem for me and people from an engineering background is the word “design”. For engineers, “design” is a plan. For a designer “design” is a process whose end result is a plan. This discrepency exists with other non-designers as well–business-side/marketing folks, QA, and even researchers and usability professionals. Understanding these two meanings of the word “design” to me is one of the primary vocabularly problems between designers and non-designers.

Amongst designers there is a pretty good understanding of the iterative, deconstructive, out first then in towards a solution, repeat, methodology that we need to be doing. Everyone else, just expects us to to come up with stuff off the top of our heads based on the research (if that is even available).

Leo wrote:

Even the term “scenario” strikes a dischord when raised in a hetergeneous HCI/Developer team. Recently, I suggested that I would be creating “scenarios” to assist in understanding the use of the proposed system.

“Oh, use cases,” the lead S/W Architect replied.

15 minutes later it was apparent that my attempts at describing the differences were not getting through.

David D. Levine wrote:

Lacking this understanding could leave the programmer with, “it can’t be done” and the HCI responding with, “it’s unusable” - without further clarification from either side, it’s a stalemate.

When a programmer says “it can’t be done”, that means “I don’t want to do it.” When a programmer says “it will confuse the user,” that means “I don’t like it.”

I have found myself limiting my design choices based on what I knew to be technically feasible. … While pragmatism has its place, such an approach is akin to shooting yourself in the foot before starting the race.

I’m going to have to disagree on that one. I don’t feel that coming up with a design that can actually be implemented is “akin to shooting yourself in the foot” — rather, it’s part of a savvy designer’s methodology. Designers who refuse to consider aspects of practicality and feasibility in their designs rarely get what they want and often cause friction with the implementers.

noah wrote:

Definitely disagree with you there as well. Your context makes it clear: if you’re performing both roles, you’re designing to your own strengths. It’s better when given the room to design blue-sky and allow others to refine it down where and when needed through process… but if you’re programming your own designs, you damn well better know how to implement it. That’s not shooting yourself in the foot before a race, that’s guaranteeing you’ll cross the finish line.

dave wrote:

If I’m worried about how to implement it, will I push the barriers of creativity? I know it is a reality that many have to implement their own designs … but I wonder if you could do so in such a way where creativity is not lost in the process. Can people separate the left and right sides of their brain?

I do know that design works best when there is a clear line where evaluation of ideas is not happening at the same time as the creation of ideas. What this allows is that mixing of ideas which can’t exist if you never allowed yourself the full spectrum of ideas in the first place. What I love about design is how it understands that there is a grain of truth in every piece of expressed madness. Can that come out when the madness is kept in check by prozac?


Leave a Reply


OK/Cancel is a comic strip collaboration co-written and co-illustrated by Kevin Cheng and Tom Chi. Our subject matter focuses on interfaces, good and bad and the people behind the industry of building interfaces - usability specialists, interaction designers, human-computer interaction (HCI) experts, industrial designers, etc. (Who Links Here) ?