Joseph Cooney describes in a humorous way how the design of user interface is accomplished in some cases. Unfortunately, this is a common phenomenon when a developer is called to design a user interface. On his own words:

A developer needed a screen for something, one or two text boxes and not much more, so they created “the dialog”, maybe just to “try something out” and always with the intention of removing it before the product ships. They discovered they needed a few more parameters, so a couple more controls were added in a fairly hap-hazard fassion. “The dialog” exposes “the feature”, something cool or quite useful. Admittedly “the feature” is more tailored towards power users, but it’s still pretty cool. The developer thinks of new parameters that would make “the feature” even more powerful and so adds them to the dialog. Maybe a few other developers or power users see “the dialog” and also like “the feature”. But why doesn’t it expose THIS parameter? New controls are added. Pretty soon the technical team are so used to seeing “the dialog” the way it is that they become blind to its strange appearance. Ship time approaches and the product goes through more thorough testing, and “the dialog” is discovered, but it is too late to be heavily re-worked. Instead it is given a cursory spruce-up.

Joseph Cooney: Developer UI

Don’t misunderstand me! I don’t blame developers, but I strongly believe that a strict separation should exist between system development and interaction design. Developers should not design and vice versa! Even in the case that a person is capable enough for designing and development (is there any person?), she or he should not participate in both stages of the same system implementation.

In my opinion, scenarios like the one Joseph Cooney perfectly describes imply two things: poor user requirements capture and poor implementation planning.