Common errors in the brain of a developer
The three mistakes made most often are:
The first one is rather obvious. Those that don’t understand this, should recall the Days Of Horror. And they should be banned to Geo cities or any other long-dead web-page community, to play with snowflakes and overly C3wl mouse-cursor-banners.
TV, obviously. Another fine example is how the arrogance of designers (Sure I know better how some field should look, then interface developers from large multinationals found after over 10 years of research).
The third one, however, is the worst, because it happens all over the place. It makes us, developers, lazy. We finally found a closet to hide all our crappy interfaces, so that when mammy comes looking, the room looks clean. I have read and heard it many times in Drupal development “this form is really messy. Just put some collapsible fieldsets around the most messy parts and its solved.” No! its! not! solved! It is hidden. Tucked away.
Hiding a problem is not equal to solving it.
You did not improve usability, you merely hid your inability to think about good usability. In fact you are saying you are both incompetent (I don’t know how to solve basic usability questions) and unwilling to be honest about it (I’ll hide my mess so that no-one notices). It is not bad to not know how to solve usability. But then for somebodies sake, ask for help. Any proper software project, has usability baked into its very core workflow. There are hardly any proper software project. Usability is nearly never baked into the core.
The History Of The Teaser[tm]
A clear example: Drupal has known the History Of The Teaser. The concept of its teaser is not bad, its just clumsy and not very usable for many end-users and many cases. I cannot recall how often I had to explain over the phone “left pointy bracket. Exclamation mark. tow dashes the word break. No, not the break key, b, r, e, a, k. Yes with spaces” and so on. You’ll know it. Many attempts to solve this issue died because of just as many reasons (of which every single one could get a separate blog post, so I’ll leave it with just that). I, personally, don’t really care, because it takes only 15 lines of PHP to make it simple and usable for your specific end-users. And 15 other lines to make it usable for another case and project.
The Full Monty is about real usability
With the teaser, the real problem, is that many expect the body and teaser to be exclusive (again: the core of the issue is that this really depends on the case). What shows in the teaser, may not be part of the body.
Mr. Wolf, how do you solve a problem then?
So then, how do you improve usability? This, I cannot answer, I think no-one can. Its a complex, difficult trade. One that requires either intimate knowledge of the human psyche, or an Amazon account (so that you can read the many books by people who have that intimate knowledge). And worse: one that differs from case to case, site to site. So what may be true for your audience, is not for others. Usability for Linux users is completely different then usability for the operation of a television.
The most important rule is, however, to bake usability, as requirement, as feedback, as task, right into the workflow of every project and every planning you make. This is the only way that usability issues don’t pop up because of low level design flaws. It is also the only way to ensure your product will work (reasonably) well on release.