How Does Usability Engineering Fit Into the Field of Software Engineering?

I just finished reading Usability Engineering Turns 10, a paper from 1996 by Keith Butler. One of the main questions that jumped out at me, as a computer scientist, what how usability engineering can fit into the larger field of software engineering. I suspect things have changed in thirteen years (for example, a company that I did some co-op placements with has changed from being run by the engineers in the nineties to being run by the business and marketing types today, and there are now entire teams of user design experts). Despite this, I have noticed a resistance from some students to even consider making a basic user and task analysis course mandatory, even just for the most relevant streams in our computer science degree.

The usability engineering cycle outlined by Butler is fairly straightforward, and likely looks familiar to software engineers:

1. User and Task Analysis
   
2. Interface Design
3. Building (Iterative Prototyping)
   
4. Usability Evaluation

The design of interfaces wasn't always so focused on the user. This way of thinking seems to have started in the 1940's during the Second World War. The machinery and instrumentation in air planes was beginning to get too complicated for humans to safely operate. Air crews needed protection from extreme environmental conditions as well as operational safety. This lead to a book by Ross McFarland in 1946 called Human Factors in Air Transport Design. The 1960's brought Human Engineering Guide to Equipment Design by Harold Van Cott and Robert Kinkade, which considered the user to be an integral part of the system, the same as the machine parts.

Some interesting key points from the article:

• The abstract objective of usability engineering is the minimization of cognitive and perceptual overhead required from the user.
  
  
• Intuitive interfaces are the result of designers connecting the layers between the mapping of a user's conceptual model to the functions of the system, the user determining the exact commands and arguments needed to control various functions, and the user's physical execution of the commands.
  
  
• User and task analysis has two objectives: first, to understand the situation as it is, and second, to improve it.
  
  
• Analogies help users connect the software with their mental model of the world. If an analogy is not defined in the software, the user will invent one.
  
  
• The default practice is often assigning only as many functions to the computer as budget and time will allow, but it's better to understand what the computer do better and what humans do better and assign functions accordingly.
  
  
• When designing layouts and operation of screens in software, the low level details can be worked out using UI standards. Higher level details, on the other hand, are driven by analogy and mental models.

Back to the students who vehemently oppose having any courses that cover this kind of material in a Bachelor of Computer Science. They argue that this isn't computer science and shouldn't be forced upon us. They say that they will never have to be the designer, so why should they have to learn about design?

First of all, a lot of what we learn in computer science could arguably be deemed "not computer science" if one wanted to be particularly pedantic. After all, software engineering isn't about algorithms or system design; it's about engineering processes. Yet software engineering is a course we all have to take it. Wouldn't at least being aware of how the designers came up with their decisions help us develop their vision more accurately?

According to our undergraduate calendar, students in the software engineering stream have to take a quality assurance course. Again, this could argued as something a little less computer science and a little more engineering. If those students learn about what happens during and after development, shouldn't they have the complete picture by learning what comes before?

Here's another good point that Butler makes:

Application development projects, however, must already deal with function, costs, schedule, GUIs, data management, communications, software architecture, methods, tools, standards. Unless part of a comprehensive, integrated approach to application development, usability can easily end up being just one more tail trying to wag the dog.

So in addition to simply having a big-picture understanding of the entire software development process, we have to be careful that the usability design phase doesn't get shoved aside partially due to the attitudes of those on the development side of things. Unless, of course, you think that us programmers can design a perfect product on our own. (Yeah, right.)

Butler sums it up perfectly:

Cultural obstacles in the computing community must be overcome in adding a user-centered perspective to the existing technology-centered focus.

Once again, though I think things have improved, there's still work to do, evidenced by my school colleagues. Here's hoping that one day an introduction to user and task analysis will be on the curriculum of anyone taking a software engineering class.