GUI Bloopers: Don'ts and Do's for Software Developers and Web Designers

As a user interface consultant, I am often called in by companies to review, critique, and redesign a product's shoddy user interface shortly before the product is to be released into the marketplace. In this role, I often feel like a participant in a dysfunctional relationship with a self-destructive person. I do my best to smooth over the problem of the moment the client's flawed product but have no mandate or resources to address the flawed processes and attitudes that produced it. I find this unsatisfactory for two reasons.

First, "smoothing over" is a good way to describe what can be done late in development: improvements are limited to superficial changes. Deeper improvements are ruled out because of insufficient time or because the organization is incapable of making them. A colleague called these last-minute attempts to rescue a bad user interface "putting lipstick on a bulldog."
Second, my limited role makes it difficult to leave my clients better off than they were when I started. Clients hire me to solve an immediate problem: identify their product's usability flaws and indicate how to fix them quickly and cheaply. They do not hire me to advise them on how to correct the more fundamental problem: the development processes, management practices and structure, or company culture that allowed a product to be developed with so many usability "howlers" or even worse, that doesn't match any customer need in the first place. I find that the more clients I "help," the greater my concern grows that I'm...