A Perfect World?
In a perfect world, designers know how to develop, and developers know how to design. However, this is often not the case, and as has been brought to my attention recently, it can seriously bog down and lessen the quality of any user interface. There is a layer of overlap between the design and development teams of any project that needs to exist to facilitate perfect cooperation and a flawless user experience.
Problem Number One: Designers who don’t understand code
There are two main strains of this problem that I have seen take place. The first is that the designer holds himself back from creating a perfect design, unsure of whether or not things are possible. “Is it feasible to have X feature?”, he asks himself, and ultimately leaves it out of the design. Although the final product looks good, it could look better. The second problem that I have noticed is when designers go over the top with their designs, and implement design features that go against the code base, adding awkward features that look great but don’t necessarily scale. What works in flash, for example, does not always work so well in plain old HTML. This is where the code knowledge comes in.
A designer with at least a little development experience should have a general idea of what he can do, and will feel more comfortable speaking with developers with the “How about this?” sort of question. The developer and designer will be able to speak the same language, and can come up with a farsuperior solution.
Problem Number Two: Developers who don’t understand design
This is, in my opinion, far worse than the above problem. I have seen countless examples of perfect, flawless, completely unusable applications. Many developers see things very differently than designers: they design to display the data they output, and organize layouts according to the back-end. I frequently have drawn-out debates with a friend of mine, with whom I have been working on an online game. A recent argument went something like this:
“Matt: The defend and the attack forms are the exact same.
Me: Yes, but, they serve very different purposes. Defend is set-and-forget, attack is something that changes every round.
Matt: But the forms are the exact same, so they should go in the same place.
Me: No, the attack form should go where the attacks happen, the defend should go with the long-term options storage, since you only set it once, like the other options…”
And, so on, for a few hours. I’ll spare you the details. I’m sure you can tell who’s who: Matt is a developer, and only a developer. He is right; they are the same fields, the same select boxes, the same buttons. However, from a user’s perspective, they are radically different, because one is reset every few seconds during a fight. Matt is a brilliant developer; but, an intermediary needs to fight for the user, because the developer cannot always see from their standpoint when they’re used to thinking about pure functionality.
Go to the Library
What this all comes down to, is that each side should take a moment, and sit down and learn the other’s trade. Developers should see why designers do what they do, and designers should feel open to taking suggestions and discussing ideas with developers. It is when this happens that well-designed, attractive, usable applications can be developed.
