Well, usability engineering is a bit of a nuisance to discuss, and it’s not because this topic is a bad one or anything like that. The problem is that, as with many terms I’ve discussed in the past, it can mean entirely too many things, and I hate when that happens.
Generality:
I hate discussing generalities like usability engineering, because there are so many ways this can go, and so many different contextual specific meanings to what it entails that I spend half the time trying to be informative and very general simultaneously. That’s not easy and it’s often not very constructive.
Resolution:
I’m going to look at this in the context of software design with usability concerns as a prime goal of the design. This still doesn’t help much, and there’s only so much I can say, though.
Platforms:
The first thing that is considered (nowadays) are the platforms one wishes to target. This is entirely before you really get a definition of the software itself. You’ve looked at the usability problems inherent to each of them (mobile has a ton), and you see a new way to design this kind of software to be easy and comfortable to use.
In cases like this, it’s rarely a new kind of software, so much as a new design of an existing kind of design that’s as I said, easier to use for the most part.
Spotting the Problem:
The standard problems of the platform and the conventional software designs for the niche in tandem with these is then evaluated, and a model that works around this is proposed. At this point, hefty development of the underlying software begins, while the designers work out the GUI to accommodate the new kind of interaction they want to try.
Testing:
At this point, the proposed ideas are implemented and attached to the prototype engine driving the software. This is often fairly quickly done given most IDEs possess a visual GUI editor which the designers can use, and then the coders can tie in.
Testing begins, first inside the company, and then with focus groups and other outside sources, with a ton of different analysis models. I’m not getting into those here, because I’ve talked them into the ground already.
Refinement:
At this stage, refinement to accommodate what does or doesn’t work by way of the tests produces a release candidate of the concept. At this point, you then have another long period of testing, to make sure the “intended for users” incarnation of the design concept actually works as well as is presumed.
This needs to take triple the time that the first wave of usability testing takes place.
Finally:
One last phase of picking through the user interactivity aspects of the design is necessary, to make sure that inconveniences (such as misuse of infinite scrolling or overblown custom controls) which aren’t immediately visible are actually not going to show up later.
Now, you probably expected some long technical walkthrough of usability engineering, based around picking the right mixes of things to accomplish this or that. The problem with that would be, it’d be dated immediately.
