I haven't actually counted, but my guess is that about eight out of every ten websites I visit (and yes, I'm radically revising my own for August) are user unfriendly.
Quite aside from the arrogance (or ignorance) of people who rely on things like Frontpage to exclude non Windows users from their sites, every conceivable interface error can be demonstrated simply by typing some randomly chosen words into google and reviewing the first few sites found. In fact, there's a whole genre of completely unusable websites out there you can find with almost any google search - the accumulators or indexers who buy pop-up ads but whose websites are totally unusable garbage collections.
The reason, I think, is generically that the tools determine the outcome - but bear in mind that choosing the right tools is part of the designer's responsibility and that designers are tools from upper management's perspective. In other words getting it right means getting the right skills focused on the problem and leaving both tool and implementation decisions to the people you've put in place to get the job done.
Look at the issue from the perspective of choosing between programming approaches and what you see is a paradigm clash. On the majority side we have the Wintel focus on small screens, user interaction at each step, and the use of user set preferences to deliver the feeling of customizability. On the Unix/Smart display side we have large screens, lots of interface automation, and the use of environment variables to deliver customizability.
The real difference here is between interface design and user interaction design, but the simplest way to get your head around the functional difference from a programmer perspective is to think about testing. Preferences are combinatorial: in Windows an application might have 60 pop-ups, and 20 application wide preference settings each with an average of four settings - i.e. about 58,140 potential interface configurations for each operation.
In the smart display world you might have 60 functions accessed from eight to ten screens and controlled by 20 environment variables, each with a virtually infinite number of possible values. In this case, however, the testing burden grows linearly because defaults are automatically substituted for missing or out of range values, the usage mechanisms can be tested on a stand-alone basis and the database linkages either work, or don't work.
With preferences the primary concern tends to be about how it looks, and how it looks can affect whether it works. With user specific external variables, however, we're primarily concerned with how it works, because if it works at all, it will reliably work for all.
With that in mind I'd like to point you at a fascinating interview between Alan Cooper (goal-directed interaction design) and David Anderson (agile software).
Consider this bit from the opening discussion of programmer motivation:
DJA. So it's not enough for a designer to turn around to a programmer and say "It's cool!"AC. Right! Cool is not a good design reason.
If you have a good design rationale, if you know that people are going to be searching for information in this place and this is an appropriate way to present choices to them and all other things being equal then presenting it in a cool way - I'm all for it - but there are all sorts of cool things which are cool the first time but the 10th time you use them, you hate them. So what you have to do is to say, "Who is going to use it?", "Is this going to be used by somebody once?" You can do cool stuff in a kiosk that someone is going to walk up to once and use just that once. That's OK.
If someone is going to sit down in front of it and use it 10 times per day for the next 3 years then you have got to get that "cool stuff" out of there because it's just going to get in the way.
We believe that good design is self-evident.
So that you can look at it and say, "Yeah. That is superior"
If you as a developer do not see that it's superior then you are probably not going to build it. Regardless of what rationale or what orders you are given from management.
And a bit later on, as the conversation moves toward what it becomes, a discussion about the difference between interface design (i.e. preferences) and interaction design (i.e. real user specific customisation), we get this:
I wondered if you followed the debate about the development of the Swing Look and Feel ?AC. I confess that I didn't follow it.
DJA. To give you some background, the Organic L&F tried to follow advice from Don Norman and Edward Tufte. It was a very flat and clean looking design. No 3D. Minimal on screen clutter. The approach was arguably the better and more promising design but it was too radical. What Sun ended up with was Metal, which was kind of a compromise Windows look with Sun Corporate colors.
AC. I don't consider that Interaction Design. Look and Feel stuff is Interface Design. It's all very stylistic. It's the color that you paint your walls. Interaction Design is about the Architecture. It's what kind of building are we building. What functions does it support. What are the shapes of the rooms and the walls and ceilings. What is the infrastructure. What kind of elevators. What kind of cooling and heating. That's Interaction Design.
Jerry Weinberg wrote about this a long time ago in "The Psychology of Computer Programming". What language is best? The language that you like best! So what's the best indentation method? The indentation method that you like best. And what's the best L&F? The L&F that you like best.
This just doesn't address the significant issue, which is Interaction Design! What does it [ the system ] do? How does it communicate? How does it behave? These are the fundamental issues.
Let's look at database queries. You issue a query to a database. It hands you back a solution set. This is a technology that's known. What we do is that we debate about how to have little dialog boxes to submit queries and display solution sets. That is interface design!
People generally don't ask fundamental questions like "In a situation, where I have a particular User, who is trying to accomplish a task, who is trying to achieve a goal, what are the appropriate methods of information retrieval for that person?" Would it be a query and solution set as the way to solve the problem. That is an Interaction Design question. It's one that is not often asked. But is the type of question that we ask here [at Cooper Interaction Design]. It's a very very different approach than asking "What should the dialog box look like".
I thought there was a certain amount of publicity management and image making going on in this interview, but it's like one of those conference calls where the PR people instruct the executives in what to say, but some truth slips out anyway - and where it does in this interview the insights are often thought provoking and well worth reading - especially in the context of this week's discussion on database based applications development.