It’s common in the web and app development industry for stakeholders to make a distinction between “designers” and “developers”. One of the things I’ve noted about this distinction is that it opens the door to antagonistic perceptions and even behaviors between the two camps. At a conference a few years ago, in the presence of developers expressing disparaging views regarding designers, I suggested that, “Designers are developers.” The audience was a but stunned. I had to explain what I meant:
The more both camps regard each other as part of the same effort to produce Great Things, the better it will work for everyone and the resulting Things. As part of this, the distinction between designers and developers needs to be toned down so communication between those engaging in these facets of product development can improve.
More crickets. I tried.
Since then, I’ve come to believe that a big part of the problem has less to do with those placed into the two camps and rather a lot to do with the corporate structure around the process. As corporations increasingly embrace metrics-oriented performance evaluation, the pressure on those subject to those evaluations to produce the desired metric increases.
Mithat’s Maxim #294: “People eventually do what they are rewarded for doing.”
Supporting this is a clear delineation of “my” versus “your” responsibilities. The consequences of this for the product development process should be obvious.
When I was an undergraduate, I read a study that found team productivity is maximized when competition within a team is minimized and when there is (perceived) competition outside the team. My personal experience to date has done nothing to make me to think the first of these assertions has become obsolete. Assuming this isn’t wrong, the consequences of this for the product development process should be equally obvious.