Another possible title for this thread could have been “The mystery of missing ergonomics specialist”.
ergonomics
Function: noun plural but singular or plural in construction
Etymology: erg- + -nomics (as in economics)
: an applied science concerned with designing and arranging things people use so that the people and things interact most efficiently and safely -- called also human engineering
(Merriam-Webster Online Dictionary)
The problem.
Every time I pay a visit to a software house I have a simple question: “Who takes care of the ergonomics of your products?”.
Unless I am are guest of a major producer of packages this, only apparently simple, question has no answer and in most of the situation for the person in front of me the idea of ergonomics is connected with tables and chairs design only.
Human-machine interaction design is a complex and difficult science well known and widely applied in the production of different products. When you change your car to a newer model you feel a lot of work has been done in the direction of easy and safe use of al the controls and going back to an old car, even a beautiful one, gives you the tangible feeling of interfaces evolution.
If we have a look to most of the software used in banks, insurances and telco companies the same evolution in interaction is not so evident. The software is more powerful, more integrated, more complete, but in the vast majority of cases the interface is poor and the paradigm applied is not much different from the old IBM 3270 terminal one.
Is not unusual to see employees getting into a screen to take note of some data on a post-it, then go to another screen and retype the same data: a sign of very poor interaction design.
The reasons for this poor design becomes very clear if you ask “Who has the responsibility of the design of program interfaces?”.
In most of the cases you find that the design of human-machine interaction is not at all a clearly defined responsibility. The functional analyst decides what to put on the screen and how to connect fields to databases and to computational modules and the programmer itself splits the fields in different screens.
At the end the interfaces does not map the cognitive processes taking place in the brain of the users, but becomes a map of the internal design of the code and the various technical constrains.
At the beginning of software history the technological constrains where extremely strong and was, in many cases, impossible to avoid the bad practice of mapping the interaction around them. That time putting two field in the same screen “because they are in the same file” was acceptable, today in not!
Now all has changed and in most of the cases could be relatively easy work around technical constrains in order to get a better interface, but if you do not have a formally defined interaction responsibility nobody really knows the best interaction solution!
Is a typical case where the problem solving phase comes after a very poor or inexistent problem setting phase…
The solution.
For years we have been calling center the computer and periphery the man. This use comes from the old days of huge computer in the “glass house”, but if you well think about is quite misleading.
The center of the problems, or should say of the opportunities, is in the brains of the human beings interacting with the system.
The starting point of the design process should be a good understanding of the cognitive processes. These processes are the result of a long evolution: they should be considered the unmovable constrains.
Short term memory (the RAM we use to identify the environment we are into) , e.g., is a limited resource: the medium value for an average population, not under stress conditions, is 7 with a span of plus or minus 2.
If you set up a menu list larger then the short term memory of your user the choice will be more difficult, will take more time and the probability of error will increase.
Waiting some thousand years to see if the evolution improves human’s short term memory storage or hiring chess champions only could be e solution. Most probably consider this constrain not removable and design your menus in consequence is THE solution.
In the software development process we should identify a unit of experts and give them the responsibility of human-machine interaction: this is the usability team. They must be expert in this specific field with a good knowledge of mental processes. Better if they are NOT expert in the specific field our software is applied to and in software development.
After the definition of WHAT the system will do this group will work on HOW should be done. The result of this two phases is the starting point for architecture and software design and development in a cyclic trial and error process known as protocycling.
No modification of the human-machine interface should take place for any reason without the formal agreement of the usability function.
Roberto Dadda
