For example, an auto maker can’t make cars for the entire population (ie. real short people, real tall people or real heavy people)

Airline seats, walkways, parking spots.

You build for the masses knowing some won’t benefit.

For example when building a website and not considering IE6.

That philosophy has a name, anyone know it?

Thx.

Webhead

He argues that ease of use and capability are the true goals, not to be confused with “simplicity” and “features.” It’s true that simplicity implies ease of use, but ease of use does not necessarily imply simplicity. (And similarly for features and capability.)

So simplicity and features are false idols, over-simplifications of deeper issues, like ease of use and capability. There is furthermore a tension between desirability (which is driven by features) and usability (which is threatened by feature creep). At purchase time users are motivated by desirability, whereas at the time of use they are motivated by usability.

So the designer’s job is to manage these tradeoffs and find balance points.

I can’t rewrite a company’s business plan for them, nor is it my role. The best I can do is make sure that the features that they do have are easy to use.

My criticism of usability advice is that it pretends that we’re all working at Apple or 37Signals.
The rest of the world, the companies who don’t — or can’t — adhere to “less is more” are the ones who need usability advice the most, but are often dismissed as dinosaurs from a bygone era who simply haven’t seen the light yet.

There are always things that are absolutely needed, things that should be built and a list of things that are simply “nice to haves”. By implementing the must haves and the should haves first, you are simplifying the system for you client and yourself. The nice to haves may never be implemented. But this all takes very careful client management in terms of expectations and prioritization.

As for the user interface, there are certain conventions out there that are followed, not necessarily because someone took a chance and found something that worked better, but because those things have been tested over the last several years and proven to work the best. This is not say that there are not areas for innovation, but do not confuse something that is new and novel with something that works.

However, as developers and UX people, it is our job to take what the client wants and give it back to them in a format that is usable for them. This means that you test your ideas with your users and have them tell you what the best implementation is.

In all, you are confusing software built for clients with software built for customers. For the later, the developers have the ability to innovate and try new things. However, the former requires a lot more discipline and, ultimately, needs to be created to meet the needs of the user. This means figuring out the conventions that work for the user involved (both computer related and otherwise).

I guess the problem is when this philosophy is used as a way to avoid dealing with hard problems like managing complexity. Usability should also be about making complex apps work, and not just simplifying them.