Re: [IxDA] Another Rant - Expectations and Roles - Designers vs. Developers vs. Recruiters...blah, blah, blah
23 Aug 2010 - 1:13pm
I'm a little hesitant to step into this debate given the combination of my lack of formal expertise on the nature of specific roles in interaction design as a field and some of the rather vitriolic comments that have been slung around in this thread, but in the interest of simmering things down a bit I'd like to throw out an explanation for why this is such a messy topic in the first place from an organizational theory perspective (one of my own specializations) informed by some experiences in the design of digital media for learning. Based on my experiences working with and as a designer in collaboration with (software) engineers on various projects in instructional media (largely digital), it seems to me that there's a lot of variation based on the individual organization/work group in how these roles get parsed and how titles get assigned to individuals within them. I'm guessing that in part this creates some strong feelings from people whose groups have been badly constituted in the past or in which roles were poorly defined, or who have a deep commitment to the way things get done in their organization.
I understand the intention of this rant involved issues around titles and recruiters, but it seems to me that part of the problem with role definition that feeds back into the job title/recruitment issue involves the high level of variance that a similarly named role might require within a different organizational context. At the end of the day, organizational structure and culture have as much to do with the role/title issue as the actual work does. To ground this in some kind of meaningful context, when I've been working with smaller groups formal titles like instructional designer, web designer, programmer, and content expert generally had very little bearing on the expectations for which of the various duties one might attach to these various roles as they were realized by different individuals depending on collective need. The H.R. folks needed titles to hang on people so we had them, but duties were shared flexibly to the extent that various members of the team had overlapping capacities. I haven't worked on any huge teams, but based on my research on organizational theory and leadership I think it would be fair to say that there's a greater need in those contexts for titles to be matched more closely to roles as greater skill specialization is an affordance larger teams provide, but this generally comes with the need for a better defined organizational structure to allow everyone to exercise their expertise in a productive manner.
To bring this back to the programmers/designers binary which Maurice introduced at the top of this thread, in some organizations that binary is certainly false and the role will require designer/programmers because that's the way the production process is organized. This seems to be particularly true if the team is small, but again specific organizational contexts will vary. In other companies having designers who are not programmers might be absolutely essential because organizational work flow benefits from breaking these tasks out, or perhaps because the sheer number of workers required to realize the project is high enough that you cant' really allow things to run fallow while trying to find the relatively rare designer/programmers to fill the requisite number of positions to make things go.
Finally (and on an only somewhat relate topic), no matter how much you might hate code, I personally believe that if you're working with programmers at the very least you need to be able to communicate with them about code and understand the constraints of the development environment they're operating in. This might mean learning some code, or it might mean scheduling some time for a conversation with your programmer/s. In either instance, engaging in design without some understanding of the coding environment is likely to be an exercise in frustration for all parties.