[ID Discuss] on Mind the Gap!
Software Engineers and Interaction Architects

To: Interaction Designers <discuss@interactiondesigners.com>
From: Matthias Mueller-Prove

Dear ID/As,

  ’cause this is my fist mail to this group I like to say "hello" to all interaction designers and architects. In addition to this 5 letters, let me point you to a short paper I wrote for Interact 2003 in Zurich. Title is "Mind the Gap! Software Engineers and Interaction Architects"

best,
Matthias

Welcome to the list, Matthias!

Okay now. Ever since I read "The Inmates Are Running The Asylum," I’ve been wanting to write a critique of the software-engineer stereotype that Cooper promulgates. Don’t take this too personally, Matthias; our professional experiences are probably very different. But since you posted this link, I’ll take it as an invitation to start a discussion. :-)

In the above paper, you write:

"Software engineers live in their own world. With few exceptions, they only focus on computers and themselves. A problem is seen as solved as soon as the algorithm is correct and the compiler does not come back with any syntax errors."

That might be how it’s done in undergraduate programming classes. But in the real-world software teams I’ve been on, this isn’t true at all. Engineers balance many different factors as they work: correctness, understandability of code, making code adaptable to later changes (often by other people), speed of development, likelihood of introducing new bugs, runtime resource usage, decoupling of subsystems, testability, conformance to specs and coding standards, etc. In other words, a LOT of what engineers think about are, in fact, human factors issues! (For other engineers, not for users; but that’s the nature of the role.) Good code craftsmanship means writing for humans, not just writing for the computer.

Software engineering is rarely black-or-white, correct-or-incorrect -- the "binary" metaphor is cute but inappropriate. The design of code is like any other design process: intuitive, rational, iterative, organic, and full of tradeoffs. For any code-design decision, we consider all the above factors (and perhaps others), then choose the best we can from countless possible "correct answers." For bug fixing, we use intuition as much as we use logic – we explore ideas, form hypotheses, and experiment with possible fixes. Programming is a creative act. Don’t let anyone convince you otherwise.

If you still aren’t persuaded, consider this: among the software engineers in all the companies I’ve worked in, you can find a disproportionate number of musicians, painters, writers, poets, gardeners, cooks, textile artists, photographers – good ones, too. This just doesn’t fit Cooper’s stereotype of engineers.

You go on to say:

"As far as usability is concerned they are at best clueless, because usability was not part of their education."

Whenever I’ve seen the concepts of usability introduced into an engineering organization, the engineers themselves seem to have no problem with it. Though they might be skeptical of techniques advertised as "silver bullets," they’re smart enough to see that usability can help them craft better products. And in recent years, engineers frequently come into organizations having already learned about usability – they know what it’s about!

Resistance to usability testing and related techniques might instead come from clumsy attempts to fit it into an existing design/development process. Or from engineers’ resentment of designers and utesters, many of whom who will not meet engineers halfway by learning their language and understanding the technology-imposed design constraints. (Since "Inmates" was published, a few people seem to treat engineers even more dismissively and patronizingly. Real-life example: what is the point of scolding an engineer for conducting part of a usability test, when that engineer has learned how to do it well? It ain’t brain surgery, folks.)

Then again, I do wish that design and usability were taught as part of the standard software engineering curriculum! That could certainly help matters. Many engineers (and managers) still don’t see IxD and usability as indispensable parts of the development process.

You continue with:

"The attitude software engineers have is without a doubt fine in their own minds, and their standpoint is rarely challenged by other people in the product development process. ..."

Does the stereotype suggest that all software engineers are arrogant and myopic? And unable to appreciate other perspectives on the development process?

I’ve known a few software engineers like that – often the most brilliant ones – but it’s not fair to paint us all with that brush.

"...Therefore, it is not surprising that engineers see no reason to take the suggestions of interaction designers seriously, since they usually just mean more work. Engineers block suggestions by responding that they are not feasible for technical reasons."

And sometimes they’re really not feasible! As I said before, some designers don’t bother to learn the technical constraints under which the designs need to be made. Software can be written to do almost anything, but the cost of an unrealistic design can be outrageous! Engineers have to balance the value of a design against its cost. If designers could work with engineers in a more collaborative manner, with less of a "design it and throw it over the wall" attitude, engineers might take designers’ and testers’ suggestions more seriously.

Nevertheless, in my experience, I’ve rarely seen such suggestions being rejected outright. The cases I have seen were due more to schedule constraints – unrealistic expectations – than to ideological issues, turf wars, or power struggles. But I won’t pretend those don’t happen.

