Jakob Nielsen, the man I love to tweak (I mean, just try and use his website to find something useful and you’ll see what I mean; the site’s organization resembles nothing so much as a herd of cats) almost gets it right with his latest. The misuse of radio buttons and check boxes has always been one of my pet peeves as well. But he does overlook something important in his rush to accuse yet another designer of incompetence.

His example deals with the text on a registration page. The site in question offers what are clearly two mutually exclusive options: Send me email about other offerings, or , Don ‘t send me any email. The site in question offers these two choices on its user registration page, and uses checkboxes for each of the choices.

Nielsen’s point is that since the options are mutually exclusive, the proper user interface widgets to use are radio buttons, rather than checkboxes. Which, strictly speaking, is correct.

But there’s another issue playing here. The web is a two-way street. Web site visitors aren’t the only people with goals to satisfy. Not only are there reasons for users to visit a web site, there are reasons for the site builder to create the web site in the first place. The user’s goals need to be met, true, but so do the site owner’s goals. Web sites should not be considered as a Win/Lose proposition for either party; as in all sensible transactions, the goal should be Win/Win.

And it’s in the site owners goals where you may find a reason for this design choice. Nielsen doesn’t give the URL he found his particular example on, so I can’t discover if the design choice was intentional or not, but I want to take a minute to talk about a reason to make this design choice intentionally.

The use of checkboxes here makes it possible for the user to select mutually exclusive options by mistake. And, presented with mutually exclusive options, the site owner would then “guess” which of the two mutually exclusive options the user actually meant to click — naturally, the option most beneficial to the site owner.

Now, it’s true that I wouldn’t personally select that method for increasing the circulation of my marketing literature. But the oceans of “fine print” found in business today confirm the exploitation of conclusion-jumping (and similar mistakes) by the customer as a widely-used method of doing business. As customers we may not like it, but it’s commonly practiced, and widely accepted.

While outspoken critics of designers assume the designer is in control of the website, it must be noted that they generally do not. Oh, some few powerhouse “name” designers have enough existing business prospects to be able to pick and choose projects, and walk away from contracts when the client insists on doing something they find unappetizing. But the vast majority of us are at the mercy of our clients. We don’t own the site, we’re just the hired help; just as liable to be replaced or outsourced as any other working stiff. We may preach good design practice at the top of our lungs, but when the resolute client/employer replies, “Should I find someone else to do this, then?” we have to decide just which of our design principles is actually worth fighting for. And, when making a small (for let’s face it, this particular design decision isn’t earthshaking in its repercussions) compromise in the absolute purity of our design enables us to eat or pay the rent, we will, however reluctantly, make the compromise.

It reminds me of my days in Network Security. Whenever I would set up a network, I explained that the firewall wasn’t there to set company policy, it was there to implement company policy. It was the company executives who would tell me what traffic should be allowed. I would explain the risks associated with each, and the rewards of permitting it, but the final decision wasn’t mine, it was theirs. Everyone has a different definition of “acceptable risk.” My job wasn’t to impose my definition, but rather to support theirs as effectively as I could.

What’s my point? Only this: Don’t jump to conclusions. This particular example may not, in fact, be a design “mistake”. Company policy, rather than designer incompetence, may be the reason it’s there.