The usability engineering cycle outlined by Butler is fairly straightforward, and likely looks familiar to software engineers:
- User and Task Analysis
- Interface Design
- Building (Iterative Prototyping)
- Usability Evaluation
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.
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.