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.

  • 65
    As a developer, sometimes I enjoy designing the UX, but usually I prefer to be given concrete specs to implement. This isn't a threat to my autonomy because my job is to implement software and ensure the implementation is maintainable. In fact, having another group design the UX enables me to do my job better as I can concentrate on the internal structure of the software rather than having to dream up a UX.
    – R. Barzell
    Commented May 21, 2015 at 14:50
  • @R.Barzell that's fine, but I think that heavily depends on process. In an Agile process, dev needs to be part of that creative thinking group as much as UX. In waterfall, dev tends to be simply told what to do (for better and worse).
    – DA01
    Commented May 21, 2015 at 15:46
  • 9
    Also as a developer, I will push back if I think the experience will be negative for users or completely changes how something should work. For example, we had some mainframe people who wanted the Enter/Return key to go to the next HTML field, when Tab is the universal key for this (the entire team denied this one). However, as @R.Barzell said, a concrete implementation is nice. It's nice to get something that has been approved and just implement it. What I dislike is, "Come up with something," and then it's still not "right" 45 changes after the initial design (including process flow).
    – ps2goat
    Commented May 21, 2015 at 16:52
  • 1
    Code Monkey
    – bjb568
    Commented May 21, 2015 at 19:24
  • 3
    The developer should always have a voice in the process, especially when there are a clear standards (as in Tab vs. Enter), It's most ideal if the person designing the UX is not the person implementing it, but both should have 'skin in the game', which corresponds closely with motivation. See this excellent book: The Inmates are Running the Asylum.
    – Jon Coombs
    Commented May 22, 2015 at 3:03

12 Answers 12


Use dialog, not direction,

Use conversations, not coercion

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:

directive vs collaborative model

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 enter image description here

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.

  • 2
    In my view, processes such Agile r based on a 'wrong' assumption that everyone in process shares same values, goals & motivations. Reality is 'darker' than that! Specially in agile, while the collaboration might be more, it does not necessarily mean it is a 'better' collaboration. e.g. POs can influence UX work to a large degree, and on daily basis but are not necessarily in favour of UX. So in many cases the collaboration between UXers & PO (or even PO & developers) becomes less constructive. Partially because some roles are given more 'power' than others in this process. Commented May 22, 2015 at 11:29
  • 7
    @PariyaKashfi that's a good observation, and I think it's a widely held misperception of Agile/collaborative models. But, collaboration doesn't mean consensus! In a soccer team the striker collaborates closely with midfielders and defenders, but he also realizes he cannot do their job: in a proper collaborative team each player understands her role and comparative skill advantages. So, the failure to prevent "meddling" in a team is similar to a striker trying to play goalkeeper: it's not a flaw in Agile methodology but rather a failure of leadership or team culture.
    – tohster
    Commented May 22, 2015 at 20:11
  • where's the source of the first picture you've used? wanted to use it in a presentation Commented Jun 3, 2015 at 8:14
  • 1
    Great visuals here! Nicely done.
    – DA01
    Commented Jun 15, 2015 at 0:25

Most developers I've worked with have opinions about the UX, and often they can be valid. A lot of the time they cause more headaches than desired but that's primarily down to a lack of communication across the team. Communication is the antidote in this instance. I'll talk about some best practices and ideal scenarios that should help to illustrate some strategies for dealing with this dilemma:

Good Developers

A good developer will defer to the UX team when an issue arises that might affect the user - not because they are monkeys that don't know what to do, but because they respect that it's your role to investigate and solve the problem. If they have opinions on what the solution might be, they should share it but equally as a UXer you should ask them if they have any thoughts about how the problem might be solved. It doesn't mean you have to run with it, but maybe it's the best idea ever! You never know.

Good Designers

Likewise in good teams the UX designers will include developers in their process. Not all the time and not every day necessarily, but certainly at key points. Developers are naturally inquisitive problem solvers - if they just get lumped with answers but can't see the thinking behind them, they're bound to want to question your motivations and workings. Over the long term they'd harbour resentments if they didn't feel free to question UX.

