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.