At the risk of overgeneralizing, I’ll say that most engineers I’ve known are not really interested in power as such. Being human, their motivations are complex; but fundamentally, they want to build good software. If they can be convinced that designers and usability experts have something to offer them, they’ll cooperate with you! But patronizing them will not work. Shrouding the design/testing process in artistic mystery and pseudo-science will not work. What DOES work is teaching them how you do what you do, partnering with them, and showing them exactly how you can help them make better software in less time.

So even though I think your premises are wrong, Matthias, I agree with your conclusions. You talk about in-house training, "supporting findings with quantitative data" (what counts here is good science, not just the presence of numbers!), and explaining how designs are arrived at. Yes. These work. As in any field, good professionals will respect other professionals who can do what they cannot – as long they bring value to the table.

"The conclusion is that it is necessary for both groups to gain respect for the different areas of expertise and have an understanding of each other’s perspective. Otherwise, the fruits of beneficial cooperation will be a long time coming."

Hear, hear!

    - Jenifer

Jenifer Tidwell

Alan (Cooper)’s broad-brush characterization of software engineers is to some degree (the amount is surely debatable) hyperbole, which I think I can say (having co-authored a book with him) is Alan’s favorite rhetorical device. But if you’ve ever had the chance to hear Alan speak, you’d know he doesn’t look down on engineers or programmers. SW engineers include some of the most brilliant and talented people I’ve ever met – but their talents don’t typically include empathizing with end users.

At its core, "Inmates" does underline a key truth, which is implicit in what you yourself state:

"Engineers balance many different factors as they work: correctness, understandability of code, making code adaptable to later changes (often by other people), speed of development, likelihood of introducing new bugs, runtime resource usage, decoupling of subsystems, testability, conformance to specs and coding standards, etc. In other words, a LOT of what engineers think about are, in fact, human factors issues! (For other engineers, not for users; but that’s the nature of the role.)"

The point is a simple and perhaps obvious one: that engineers are not as a rule thinking about the end user experience as they code, and even when they are, they are in a conflict of interest between technical, time, and resource demands and user needs. "Inmates" target audience was business decision makers (though many more designers and engineers have probably read it), and the message was: don’t leave decisions on user experience in the hands of people who a) aren’t experts on it, and/or b) are conflicted by it; instead, look to user experience specialists to provide input to those decisions.

While it’s certainly true that many developers and development organizations are good citizens, it’s also true that many, perhaps subconsciously, take advantage of the power they wield in an organization. My experience suggests that many engineering-driven companies do have some level of issue with engineering thinking dominating the process of product definition. I worked with dozens of different organizations as a consultant at Cooper, and saw a broad spectrum of organizational behaviors. "Inmates" as you can tell by the title, was targeted at managers of problematic organizations, with the hopes of getting user advocates a seat at the table there.

But once you get that seat, it’s up to you to make it work. I agree with absolutely everything you say about partnership and cooperation between engineering and design/usability. The way to ensure things won’t work is by setting up a competitive or adversarial relationship between these groups. When I was brought in as a consultant, especially by non-engineering groups, engineers often reacted with initial suspicion – and why not? I could have easily represented a monkey wrench that would throw off their deadlines, resource planning, and architectural assumptions with difficult to implement solutions. So it was important to meet with technical stakeholders early to let them know that while some of our design work might challenge them, it was going to be within the realm of what they agreed feasible, and that I was going to work closely with them at every step of the way to make sure that was the case. Another big help was having research, rigorous process, and a set of principles that could be used to rationally balance the pros and cons of any design/implementation decision.

Robert.

Robert Reimann
Manager, User Interface Design
Bose Design Center

"Software engineers live in their own world. With few exceptions, they only focus on computers and themselves. A problem is seen as solved as soon as the algorithm is correct and the compiler does not come back with any syntax errors."

That might be how it’s done in undergraduate programming classes. But in the real-world software teams I’ve been on, this isn’t true at all. Engineers balance many different factors as they work: correctness, understandability of code, making code adaptable to later changes (often by other people), speed of development, likelihood of introducing new bugs, runtime resource usage, decoupling of subsystems, testability, conformance to specs and coding standards, etc. In other words, a LOT of what engineers think about are, in fact, human factors issues! (For other engineers, not for users; but that’s the nature of the role.) Good code craftsmanship means writing for humans, not just writing for the computer.

I have to strongly disagree: It has nothing to do with human factors. Even if it would, the person who does everything you have described above well can be called "an ideal software-engineer". I admit there can be few people with such charachteristics but it is rather an exception.

Does the stereotype suggest that all software engineers are arrogant and myopic?

No. Of course not. Not _all_ engineers. But the most of them. Do you see the difference?

regards,
Andrei Sedelnikov

usabilist.de

Disclaimer: I’m working in a large organization with thousends of so called "software-engineers", and I observe the evidences of what the Cooper says everyday.

On Tue, 3 Feb 2004, Andrei Sedelnikov wrote:

