Wednesday, October 14, 2009

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.


Matt Villeneuve said...

Wow, Gail, I could not agree with you more! Being a full time QA with no programming background, I see daily the results of programming created without the end user in mind. Things have improved greatly as our User Experience team gets more involved, but a little thought and a little effort on the part of the developers to think about how the code will be used and more importantly by WHOM would solve a lot of the usability issues I raise as bugs.

lwaldal said...

stop asking engineers to design (or letting them design) user interfaces if they don't have experience in usability engineering and have usability engineers and developers work together concurrently instead of, as in most development processes, consecutively. if usability engineering isn't a part of a developer's talents/interets/expertise, then ... Read Moredevelopers shouldn't be dabbling in it -- too often they do with disastrous results for the end user of a product (this is particularly true for web and other software apps)

my company is often hired to settle a dispute between marketing and engineering who are arguing about what is more usable by their user/customer -- it's tiring. if they worked together from the start they wouldn't be fighting over "what's best for the user" just before launching their product.

Oliver said...

(@Greg, dup'd from FB)
I agree in general. Functionality comes first, otherwise someone else will just make a faster version of your easy-to-learn software which enables better metrics in the long run. However the example is flawed.

Usability is largely about the I/O of a system, because that's how we interact. As painfully obvious as that is, it highlights ... Read Moresomething -- I/O. The shiny GUI with fancy displays is merely 1/2 the equation. While better for presenting information over flat monochromatic text displays, what often gets forgotten in a GUI is shortcuts (that same time-saving aspect that we like about the old-style UI). I'm as big an advocate for shortcuts as anyone. I hate using the mouse for so many of the navigation-oriented activities because it's such a distraction to move your hands off the keyboard to grab the mouse when you only need the cursor to select something that's only a few keystrokes away. If the hospital GUI in your example implemented function keys the same way as the old-style UI, then you'd have the best of both worlds. The newbie can learn the ins and outs of the app easily, and as they get more familiar with the built-ins on each screen, they adjust to using shortcuts so save time. Note that this isn't to say the mouse is useless. It just has areas like working with graphics where it actually performs better. (Could you imagine having to do photoshop using only a keyboard?)

Gail Carmichael said...

Matt: It's interesting that the devs end up doing as many UI decisions as you're suggesting, since your company has such a strong user experience team.

Leanne: I agree that developers shouldn't be asked to do design. In fact, my insistence that we learn about it isn't even because I think we should do it ourselves in industry - rather, I think it's important to understand where the requirements etc that we receive come from. In terms of working concurrently, I think that perhaps there should be some of that (which could support iteration and all that), but the analysis of users and such really needs to happen before there is coding. Working out the most major issues before a lot of code is written seems to save money in the long wrong.

Oliver: Too bad we didn't get Greg's comment up here so that yours ended up orphaned! But basically we're talking about efficiency vs. usability. Thing is, efficiency can equal usability - it all just depends on the end goal. Some analysis tools (like the GOMS model) are specifically designed to consider efficiency. Sometimes learnability of a system is more important. This is one of the reasons that user analysis is so important - you have to know who you are building the system for!

Gail Carmichael said...

Oopsies, "seems to save money in the long wrong" should obviously read "seems to save money in the long run."

Alex said...

While I don't have any formal training in human-computer interfaces, it is a pet interest of mine, and I've done a lot of reading on the subject. I therefore feel compelled to chip in my two cents.

Regarding the original question (Should usability be taught in CS?, and tangentially @Matt, lwaldal):

I don't think there's any sense in teaching human-computer interaction and usability design to most CS (or most other S/W dev) majors for the purposes of making them better at designing user interfaces; the field is much too complex to be able to "tack on" enough information to be useful.

That said, a course (or even just a month-long unit in another course) would probably be invaluable, not because the students would learn how to do UI design, but because they might learn that they can't.

Too many software devs believe that because they use computer UIs all day, they are qualified to design UIs. This is all the more common because HCI considerations are often subtle and non-obvious.[1]

Anything that can be done to disabuse new developers of the notion that they can design user interfaces without any specialized knowledge/training is a good idea.

[1]Favourite demonstration/example: "Pop quiz: What five points on the screen can the user access the most quickly with the mouse?"
Answer, and further discussion here:

Post a Comment

Comments are moderated - please be patient while I approve yours.