In practice

One example of what I've done previously over a UX cycle investigating a particular feature (albeit a reasonably large one) would be to invite one or two devs to the initial kick off meetings and some following workshops. That way they'll get a good insight into what you're trying to achieve and why, and have a chance to provide input and feedback. This gives them a sense of ownership in the outcome, which is invaluable in maintaining team morale. After that, as the designs are evolving and feedback is being sought by the PO's etc, I'd occasionally have the devs in again to get their take on the design iterations. This isn't always ideal, but if you're skipping this part then you'd at least be advised to arrange a meeting as you hand over the project from design to dev. That way all parties can voice their concerns and remind each other of their respective roles in the process. (I hope a hand over meeting goes without saying...but you'd be amazed!)

In addition: along the journey there will be various user testing sessions and feedback from parties involved and it's important to document these all somewhere that is accessible to everyone. Lots of devs I've worked with enjoy poking around the UX documentation and understanding what went on.

Further reading

One really great book about UX that has a section on relationships between UXers and the team at large is Under Cover User Experience Design by Cennydd Bowles and James Box http://undercoverux.com/. It's a little dated in some aspects but it's filled with great insights and timeless advice.

  • 5
    I like this. I'd maybe go a step further with 'good developers' and say a good developer not just defers to UX but actively collaborates with UX. (and the reverse is true as well...the more UX and Dev collaborates, the better then UX in general)
    – DA01
    Commented May 21, 2015 at 15:47
  • absolutely, I'd encourage inclusivity and communication coupled with a respect for each others roles and subject boundaries and generally you'll muddle along just fine :)
    – Chris
    Commented May 21, 2015 at 15:52
  • 1
    Great answer - agreed on all points! I made some minor housekeeping edits, but tried not to change the spirit of the answer - feel free to change back if you don't agree.
    – CodeMoose
    Commented May 21, 2015 at 16:41
  • 2
    +1, especially for the emphasis on communication. Keep in mind, too, that if we developers have a good idea of what the end goal is and aren't just told what to build, we can do a better job building something that meets expectations or raising questions/concerns that no one else thought of ahead of time.
    – jpmc26
    Commented May 22, 2015 at 4:50
  • It's also the case that developers prefer not to have to throw away things they've just built - they will appreciate understanding what they need to build and why, as having a good understanding increases their chances of getting it right first time. It's perfectly possible to explain this to a dev without making them feel like a coding monkey - it is their job to choose how to build something, not what to build (although this)
    – Conan
    Commented May 26, 2015 at 8:34

This is about organisational structure and the classic silo mentality.

Lose the silos.

Silos emphasise personal goals rather than goals of the organisation. Strategies become fragmented and internalised rather than being part of a bigger picture for the benefit of the end users.

Passing off chunks of work from one group to another is not the right way to get jobs done well. Involve as many people as possible throughout as much of the process as possible.

Work as one team with common goals (those of the user), with open communication and knowledge sharing. Know the strengths of other members of the team, and ensure they know your strengths.

Reading material:

Smashing Mag: Breaking Down Silos, Part 1: The Consequences Of Working In Isolation

Leisa Reichelt: Everyone is doing strategy right now and Strategy doesn’t live in a silo (or, there is no such thing as UX Strategy)

FoolProof: Breaking Organisational Silos

  • 1
    The reality is that still there are companies , specially the big ones, who have these silos. Removing the silos although an ideal choice is out of the hand of UX practitioners. Commented May 21, 2015 at 9:17
  • 2
    @PariyaKashfi The FoolProof link above recognizes that this is the case and that it's no easy task but does suggest that the 'UX Champions' can try to act as 'agents of change' in trying to improve the situation where it matters. Commented May 21, 2015 at 9:22
  • 1
    +10 for Lose the Silos. No, wait. +100!
    – DA01
    Commented May 21, 2015 at 15:48
  • 1
    From the employer perspective, In many companies, silos are there to keep the integrity of the company in the sense of preventing the team from being autonomous and acting on their own, which would eventually mean the employees realizing their potential and starting their own start-up, and leaving the company for full time work at their start-up, effectively endangering the resources that the company has already spent on these employees while training them etc. Hence the silos. Commented May 24, 2015 at 15:14
  • 1
    @9kSoft which is a ridiculous way to handle things. If your staff is talented enough to go and do a start-up, silos aren't the solution--rather getting them to actually be collaborative and part of the solution is how to drive job satisfaction and keep them around.
    – DA01
    Commented Jun 15, 2015 at 0:26