Engineers balance many different factors as they work: correctness, understandability of code, making code adaptable to later changes (often by other people), speed of development, likelihood of introducing new bugs, runtime resource usage, decoupling of subsystems, testability, conformance to specs and coding standards, etc. In other words, a LOT of what engineers think about are, in fact, human factors issues! (For other engineers, not for users; but that’s the nature of the role.) Good code craftsmanship means writing for humans, not just writing for the computer.

I have to strongly disagree: It has nothing to do with human factors.

Really? Designing something so that it can be read, understood, and improved by others has "nothing to do with human factors"?

Even if it would, the person who does everything you have described above well can be called "an ideal software-engineer". I admit there can be few people with such charachteristics but it is rather an exception....Disclaimer: I’m working in a large organization with thousends of so called "software-engineers", and I observe the evidences of what the Cooper says everyday.

Our experiences are very different, then. In twelve years of working in software organizations, I’ve seen almost all engineers be concerned about the issues I listed above – and most strive to be better at them. Yes, I described an ideal. But many come very close to that ideal.

(If that’s not so in your organization, then I pity its customers, because these things must be taken into account if one wants to build good software.)

Does the stereotype suggest that all software engineers are arrogant and myopic?

No. Of course not. Not _all_ engineers. But the most of them. Do you see the difference?

Certainly. And it’s still insulting to software engineers.

I beg of you all – please consider the negative effects of stereotyping. Will it really help you establish an effective design and utesting presence in your organization (assuming that’s what you’re striving for)? Or would you be better off working cooperatively and empathetically with the engineers who will build your designs?

    - Jenifer

Jenifer Tidwell

I have to strongly disagree: It has nothing to do with human factors.

Really? Designing something so that it can be read, understood, and improved by others has "nothing to do with human factors"?

