“People need to demand that design performs for them, and is special in their lives, these objects that they buy. You can’t make your GPS thing work in your car? There should be like a riot because they’re so poorly designed. instead, the person sits there and things ‘Oh, I’m not very smart, I can’t make this GPS thing work.’. I can’t make these things work! This is my field and I can’t make them work!”
I completely agree with this, and see it most often (naturally) in web/UI design. The problem is, in my experience, most designers neither have the capability nor desire to design for users who are less technologically savvy than they are; they simply can’t understand why a typical user wouldn’t know that to get the site to do what they want, the user needs to go through a series of byzantine steps, which are known and understood only by the coder.
This is at its most pronounced on sites where the coder is also the “designer.” That is, the person who is working on the guts of a site/UI is also the one responsible for the front-end look of the site/UI. I firmly believe that this is why many sites fail. Think about it (and I know I’m generalizing, but my beliefs are rooted on empirical experience): Most of these coders aren’t the typical customers for the sites they are charged with building.
To illustrate this, it’s easier to look the other way: when the coder is the customer. When the coder is the intended customer, it works perfectly. This alignment is best exemplified by the look and feel of version one of del.icio.us. From the funky url on down, del.icio.us (at least, pre-Yahoo acquisition, when it was completely in the hands of its original creator) was clearly made by and for coders. I spent many hours attempting to explain the merits of del.icio.us to non-coders. Typically this was a very frustrating experience. Of course, while I was busy fruitlessly explaining, the wise people at StumbleUpon basically created an easier-to-use del.icio.us – a del.icio.us for the non-coder. Of course, some of the features that made del.icio.us so compelling didn’t cross the chasm onto StumbleUpon, but most users didn’t care (they didn’t miss them, because they didn’t know what they were missing).
Another example of coder as customer is my favorite app of all time, Quicksilver. I have spent unknown hours trying to explain the virtues of QS. I feel these efforts have been largely wasted. For most people, the process of setting up QS is just not worth their time. The process is not intuitive, the documentation stinks, and after a few attempts, people just toss up their hands. This likely explains why, after several years, the creator of QS has abandoned the project, and turned it over to the open source community. In so doing, he is tacitly saying, “QS is really only going to ever be embraced by coders, so let them design it for themselves, without worrying about making it usable for non-coders.” Non-coders can use LaunchBar. And, much in the same way that StumbleUpon is a more user-friendly, but less feature-rich version of the first iteration of del.icio.us, LaunchBar is a more user-friendly, but less feature-rich version of QS.
So…the disconnect occurs when you have a coder (either by default or by choice) working as a designer on a project where the customers are not coders. It takes herculean management discipline to deal with this. Most managers are at least cognizant of their customers’ wants, and also tend not to be coders. One would think, therefore, that the managers would be able to guide the coders to create for the customers. Wrong. In the actual hierarchy of things (as coders know…they’re smart…that’s why their coders), the coders trump the managers. Let me be more blunt: the coders have the managers by the balls. The manager can try to articulate to the coder what the customers want, but if the coder doesn’t get this/agree with this or simply can’t accomplish this, the end product is going to be designed not for the customer/manager, but for the coder.
The manager will then be faced with either trying to get the coder to changer her work to get closer to what the manager perceives the customer wants, or firing the coder and starting from scratch. Both options suck. Trying to get the coder to improve upon what they have built axiomatically leads to diminishing returns. The coder believes that what he has already created is perfect. He will make changes only reluctantly and half-heartedly. The manager eventually settles for something less than what they believe/know the customer wants, and the product fails. Firing the coder and starting over is typically an equally frustrating experience, and it adds cost and time to the equation, and…of course…you typically end up with a less than optimal product anyway, and thus have to go through the “improvement” stage.
So, what’s the answer? I frankly don’t know. The problem is so pronounced, and so deeply ingrained at this point that there is no easy answer. Certainly setting clear expectations, articulating, and trying to find a common language between manager and coder is the key, but that’s far easier said than done. The reality is that most manager/coder dynamics lack not only a common language, but also a common process. They’re two different animals. This is why there is the tension and the less-than-optimal products out there. Over time, of course, managers can sometimes make the continual improvements with the coder, and give the customers what they want (Apple is an example), but often it’s too late. This is also why, when you have that rare combination of manager/coder (and they’re as rare as the albino tiger) you end up with amazing products; eBay is the classic example.
I truly see this as the largest problem facing most entrepreneurs/start ups today. Most entrepreneurs have no idea what they’re getting into when it comes to web dev/UI. They think that they can just hire someone to build them a site. A year or so later, they have spent most of their money, pulled out most of their hair, and — if they have a site at all — it’s sub-optimal.
As the quote from David Kelley explains, these sub-optimal designs end up causing the customer to feel that they’re not smart enough to use the product, and they thus abandon it.
This issue truly is the entrepreneurial challenge.