Whether it is a 'coding monkey' or a 'pixel monkey' (for graphic/visual designers) dilemma, the problem remains the same. There are essentially two aspects of any role that has some degree of specialization. In the first instance it is about being able to solve problems in your domain area, and the second instance it is about implementing the solution.

The coding monkey dilemma is about implementing a solution that you didn't come up with, and therefore have either no personal interest in the outcome or don't agree with that it is the correct solution for the problem.

The 'coding gorilla' is the person who (presumably because they are in a more senior position or are more experienced) beats their chest about these issues but may or may not affect changes.

The solution really is to set the expectation for your role/position so that it meets your requirements. If you are happy to come up with a solution without implementing it, then perhaps the coding monkey job is not suitable. If you are happy to implement someone's solution without question it, then the coding monkey job is entirely appropriate.

P.S. I would think that the UX person might fall into the description of a 'magic' monkey, since many people regard the seeming very logical aspects of the research and testing work that UX practitioners perform to be some kind of 'dark/black' magic.

  • 2
    I like your notion of 'coding gorilla'! In fact, in the organisations that are still in transition and immature in UX, the developers become 'coding gorilla's to prevent becoming a 'coding monkey'. In reality, many organisations experience this, unless they have been startups with UX in their agenda from the beginning. Therefore, giving up some authority by bringing designers to the picture happens more often than the other way around. Commented May 21, 2015 at 9:21
  • 3
    I agree with this. To take it a step further, I'd say the issue is over specialization. In orgs that hires 100% specialists, and 0% generalists, you really end up with a bunch of assembly line monkeys.
    – DA01
    Commented May 21, 2015 at 16:12

There are great answers here already.

I'd like to provide a slightly different perspective on the topic, which is more process-based.

Test driven development

From the different strategies for software development, Test Driven Development (TDD) is one of the most popular ones nowadays.

It asserts that you should write tests before writing any code. But the paradigm goes way further, as many see the tests as the pivotal piece of documentation, requirements and specifications of a system.

Tests should capture:

  • Use cases, including alternative paths.
  • Expected feedback for various user actions.
  • The business logic.
  • etc.

Much of this is defined by the work of the UXer.

Tests may be written in a fairly natural language (see Cucumber), or using a programming language in (hopefully) a format that is understood by non-programmers; something like this:

