Sunday, July 24, 2005

Some Philosophy Behind Good UI Design

I've had a number of conversations about interface design recently in which it was suggested that excellent design doesn't really matter, and that as a designer I have some kind of extreme bias towards quality that amounted to, well, anal fluffiness. My friends seemed to be sold on the concept of usability, which is, after all, a wholesome sounding term (except in France where it doesn't exist), but the relationship of usability to good design was non-obvious to them. While avoiding a homework assignment, I dug up a few relevant pointers.

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%.
  • 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
What is being designed? Two languages and the dialogue that interlaces them: Users(s) - > computer-> user(s).

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.

5 comments:

  1. Anonymous2:21 PM

    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.

    ReplyDelete
  2. Hi 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?

    ReplyDelete
  3. Anonymous3:12 PM

    Many 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").

    ReplyDelete
  4. Anonymous3:14 PM

    Speaking of usability, those anonymous comments are both me. I just didn't notice I had an option other than "Blogger" and "Anonymous"...

    ReplyDelete
  5. I 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