Mind the Gap!

2 Feb 2004 - 4:53pm
10 years ago
6 replies
424 reads
mprove
2004

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"

http://www.mprove.de/script/03/interact/

best,
Matthias

--

User-Centered Software Design http://www.mprove.net

Comments

3 Feb 2004 - 8:17am
Jenifer Tidwell
2003

On Monday, February 2, 2004, at 05:53 PM, Matthias Mueller-Prove wrote:

> 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"
>
> http://www.mprove.de/script/03/interact/

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
w: jtidwell at mathworks.com
h: jtidwell at alum.mit.edu
http://jtidwell.net/

3 Feb 2004 - 11:23am
Robert Reimann
2003

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

-----Original Message-----
From: Jenifer Tidwell [mailto:jtidwell at animato.arlington.ma.us]
Sent: Tuesday, February 03, 2004 9:17 AM
To: Matthias Mueller-Prove
Cc: Interaction Designers
Subject: Re: [ID Discuss] Mind the Gap!

On Monday, February 2, 2004, at 05:53 PM, Matthias Mueller-Prove wrote:

> 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"
>
> http://www.mprove.de/script/03/interact/

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
w: jtidwell at mathworks.com
h: jtidwell at alum.mit.edu
http://jtidwell.net/

_______________________________________________
Interaction Design Discussion List discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

3 Feb 2004 - 2:36pm
Jim Hoekema
2004

One small footnote to this discussion:

At their best, both UI designers and SW engineers strive for "elegance" in
what they create. But the two views of "elegance" can be at odds.

An elegant software solution always includes economy of means -- which you
could hyperbolize as the greatest functionality from the fewest lines of
code (I'm sure there are better ways to characterize it).

For UI designers, elegance is defined in making the program's behavior
conform as "naturally" as possible to user models and behavior. This can
lead to some fairly elaborate bits of software just to serve the quirky and
messy way that users approach the task at hand. What seems "elegant" in
matching user expectations can seem highly inelegant and inefficient from a
strict software viewpoint.

- Jim Hoekema
Pepsi Bottling Group

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesigners.
com] On Behalf Of Reimann, Robert
Sent: Tuesday, February 03, 2004 12:24 PM
To: Interaction Designers
Subject: RE: [ID Discuss] Mind the Gap!

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

-----Original Message-----
From: Jenifer Tidwell [mailto:jtidwell at animato.arlington.ma.us]
Sent: Tuesday, February 03, 2004 9:17 AM
To: Matthias Mueller-Prove
Cc: Interaction Designers
Subject: Re: [ID Discuss] Mind the Gap!

On Monday, February 2, 2004, at 05:53 PM, Matthias Mueller-Prove wrote:

> 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"
>
> http://www.mprove.de/script/03/interact/

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
w: jtidwell at mathworks.com
h: jtidwell at alum.mit.edu
http://jtidwell.net/

_______________________________________________
Interaction Design Discussion List discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/
_______________________________________________
Interaction Design Discussion List
discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

3 Feb 2004 - 7:08pm
Andrei Herasimchuk
2004

On Feb 3, 2004, at 12:36 PM, Hoekema, Jim {PBG} wrote:

> At their best, both UI designers and SW engineers strive for
> "elegance" in
> what they create. But the two views of "elegance" can be at odds.

My personal experience with this is that the two standards for
excellence are hardly ever at odds, it's usually nothing more than a
communication breakdown. Think of it as designers speak French and
engineers speak Italian. Their communication and effectiveness hinges
on how well the people in each group understand the other's language,
which includes nuance of translation and culture. But the fact they
each have difficulty with each other's language doesn't mean they both
don't like good wine.

Andrei Herasimchuk
andrei at adobe.com

work: http://www.adobe.com
personal: http://www.designbyfire.com

3 Feb 2004 - 8:02pm
Andrei Herasimchuk
2004

On Feb 3, 2004, at 5:08 PM, Andrei Herasimchuk wrote:

> My personal experience with this is that the two standards for
> excellence are hardly ever at odds,

Obviously that should have read "elegance", but excellence works as
well.

Andrei

4 Feb 2004 - 10:20am
Don_Hanson at N...
2003

Greetings,

I think those are some excellent comments, but I would have to add one
very large caveat: Everything you said has applied to projects I've
worked on in the past with good teams. Sadly, I have a number of
experiences where this was not the case.
You might be thinking that was the past, this is now, things
must be different. I've been at the same company (~1 billion annual
sales) for a couple of years now. The project I just finished was
probably the best I've worked on in my eleven year career. Sadly for me
the one I am rolling on to has every problem, and more, described by
Matthias. (thankfully it is a short project)

Although I would love to believe workshops like this are unneeded,
direct present-day experience says otherwise.

Cheers,
Don

------------------------------------------------------------------------
-----------------------------

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
w: jtidwell at mathworks.com
h: jtidwell at alum.mit.edu
http://jtidwell.net/

Syndicate content Get the feed