Fog Creek Software
Discussion Board

Interaction design -- anyone?

I was just wondering if anyone here is active in the field of interaction design, or by whatever name you refer to it.

Just to make sure I get replies on the question, not the terminology; by interaction I mean the interaction between the system or product and its environment (environment = adjacent systems: machine or man).

So the question is, are any of you responsible for defining the behaviour of a system or product that is immediately visible by, and impacts, adjacent systems? In particular people.

I also mean in detail, from the adjacent system's perspective.

I ask because judging by most of the discussion I get the impression that the majority of visitors is either responsible primarily for the internal design of a system or product in order to achieve the desired behaviour, or for managing the project.

Practical Geezer
Thursday, December 19, 2002

Machine-machine interaction and human-machine interaction are two very different disciplines.

Human-machine interaction falls under the topic of Human Computer Interface (HCI), also known as Human Factors.  This is all about user-friendly interfaces, making the program model work as closely as possible to the user's conceptual model, streamlining frequent tasks, and so on.  The good HCI compensates for a human's relative slowness and propensity for error, and is often visually appealing to reduce stress.

Machine-machine interaction is all about speed and correctness.  It can go thousands of times faster, but even small discrepancies in data can cause breakage if the design is careless.  The good MMI optimizes the communication protocol to send the most amount of information in the least amount of time, and pretty much ignores any other considerations.

Paul Brinkley
Thursday, December 19, 2002

I've not heard the term before.

I design and implement commercial software marketed at the general public. This includes all aspects of the UI and a vast array of other software and hardware devices that my software must interact with. Do I qualify? not sure where your inquiry is headed. I don't have any 'interaction design' classes in my background though, but I do use all the software I write which provides many insights and all the customers I talk with tell me that my usability is greatly superior to that of my competitors so I guess that counts for something -- I listen to their feedback and suggestions a lot and also discuss things with them and try to get into details about what they like about different features and how they work with them. They seldom have specific suggestions to make but once I get two support requests over a given thing, I start looking very carefully at how to make it better.

X. J. Scott
Thursday, December 19, 2002

Check out Alan Coopers UI design book in Joel's list and read his other book "The Inmates Are Running the Asylum : Why High Tech Products Drive Us Crazy and How To Restore The Sanity":

fool for python
Thursday, December 19, 2002

I'm not directly involved in interaction design, but I certainly keep my eye on topics relating to information design (eg. information architecture, usability). I'm really enjoying reading Dan Hill's City Of Sound blog - - he studied CS but is now involved in design.

Personally I see a lot of similarities between programming and design and it's interesting to discover related perspectives and ideas.

Walter Rumsby
Thursday, December 19, 2002

I get to do some of this on a good day when nobody is screaming for me to fix a lot of cruddy old legacy systems.

My experience is with admin and ERP systems.

My thoughts about how to go about this continue to evolve.

Currently I'm struck by the extent to which so many developers are tempted to do what is easy for them rather than what serves the user best.

The user isn't there to become an expert user of our systems. The user has a job to do which already occupies their capacity to learn, discriminate, and act.

A good interaction will be as nearly as possible invisible to them. They shouldn't have to think about it when using it in the performance of their job.

They should never be forced to put in anything that they or their colleagues won't want to get out again in some form.

A technically wonderful feature-packed tool can be unproductive in the hands of the average user simply because it takes all their mental energy to manipulate the tool when that energy should be devoted to the product they are trying to make with the tool.

Of course, training is part of this too. There I feel that the users should learn about how the tool helps them do their job along with learning about what the tool's capabilities are. (This should be a feedback loop, 'cos the users will often show you better ways in which it can help them.)

A lot of this comes down to common dialogues and retrieval facilities. People using admin systems are continually having to pick up threads which have been idle for some amount of time (waiting for returned calls, requested info etc.) They should be able to do this easily, of course; they should also be able to do it in such a way that it is easy to return to the context they were dragged away from by the phone, colleague, interruption. The system can mitigate the effects of context-switching.

So I say that we find out what makes users' work easier, then we get the system to do it. If that makes our lives as designers / developers harder, so what? Do we want to be bored with doing stuff anyone could do?

Party animal
Friday, December 20, 2002

*  Recent Topics

*  Fog Creek Home