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.
I've had similar conversations with other software developers both about attempting to make usable UI (usally when "good" UI is in conflict with "easy to implement" UI) and general software quality.
ReplyDeleteHi again Anonymous -- I'm also hitting myself for leaving out the most crucial and important point (I'll focus on it next time): if your UI sucks enough, the features you want on your product page and that motivated your app in the first place are basically not there -- for the user. Why risk failure (and/or huge support costs) after spending so much time building up that featureset?
ReplyDeleteMany people on projects are not evaluated on how good the resulting product is. It's frequently more about: Did it ship on time? Within budget? Did the project meet all the defined objectives (which rarely include "product is good").
ReplyDeleteSpeaking of usability, those anonymous comments are both me. I just didn't notice I had an option other than "Blogger" and "Anonymous"...
ReplyDeleteI wondered if it was you. You can also just sign it (--Ken) when you post so you don't have to do anything special. But yeah, blogger has some issues. I note they're hiring :-)
ReplyDelete