Iterative Design By Flaw Eradication: Good design benefits from the identification of problems, even when the identifier proposes no solution.

From the book The Evolution of Useful Things by Henry Petroski, I thought I'd pass along the following wisdom. As background, Petroski is analyzing the process by which simple objects (e.g. the fork) gain their form, strongly declaring that the alliterative aphorism "form follows function" is bunk, that instead the evolution of tools is an iterative process which is rarely ever complete. Analyzing the words of architect Christopher Alexander, Petroski writes:

'Misfit provides an incentive to change; good fit provides none,' declares Alexander, and even if we ourselves do not have the material, tools, or ability to work up a new artifact to remove an irritant in one we use, we might at least call the irritant to the attention of someone who can. That someone who can effect changes can be a craftsperson, for whom Alexander uses the masculine to include the feminine, and whom he describes as 'an agent simply' through whom artifacts can evolve in an almost organic way:

'Even the most aimless changes will eventually lead to well-fitting forms, because of the tendency to equilibrium inherent in the organization of the process. All the agent need do is recognize failures when they occur, and to react to them. And this even the simplest man can do. For although only few men have sufficient integrative ability to invent form of any clarity, we are all able to criticize existing forms. It is especially important to understand that the agent in such a process needs no creative strength. He does not need to be able to impove the form, only to make some sort of change when he notices a failure. The changes may not be always for the better; but it is not necessary that they should be, since the operation of the process allows only the improvements to persist.'

Sage words, indeed. (The bolded emphasis is mine.)
The two truths which this made clear to me, as they apply to the design process in general (be it forks or user interfaces or coding) are:

1. Creative-impaired idiots can always improve the design through accurate criticism. As a craftsperson who believes that he can create solutions 'with clarity', I have found myself resenting and discounting the opinions of those who criticize without offering solutions. However, when creating a solution I realize that I must keep in mind:
   
   1. that though it was the best design at the time, it's not going to be perfect [certainly not in a true sense of the word, for desirable qualities like instant download time will always need to be traded for other desires such as graphical richness], and
   2. that all criticism if it accurately points out a flaw truly is beneficial to the design (no matter how frustrated I may be in trying to fix the flaw).

   Further, when critiquing someone else's solution, sitting at the other end of the fence, it's important to know that, while helpful, it's not necessary to attach to each criticism a proposed solution.

   This concept is what enables usability groups to be so useful--discovering that it's broken is as important as figuring out how to fix it. [Moreso, in fact, since without that knowledge, why would you fix it?]

2. In creative designs for web sites, historically I have believed that, after a client review and the ensuing design changes, the client should be focusing only on one of the newly-created designs. As the good Mr. Alexander points out, the new solutions don't necessarily have to be good ones to succeed in the end. If all the good aspects are kept intact, and only the flaws replaced with new attempts, then even random attempts to fix the flaws would produce a solution no worse than the previous iteration. However, given the multitude of goals and tradeoffs present in web design, an attempt to fix one flaw will most likely affect previously-acceptable attributes of the site, and hence the overall design could end up worse.

   As an example, suppose a nav bar has a font (Times New Roman) which the client complains is too small to comfortably read. To fix this, I change the font to a more legible one (Verdana) and increase the font size slightly. What the client didn't say [and perhaps did not even realize] was that the ratio of the nav text size to the size of the text for the rest of the site was good. That the amount of horizontal space that it took up was good. That the amount of vertical space which it took up was good. In fixing the problem of sub-optimal legibility, I've thrown off a bunch of other factors. I fixed what the client asked for, but at the expense of other acceptable elements.

   Given that an attempt to implement a client's stated desire may in turn destroy other, unnoted-but-loved aspects of a site, pressure should never be put on clients to say "You asked for this change, you better choose one of these solutions."

In short:

1. Even dumb people can give you fantastic input.
2. Fixing what you set out to fix doesn't necessarily mean you did well.
   (At least not in web site design.)