Andries van Dam's overview lecture (pdf slides) provides a thorough introduction to the process and goals of interface design (although he uses many more linguistic metaphors than I would). He notes in the early motivation section:
In many modern programs, the user interface code constitutes the bulk of program, i.e., 70-80%.
What is being designed? Two languages and the dialogue that interlaces them: Users(s) - > computer-> user(s).
- For the most part, the user interface is the key to the success or failure of a program
- Creating a good UI is often harder than software engineering because UI design requires much more than software engineering skills
- Some people typically believe UI design is unimportant because they misunderstand the design process/methodology
- Nowadays, software companies can be very picky about choosing who designs their user interfaces because the user interface defines the product
He notes that the UI code usually accounts for most of the code in a modern application, and it's often hard to write and change. (As a corollary to this point, it's my belief that a corporate culture that considers UI engineering as a second class activity, or "not hard," will not be generally capable of getting consistent good results from their product interfaces.) Designing the dialogue between the system and the user requires a non-trivial understanding of many things, including: the widgets in the set of tools available, the features and tasks to support, the mental model of the user going in, how to reveal the model of the application for learnability, what standards exist and might bias your users to expect certain behaviors from your application, what counts as basic vs. advanced functionality (10% of the features are used 90% of the time), good visual layout to support discoverability and task structure, and so on.
Application design is not a static problem -- one screen at a time -- but a dynamic one, and hence van Dam's use of the conversation metaphor. What happens to the interface when your user clicks here; and more globally, how does the application surface the product features during use over time? Does it make sense to a user, or is it only sensible to the development team who structured their code a certain way and locked in a possibly non-intuitive task flow that is now reflected in the interface? The interface, after all, is not icing after the architecture work, but a fundamental part of the entire problem you're solving with your application design.
Seth Nickell at Red Hat summarizes absolutely bang-on the difference I see between designing via lots of usability testing (a parody of the non-design approach to getting usability "into the cycle" a la Microsoft, until recently) and having a designer involved in the process. One of the well-known issues with usability testing is that it finds local problems, but can't itself help you understand the global causes and solutions to those problems. Seth's points are: A good designer will get you much farther than a bad design that's gone through lots of testing and Usability testing is not the best technique for figuring out the big picture and Usability tests can't, in general, be used to find out 'which interface is better.'
During testing, a user may muddle through even a poor design, and with qualitative testing it's tough to say "that's it, it's not good enough" -- there is always a tendency against change, for efficiency reasons, in any software organization.
I'll keep looking for more inspirational pointers, as this is a subject I care deeply about.