“The interface IS the application”

“The interface is the application.” You hear that a lot when someone’s trying to remind you to consider the end-user’s perspective. It’s a good reminder, too — to the user, the inner workings of your application are probably about as interesting as the inner workings of a warehouse. N-tier? Components? Who cares? At the end of the day, if people don’t use your software, is it really any good?

It’s important, though, to remember how this statement is used: it’s a context-shifter, a facetious phrase intended to jar you into thinking — not a statement of fact. Accepting it as factual, and making decisions based on it, is like saying your skin is the entire organism, or that your car seat and dashboard are the whole car. I rarely think about the transmission (unless it’s not working), but that doesn’t mean that the radio moves the car.

Keeping to the vision

Maybe this echoes back to my days making music. I remember wondering whether a band needed to have a “leader,” a single member who wrote most of the words and music, and provided a psychological unity to the band. Gave it a personality.

I wonder whether software teams need the same thing. Typically, gathering software requirements is a bunch of people throwing details around. These people have different views of the system they’re designing, they understand the constraints on it differently, they have different goals and pressures on them. Seldom is there one person who makes all the decisions, and steers the overall project. Seldom is there any coherent vision of how things should work. Seldom is there any clarity. Is it any wonder that a lot of the software out there sucks?

Amazon.com is a good example of software with a cohesive usage paradigm. Users understand the entire process of buying things from Amazon. They understand shopping carts, check-out, addresses, coupons, and shipping. They understand how all these parts fit together. Granted, all of these concepts are carry-overs from real-world retail, so Amazon had it easy. In fact, anyone who builds software that models a real-world process has this part easy: email is so simple to use because it mirrors a real-world process.

However, this kind of clear understanding is lacking in many software systems. Making users understand the “components” of a software system (the shopping cart, the coupons, etc), and how they hang together to be useful, I think is the essence of usable software.

As I think more about this, I think that a lot of software models a real-world process, because a lot of software is about automating some real-world system. In these cases, maybe the trick is to recognize that you’re automating a real-world system.