Originally published: Jun 01, 2001                                    Articles Archives

How many times have you heard someone say, “GUI guidelines are mostly common sense”? If that’s the case, then why do we struggle with designing usable systems so much?

Many people equate user interface guidelines with look & feel (L&F); they assume that this must be what usability is all about. Unfortunately, they’re wrong. L&F is less than half of the usability equation — at best, with simple business systems, say 40%. The functionality and the behavior of a system have a far greater impact on usability. System behavior, a major part of the other 60%, can be quite elusive.

How then do we capture the essence of usability and transform it into something that we can see, understand, and apply consistently? Perhaps some clues can be gathered from the past. Let’s look at how we, as systems developers, have produced applications over the last several decades. In the early days, we built databases — static storage tanks designed the way that we declared our data should be stored. Then we programmed some logic — conditional code created to get the data in and out of storage. For quite a few years, we did ‘data processing’. What on earth does that have to do with usability? Not much.

With the arrival of the Windows and client/server era, we continued to build databases the way we figured the data should be stored. And, we created more code to process that data. This time around, we added a whole bunch of cool user interface controls like spreadsheets, tabs, buttons, and boxes of all shapes and sizes. At first, we obsessed about Windows L&F, saying that it would revolutionize usability. And yet, after a short honeymoon, we realized that a dog in tux is still a dog. When it came to actually building the system, Rapid Application Development (RAD) gave us more than one kick at the can, and by trial and error, we made some headway with producing more usable systems.

Now, with the web being the preferred medium, we’ve ditched Windows and rediscovered the page paradigm. The databases are still there; if we need some more, it is relatively cheap to tack on another one. We keep on clinging to that code, which by now looks more like a pile of band-aids on a wounded duck, than a business rule. Most of the Windows stuff has turned out to be a write-off, because in our rush to crank out fat feature laden clients, we didn’t get a chance to separate presentation from logic and description from behavior, leaving us with no easy way to peel the user interface off of our Windows and transfer it onto our web pages.

The Object Oriented Application Development (OOAD) gang keeps tooting their horn, saying that objects will give us the behavior we need to improve usability — and they are right! However, the percentage of developers that seem to really know how to apply this sophisticated OO stuff is still pretty small, and, regardless, OOAD does not teach us how to design the user interface itself.

And so, as we tinker with portals and various web solutions, we find that the past simply tells us that we’ve overlooked usability and don’t really know how to translate functional requirements into well-designed user interfaces. What is a designer to do?

With usability surfacing as a major issue associated with enterprise application integration (EAI) and the like, the time is right to adopt improved methods of communicating functionality. The real world is messy and complicated. There is more order in chaos and entropy than can be found in any of our feeble attempts to organize reality. That said, in our next article, we’ll shed some light on the process of developing usable systems. Specifically, we’ll explore various techniques for modeling the behavior and functionality of the user interface.