I meant how does it concern the usability of the end-user product? From my observations, the software-engineers will be trying to provide something readable and understandable for their collegues only if they will be forced by the management to do so. Left alone, each software-developer will only try to please himself. :(

Our experiences are very different, then. In twelve years of working in software organizations, I’ve seen almost all engineers be concerned about the issues I listed above -- and most strive to be better at them. Yes, I described an ideal. But many come very close to that ideal.

(If that’s not so in your organization, then I pity its customers, because these things must be taken into account if one wants to build good software.)

That’s a corner stone! How do the customers can determine the quality of the software product execept counting the number of features? They [usually] don’t have a single cue how to do it! That’s why the management personal of the software company do not care about such things.

And it’s still insulting to software engineers.

[Ironically] Ah! Poor children!

I beg of you all -- please consider the negative effects of stereotyping.

For several years the "steering wheel" was in the hands of
software-developers because noone could understand what they are doing. But the times are changing. That "stereotyping" is just a way to show other people and to explain what really happens.

Will it really help you establish an effective design and utesting presence in your organization Or would you be better off working cooperatively and empathetically with the engineers who will build your designs?

Personally I always try to keep good relations to software engineers. And the knowledge of their nature only helps and does not disturb.

regards,

Andrei Sedelnikov

usabilist.de

Hi. I come from a design background, and the field of Interaction Design in India (small though it is) is full of product and visual design professionals who crossed over some time during the past 15 years and are largely self-taught.

Personally, I taught my first course on user interface design back in 1994, and have been a teaching Interaction Design professionally since 1998 in a design school.

When I teach a course on HCI / Interaction Design / Usability, I sorely miss teachers / courses from the backgrounds of cognitive psychology, instructional design and written communication. (We are lucky to have teachers and courses in design, information theory, ergonomics and software engineering at our institute). I try to compensate by inviting guest speakers and by trying to teach missing topics myself. But I really look forward to the day when we can offer a cohesive instruction from all branches under one roof. (I admire film institutes in this regard.)

In my experience, I have never met people from ANY discipline who are particularly fond of producing bad products. But good intentions don’t make good products. On the other hand, I have also not met many people who have fluent knowledge of all disciplines needed to produce good products. Ethnocentric behavior doesn’t make good products either. In our case, there is no alternative to teamwork.

I like what Beyer and Holtzblatt suggest in their book - one needs to adopt processes and techniques around the people we have. I have been teaching introductory courses on HCI to working professionals, including many software engineers. I have found them quick on the uptake and hungry for more. Many of them apply what they learnt pretty quickly in their next project, and go much beyond what I ’taught’ them.

As a field we are on the intersection between many disciplines. We need to make sure that we stay in the intersection and not fall in the cracks. We need more people who can build bridges across disciplines, not the ones who look down upon others. For a while that might require a design teacher to teach cognitive psychology, or a software engineering teacher to teach design, often at the risk of doing so from half-baked knowledge. But from such efforts will emerge better interaction designers (and better interaction design teachers) of the future.

No offence meant, but in this context, I do find Allen Cooper’s books hard to recommend, particularly to software engineers. I get the point when I read them, but ’software-engineer-bating’ is not a solution, and could be counter-productive. (I must say that About Face 2.0 was much mellower and very useful. Was it an effect of the co-author?) I could say the same thing about some other comments I have read / heard about designers, particularly in the late 90s.

There is a long way to go, and there is enough room for everyone. We really don’t need to fall in the cracks.

My two cents.
Anirudha

In my experience, I have never met people from ANY discipline who are particularly fond of producing bad products. But good intentions don’t make good products. On the other hand, I have also not met many people who have fluent knowledge of all disciplines needed to produce good products. Ethnocentric behavior doesn’t make good products either. In our case, there is no alternative to teamwork.

I think that most of the issues that come with dealing with software engineers (and others) come from the fact that we’re all human. We all have different backgrounds, perspectives, perceptions, and goals. Sometimes, the software engineers are faced with the choice of making something that they *know* is "bad" and not shipping something at all (and being punished for it). Or, they really want to work on the internals, and the interface is an afterthought because it isn’t a priority for them. Other times, for whatever reason, they have the perception that they know what is the "right" thing to do and what they’ve done is "good" from a design and/or usability perspective.

What works best is to work cooperatively as much as possible. When there is conflict, decide whether or not it’s a fight worth fighting. In my own situation, I’ve cultivated relationships with some engineers to the point that they almost always come to me first for advice or to have me design interfaces for them. I stopped trying to persuade some others that were very resistant or hostile to my suggestions. In some cases, some of my cultivated software engineers have ended up pushing the other engineers enough to affect change.

So, in short, we’re all human, work as a team, and choose where to expend your energy.

Ron

Ethnocentric behavior doesn’t make good products either.

I’m assuming by "ethnocentric" you mean something like: designed predomimently with the needs of one particular cultural/langugae group in mind.

I see this sort of assertion (along with similar assertions about accessibility) bandied about a lot. I suppose a lot of it depends on what you define as a "good product". Is a good product one that has the highest prospective market or is a good product one that best satisfies its users? I tend to favour the latter, though obviously business cases can be made for maximizing prospective market. Mediocrity often results from the pursuit of maximal market share because you typically can’t achieve "best for everyone" in a single design.

For example, I was recently working on a design for an interface that I scrapped because it didn’t work on languages requiring long textual descriptions (I used German). The final product was *worse* for a huge percentage of users (who spoke english, spanish, japanese, etc). As a trade-off, we got a larger potential market. It didn’t make sense for one small interface in the final product to restrict us from supporting German, so we chose larger potential market. If this interface had represented the whole product, I probably would have been "ethnocentric" and simply not supported German and some other languages.

Accessibility presents many similar situations. In general, the more types of user you must accomodate, the worse the design is to those users.

There are many good arguments that can be made for accessibility and "internationalization" on the basis of being the Right Thing(TM) to do, being globally conscious, being socially conscious, and in the US being marketable to the government and large companies. I’m not anti-accessibility or anti-i18n ;-) But I think its important as designers when we are thinking through issues to remember the reasons behind broad decisions and approaches.

-Seth

I should have clarified - here by ethnocentric I meant ’profession centric’. All people in the entertainment industry are a group. But within that there are film-related and others. Within film-related, there are directors, actors, cinematographers, sound engineers, editors, writers, music directors, musicians, singers etc. But they all work as a team of people from different professions. In a low budget film, one might not hire a sound engineer (I would say a bad decision), but someone in the unit better know how to do sound engineering to an extent. Competition exists between such teams, not between professions.

Anirudha

Hi,

thanks for the warm welcome. Let me add just some points to the discussion.

Of course, Jenifer is right. Engineers, esp. if they belong to the professional ones - do care for the interaction between engineers on the level of source code. Software engineering is a serious and hard discipline. For example, extreme programming (XP) is one of the most interesting movements in software engineering that demonstrates how engineers approach the problems of working together, and delivering better products for the customers and users.

Nonetheless, if a team does not function well it is in many cases related to the Cooper-Inmates effect.

Having a stereotype of anyone is dangerous. On the other hand, what else are personas – to a certain extent? You have to be aware that engineers and users do not match your expectations. Give them a chance to be different and treat them with the dignity and respect they deserve.

I am more surprised that none of you tackles my statement: "Interaction architects tend to perceive themselves as artists."

This is another stereotype that does not bridge the gap between engineering and interaction design. Both groups strive for elegance – thanks Jim for this term. But the focus of their activities is not necessarily the same.

The way I perceive my job is much closer to engineering than to graphic design. I have strong methods and techniques at hand to support my UI designs. My MSc in Computer Science and my experience with international development teams is my backing in interacting with my colleagues at work.

all the best
Matthias