Adaptive Path Blog

It’s long been my belief that the perceived dichotomy between design and development, a dichotomy that is often fostered by both, exists to the detriment of both. The potential negative impact of of this dichotomy has increased as recent developments continue to challenge us. To use Ajax and RIA’s effectively requires expertise that spans both design and development. On another front entirely, as we move into the realm of service design, we enter a territory whose constraints and possibilities are unfamiliar to us.

This was brought to mind again several months ago as I was listening to a presentation given by a hardware designer. In discussing how closely, or not, some hardware designers work with manufacturers he posited a dichotomy between design integrity and manufacturing priorities. My hackles rose instantly. The implication was that there was some clear and pure design vision and that anything that pushed back against it was to be avoided. Including, evidently, the real world. Clear design vision is a wonderful thing but it doesn’t mean that there are not real physical and manufacturing constraints to building products that designers should be aware of. I was disheartened but not surprised to hear a sentiment so familiar to us in the web applications world. Designers can be deeply distrustful of the developers that are actually going to make their visions and ideas real.

Here is one of the few effective keys to the design problem — the ability of the designer to recognize as many of the constraints as possible — his willingness and enthusiasm for working within these constraints. Constraints of price, of size, of strength, of balance, of surface, of time and so forth.

- Charles Eames

Developers work in an environment of constraints. There are only so many developers or a limited amount of time. The database will only fetch the data so fast. There is often amongst developers, just like designers, a strong desire to find technically elegant solutions. These elegant solutions are not reached by being willfully ignorant of the constraints or being negligent about learning what is actually possible. But, whether or not an elegant solution can be found, the ultimate metric of success for developers is “Does it work?”.

So what do we do? One simple answer is that we work more closely together. This is easier with smaller teams. Significant web applications can and are being built with fewer than 10 people involved from start to finish. Even in cases where larger teams are unavoidable, approaches that involve prototyping or some sort of iterative cycle can be useful. Aside from their other benefits, these approaches can ‘game’ the corporate structure to get the right people in the same rooms on a regular basis. With increased exposure, both developers and designers get a much better sense of each other’s expertise and concerns. With increased exposure we both get better at finding the place where the possible and the ideal come together. Most importantly, we get to align behind the realization that we are all trying to build an application that we’re proud of and we’re trying to do it together.

This entry was posted on Wednesday, June 27th, 2007 at 7:07 am and is filed under Collaboration, Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

This post is licensed under a Attribution-Noncommercial-No Derivative Works 3.0 Unported License.