Worse is better? When designing digital experiences, I followed the maxim "the customer experience is the most important determinant of website success." This is a sharp break from information architecture which has many rules like "navigation needs to be consistent," "don't risk the value of groupings," and "site hierarchy must be strictly maintained." Customer experience only focused on how well the customer could complete whichever task was most important to them. Inconsistent navigation, perverted groupings, subverted hierarchy were all fair game when a company wanted to maximize its business by creating the best online customer experience. Focusing on the customer experience was the most effective strategy a company could employee when thinking about its website.

Imagine my surprise when reading through this old piece on LISP where it compares the "right thing" philosophy to the "worse is better" philosophy of computer language design. The "right thing" philosophy, like information architecture, has several rules requiring "simplicity," "correctness," "consistency," and "completeness." The "worse is better" philosophy places simplicity as the top concern all other elements should be subverted to support. Sounds a little like customer experience to me.

UNIX and C, built on the "worse is better" philosophy are still going strong. Sites with a good customer experience are winning. LISP is moribund. Sites with bad customer experience (but excellent information architecture) are dying.

XML-RPC, a language I will write more on soon, takes this "worse is better" philosophy to create a simple way for systems to talk to one another.

In my experience, customers have overwhelmingly preferred simple sites that let them do what they wanted to do. By using customer behavior to control scope, the technology could be kept simple and slim. This kept build and maintainance costs low. Simple, customer behavior driven technology will be increasingly important as the world moves from PC-based to network-based work environments. This will require abandoning monolithic bloatware and learning to handle bits (digital information) they way UNIX coders do: simple programs piping ASCII to each other. Check back soon and I'll tell you about porting the UNIX design philosophy to the front end (and why GNOME and KDE are seriously misguided).
Link to this column.