Computersight -

More often than not, designers have rightfully been accused of retreating into their cocoons of ignorance as soon as their work of designing the user experience is finished, leaving the dirty, more hands-on work of developing it to the language gurus. This apathy is prevalent not only in the web development industry but also in the software and game engineering domains.

The hard truth is that the buck of development should stop with designers, such that they provide a turnkey solution to the user defined requirements. For optimum efficiency, designers should not only be concerned with creating the bigger picture but also painting it! These are the reasons:

Realistic Designs

With a clear image of how the final product will be actualized, a designer will come up with more feasible and practical concepts. Being an integral part of the development process, they carry the onus of ensuring their designs are implementable and user-friendly. A user-friendly website is not only a picnic to navigate from one page to another in a clear and concise flow of logic, but also provides a user with all the information they need without being too overbearing or cluttered.

Easier Communication

Virtually all products designed but implemented by different parties never sate both sides’ expectation, especially when it comes to intangible products like websites, software or games. It normally comes down to a compromise between what it should have been and what, in reality, it can be. Whereas the general idea is captured, it is seldom replicated verbatim. The panacea: designers should preach water and drink it to! This avoids confusion, misunderstanding and misrepresentation.

Convenient Iterative Development Process

A design, in practice, should not be absolute. By this I mean it should be flexible and affable to change without distorting its intrinsic essence to meet the systems’ technical constraints. These repetitive and necessary alterations can only be realized by the original designer. Not unless he is also a coder, this would be hard to implement. A designer-cum-coder can iterate more aptly where necessary rather than having a coder resubmit the design to the designer, who is rarely at hand, to implement the alterations. This may even create friction.

Better End Products

I often like drawing parallels between software, web or game development to orchestral music where the designer is the composer and the coder is the ensemble’s maestro or conductor. Imagine the latter had the composers score? Wouldn’t the symphonies be awesome and captivating? Not only were they crafted by a master craftsman, but are conducted by their creator!

Shorter development curve:

The designers doubling up as coders implies that the design and coding processes occur at least sequentially if not concurrently (e.g. in Extreme Programming tm) . This results in a shorter development timeframe, which translates to a bigger profit margin as the number of projects presented before their deliverable dates is directly proportional to the number of satisfied clients who will keep coming back , at times with referrals.

Designer Becomes More Marketable

Modern day designers worth their salt need to up their portfolio, if they need to remain relevant. What with the proliferation of cheap design colleges of questionable repute churning out “graduate designers” by the cent a sackful. “I’m a designer. How can i achieve this?” one may be forgiven to ask. By learning to implement what you design rather than leaving it orphaned in the hands of coders. After all, citing design and coding skills in one’s resume does not hurt. On the contrary, it makes one less redundant and indispensable, a life and death determinant in these financially tumultuous times of corporate restructuring (read mass retrenchments) and downsizing (read firing).

However, in so much as designers should also code their innovations, there are down sides to this scenario. Quoting Lukas Mathis, he of the controversial article “designers are not programmers”1, says:

“If the designer implements his own designs, he is beholden to two different goals: Clean code and great user experience. These two goals contradict each other. If you have to implement your own designs, you’re bound to compromise for the sake of code quality, which is bad for your interaction design.

Designers who implement their own designs face two issues: They know when a neat new idea will create messy code, and they know about all the existing code that would be touched by a change to the user experience……………….The two goals are at odds, because the user experience is all about the little details, and those little details all end up being messy bits of code you would rather not have to write.”

This aptly summarizes the hard stance taken by IT products development purist. They are of the old school of thought that advocates for clear cut lines between software design and implementation. Apparently, designers create for humans, coders create for computers. Thus user experience designers should design the best possible user interface and leave the code makers to make the best possible programming decisions. While this holds some merit as I’ve found myself trying unsuccessfully to abstract my mind from the code when I’m working on a user interface, it is ultimately more convenient to have the technical and usability constraints in perspective.

In conclusion

All said and done, the scope of a project under development may ultimately decide the designers and programmers role. A small application can be pertinently handled by a program manager2 while a large system will definitely need specialized personnel!

1: http://ignorethecode.net/blog/2009/03/10/designers-are-not-programmers/

2: term used to describe designers-cum-programmers by Joel in his website

Joe on Software; http://www.joelonsoftware.com/items/2009/03/09.html