selling ux - The coding monkey dilemma

This is a quotation from an interview with a practitioner with a technical background and role:

Developers are all smart people; they don't enjoy their work if somebody tells them this is what you need to do and this is how you're going to do it. Nobody wants to feel like a coding monkey.

I call this 'the coding monkey dilemma'. I am sure many of you who work with UX have experienced similar situations in which the role of a UX person, interaction designer or similar is somewhat considered a 'threat' to job satisfaction of developers. I agree that introducing new expertise such as UX means division of responsibilities and losing power in some areas for other roles.

My question is what approaches (processes, tools, methods, etc.) do you use in your work as a UX expert, interaction designer, or similar to overcome the 'coding monkey dilemma'?

I would also like to read more about this if you know of any references.

Answer

---

Code monkeys are a symptom of a lousy design and development process which emphasizes direction/management versus dialog/collaboration.

There are many names for this kind of process (waterfall, linear, directive, etc) but at the heart of it, the code monkey syndrome comes out of a design/development model where developers are seen as resources to be directed rather than partners in a process:

The directive approach is weak for many well-documented reasons.

• Developers feel unempowered, uninvolved, and underappreciated in the process.


• The process stifles upward feedback, or slows it down.


• The lack of feedback and iterative mechanisms makes it slow and inefficient ...and much more

---

Collaborative development

Turning code monkeys into collaborators

Collaborative development models generally use concepts of shared ownership, conversations, and iterative development to accomplish several goals:

• Avoid code monkey syndrome by giving developers (and other stakeholders) ownership and an active role in decision making.


• Improve 2-way communication by breaking down walls/silos/functional barriers which can slow down open co-operation.


• Speed up development by providing an experimental/prototyping/iterative rather than linear process, resulting in faster failure/error detection and faster product evolution. ...and other benefits

Under a collaborative development model, the UX professional becomes a facilitator, not a director of product activity.

• By promoting collaborative design process, guided ideation, facilitated conversations, and shared ownership of the product development process, the UX professional maximizes the contribution of team participants instead of directing team resources to do a job.

There are many tools and frameworks to reference here for facilitating collaborative development:

• 
  

  Frameworks such as Agile, Spiral, Lean, and others provide overall structure and guidance for collaborative product development.

  
  


• 
  

  Behavioral models such as Flow, Hyperfocus, Hierarchy of needs, N-Ach and others help provide psychological models for motivating developers and designers in a team environment.

  
  


• 
  

  Team process methods such as design interviews, storyboarding, structured ideation, and others provide collaborative guidelines for accomplishing specific tasks inside the production workflow.

  
  
  

Hopefully these terms/concepts will provide a launching point for your further research.