describe( "distance converter", function () {
    it("converts inches to centimeters", function () {
        expect(Convert(12, "in").to("cm")).toEqual(30.48);

    it("converts centimeters to yards", function () {
        expect(Convert(2000, "cm").to("yards")).toEqual(21.87);

Human-centred TDD

The combination of human-centred design (meaning UX drives the design of the system and thus also its implementation) with TDD is becoming ever more widespread.

The process looks roughly like this (a lot has been omitted for sake of clarity and focus on the key message):

A diagram showing various development steps with test being the bridge between design and implementation

What's important to notice is that tests serve as the bridge between design and implementation. The argument often revolves around who should write the test, with the options being:

  • The UX designer - we need to document many of what the tests cover anyway, so rather than writing something in one place that is then converted into a test, it pays to actually only write it twice in a syntax that can be easily converted into a test.
  • The QA person
  • The developer - developers often have to write additional tests for internal code units anyway, and are most proficient with the syntax.

My argument is that if one considers round-trip engineering, UXers should be the ones writing the tests that capture much of their work.

What does it mean for developers?

  • First, good tests provide well outlined specifications.
  • Tests save developers a lot of time since the code is tested automatically rather than the developer having to test all previous behaviours with each change (to give one example, a structured date entry field I've designed involved 64 tests, most represent atomic use cases like "if the user is on the day partial and presses TAB the selection should move to the month partial"; if the developer was to test manually each use case after implementing it together with all previous use cases, there would be 2080 tests to be run)
  • Tests reduce bugs.
  • Tests allow developers to write better code since they can improve the code without fear of it breaking.

OK, so for all of this to happen what is needed? Developers shall write code against well specified requirements in the form of tests.

Does this mean 'being told what to do?'. Well, in a way yes. But consider the alternatives - just giving a short sentence of a required feature and hope the developer will do a proper design job and write the tests?

I'd argue that developers will be happier to be part of an HCID/TTD process, than any strategy that omits either or both of these components.

Of course, this still doesn't mean we shall not get them involved in the design process, but you should remember that both their persona and perspective on the system is understandably different from that of users or UX designers.

  • this is a very interesting approach, do you know some published work on this? Commented May 25, 2015 at 13:18
  • @PariyaKashfi published work on what exactly? Because if it's TDD there is loads out there.
    – Izhaki
    Commented May 25, 2015 at 20:45
  • published work on Human-centred TDD Commented May 26, 2015 at 11:36
  • 1
    I can try to find explicit sources; for now, in his series Clean Code, Uncle Bob clearly discusses the tests being THE specification document. Currently I spec out most new features using a natural language but in a test structure and format. First, it actually makes a lot of sense for me to work this way because it does really make you think on all the design aspects; then, these specs are easily tested by QA and can easily be converted into automated tests by the developers.
    – Izhaki
    Commented Aug 10, 2015 at 21:37
  • 1
    Also have a look at BDD. Here is a good introduction video. @FrankL
    – Izhaki
    Commented Aug 25, 2015 at 11:29

Engage developers in UX

Developers are smart and generally want to understand why and "because it's in the spec" just creates another reasonable question why is it in the spec? Explaining, defending and gaining respect all help but here are specific activities I have found to create leverage:

Let developer see and feel users issues

In user tests, interviews, bug reports and show and tell are all opportunities for developers to not only understand but all feel the importance of their work on the user. Not only do they value UX higher but are more motivated to do a better job.


A well set-up design workshop not only gathers range of ideas, but also clearly communicates. A key part of the two-way dialog is that "hidden gotacha's" that can later come out and pollute designs are revealed early. That way designer is not seen as "superficial" but rather part of the team dealing with the nitty gritty.

Allow developers to win some opinions

An Agile environment with a robust feedback cycle allows some close run decisions to go either way. Later if course correction is needed it can be made and you still have a great user outcome. Allowing the developers favourite design through has two possible outcomes (a) it measures highly with users and you learn something possibly novel (b) it measures poorly with users, and the developers learn to take UX steer better. UX does need a "veto" power, but wielding this at right place and time is crucial.

Design for implementation

This may be contentious, but without compromising on overall quality work with developers about UX options that are friendly to their internal pressures (tooling, timing and skill-set). On occasion this optimised-for-delivery UI can deliver boon in consistency, simplicity and implementation accuracy


Probably the most thought provoking for developers is The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity by Alan Cooper

Also starting with a non-tech take may be engaging The Design of Everyday Things by Donald Norman

Adjust engagement level by Developer interest

In a development team you will normally find a mix of interest in UX. Some want to be closely involved in UX and some just want to work off fixed specifications. Either way it is key is when any queries get resolved through communication - not independent action.

  • Plus one for mentioning The Inmates Are Running the Asylum .
    – Jon Coombs
    Commented May 22, 2015 at 3:13

Some of the most depressing times I've had in my life, were when I had to implement something that somebody else designed, and they designed it poorly. Putting a lot of energy and time into something that you know is going to be completely useless (or worse) is about as soulcrushing as our job can get. The closer I got to the start of te project, where all these design decisions are usually made, the happier I became.

So my solution would be to practice co-design. A developer is a stakeholder in the project. Your job as a UI/UX professional is not to develop specifications for them to implement, it's to guide a process. Get your boss, your client, the lawyer , the user and the developer around the table and shape their discussion. Get them all on the same page and make sure they're working towards the same goal, each from their own perspective.

All the tools we have, user stories, wireframes, personas, are all designed to help you do this: to let non-designers contribute to the design proces and to turn differences of opinion into elegant and creative design choices (instead of an argument that is settled when the boss chooses the cheapest option).

If you create this kind of meetin and if you let people come back to the fundamentals from time to time, I'm sure you get happy developers, who are really motivated, because they understand why the product is designed the way it is, and how they can help to reach the common goal.

  • 1
    Peter, I undersand your frustration and agree with you on having a collaborative approach, but at the end of the day it is also a matter of accountability and having clearly defined roles and remits that are based on expertise and knowledge. For example, User Interface designer and User Experience designer are completely separate roles with a defined set of responsibilities. They can and should collaborate but each is accountable for their work.
    – Okavango
    Commented May 21, 2015 at 15:23
  • 1
    @DA01 Not having a specific role (one person, or group) end up in loosing the overview and alignment on UX (or any other topic) in particular in bigger organisations, with complex products. Although I agree that UX is a collaborative work, I believe there is still a need for an authority and a role to align UX across the organisation. Not having a UX role would be like having an orchestra with no conductor. Commented May 22, 2015 at 11:18
  • 3
    @Okavango I'm not against specific roles. What I'm saying is that everybody needs to be present at the table, and there needs to be a constructive discussion in a common language. Co-design is not about everybody doing design work, it's about everybody contributing meaningfully from their own perspective to the design of all aspects of the product. (Also, I would caution against designing your workflow from the principle of accountability. If your starting principle is "who do we blame if this thing blows up?", you've lost the battle for a positive design process at the first hurdle.)
    – Peter
    Commented May 22, 2015 at 13:52
  • 2
    @PariyaKashfi That's true, but the tools of UX (user stories, personas, wire frames) give everybody a voice, regardless of which aspect of the product they're responsible for. They allow us to address the concerns of the developer, the security guy, the accountant, etc. and work together towards an elegant and creative solution. The person with final authority should not be making decisions, but facilitating, creating consensus. Good UX requires everybody to come together, so UX is often more about facilitating well than about designing well.
    – Peter
    Commented May 22, 2015 at 13:56
  • 1
    Well I can't agree more! and agree 100% on your last point! There is always legacy issues and bad processes in every organisation and these need to be dealt with first so when people are working collaboratively they are not simply masking the symptoms but are actually fully embracing their role and responsibilities while bringing their strength and their perspective to the benefit of the user as well as the team.
    – Okavango
    Commented May 22, 2015 at 13:59

I think the key here is to distinguish between telling the developer what needs to be done and telling the developer how to do it.

The UX designer specializes in figuring out what user experience is going to be more positive. This involves ease of learning and ease of use, among other things. If the developer respects the UX designer, the developer will usually (not always) respect the UX's opinion about what the the system should look like, facing the user. And the UX should express that opinion.

If the UX designer respects the developer, the UX designer will stay away from telling the developer how to do it. Development is about how to go about doing what needs to be done. Focus on the interface, and leave the implementation up to the developer.

The key is mutual respect. Without that, even the right organizational structure is going to fall flat. With mutual respect, things are going to work, even when one party occasionally treads on the other's turf.

  • I c you point but in the cases I have seen, developers want to come up with the UI themselves & see it as part of their job, or expertise. Here, I am not referring to decisions about algorithm or or architecture etc. 3-4 decades ago for instance a role of IxDer did not exist and all of these decisions were made by developers. Still these are members of the community that see UI are part of development, and telling them what goes where and what the sequence is (i.e. the IxD) equals to telling them how to implement it (i.e. do their job) Commented May 21, 2015 at 11:54

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

I update my resume and find a new job.

Unfortunately, for both coders and UX people, what makes your role a 'coding monkey' role is organizational culture. The biggest red flags I've found are a) The org is huge and b) the org is stuck with waterfall methodologies.

With Waterfall, I've found that UX increasingly becomes a highly paid note taker role. (Well, hopefully highly paid). Our only job is to draw pictures for management.

Moving to Agile helps. It's not a cure-all, but does bring about more collaboration--both for UX teams and the development teams.

My current challenge is that I'm trying to get a dev team that has been brainwashed into being coding monkeys for years. They don't know what to do anymore when we ask "so, devs, what do you think?" :)

PS (This is a great question!)

  • Agree - great question.
    – Jonny
    Commented May 22, 2015 at 17:42

Education and communication. This happens in every service relationship - telling the lawyer what to do, or the plumber what to do may be valid sometimes, and may not be valid other times.

When your client is asking for bad work, it's the job of the expert to communicate clearly that what they are asking for isn't appropriate, and why - and then, if they persist, have them formalize the request in writing, acknowledging that they are asking the expert to go against their expertise - then do the work and move on.

You communicate to them what you expect from them in the relationship, what they should expect from you, and if they start pushing during the work you communicate, you educate, then you move forward in whatever direction you have worked out with your client. That may, in fact, be to break the relationship. It may be to compromise.

The key, though, is the initial foundation you created with them on which your relationship is built. If they don't trust you as an expert, or you don't trust them as the client to know what they are asking, then you're going to run into these problems frequently.

Then you develop new relationships, and end relationships that aren't working for you as needed.


Collaborative not collective design

Its important to distinguish clearly between collective design and Collaborative design as they could lead to two completely separate outcomes!

Collaborative implies input from different roles : (people + experience + Knowledge + perspective etc. to achieve a shared target or goal. The result is a strong and viable solution to a problem.

Collective implies, everyone is involved but not to achieve a shared target, rather to have their say. This results in a diluted, compromised and poor solution as it tried to cater for the opinion of many.

UX is about methods and processes and less about opinion

There are ways to solve the coding monkey dilemma! The key here is having a methodology and a process in place that ensures that no team member feels alienated while also delivering better solutions:

- Have a clear collaborative development model (agile works best) with clear and standardised inputs and outputs.

- Adequately validating proposed solutions: User journeys, personas, testing, research, heuristic reviews etc Always provide and share clearly structured rationales and encourage other members to read them (not easy:)

- Involve all the relevant people in your team in early refinement sessions and externalise UX work as much as possible: Understandably, no one like to be in a position where they are always reacting to someone else work! People like to have the feeling of control over what they do, of being consulted rather than informed.

- Don’t get into a dialogue of the deaf instead take all opinions on board and convert them to hypotheses to test. After all if we are all working to the benefit of the user then testing results should be a very convincing argument against any misplaced reservations.

- Get agreement on some design principals and create a pattern library that documents the different use cases.(Quick Gain)

The list is not exhaustive but should in principle ensure that everyone has contributed positively to the development process from early stages to final release.


Just as in combatting real racism, role racism is best tackled by getting people together. Work together, on the same team.

I should probably qualify that I do not intend to trivialise racism, and if magically I was allowed to get rid of one the real would most definitely go first.

Start by not being part of the problem. Do not believe in, join in, or propagate the stereotype (and it is a self fulfilling one). If you've ever been to a ux conference, it is likely that at least one speaker will have made fun of an engineer or developer by acting like an ape or caveman. It is not usually done with intended malice, maybe intended irony. It gets a good laugh. Don't take part.

Other answers have some excellent suggestions for methodologies that promote collaboration.

It is likely in an organisation that you won't be in a position to change the whole structure. I believe you can make a big difference to the macro by affecting the micro. Ask to join in planning / stand ups. When working on a problem, wireframes maybe, take your laptop and sit with a developer and collaborate for half an hour or so. Invite developers to critiques.

It is possible that you may look a fool sometimes, but who cares. It is also likely you may tread on people's toes, so be careful and humble (but carry on doing it). When the little practices become the norm, then it is sometimes possible to start suggesting the bigger ones.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.