The people who write the code and the folks who are in charge of what the application should look like often butt heads. Justin James gives programmers tips on how to resolve conflicts with designers.
Technical teams and design teams are often at odds with each other. It's tempting to think that we (the programmers) know best; after all, we're the ones neck deep in the application day in and day out, and if it works, who cares what it looks like? At the same time, the design team often has taken things into consideration that we might not have, like usability, accessibility, marketing, branding, and so on. As much as it may pain us to admit it, these things are often just as important to the overall success of the project as the "under the hood" details. So the next time you're in a disagreement with the art team, here are some tips on how to resolve the conflict.
Conflict resolution tips
The first thing to do is understand the cause for the conflict. Chances are, the creative team has a sound reason for their approach, but they may be having a tough time putting it into words, or you might be having trouble understanding what they are trying to say. Ask them to explain the underlying assumptions and reasons behind their request. As they explain, repeat back to them what they are saying, but in your own words as you understand it. That will give them a chance to correct you if you really do not understand. This is basically a listening comprehension exercise to clear the air of any misunderstanding.
Once you understand the reasons behind their request, you can evaluate the request on its merits. Does the request try to accomplish an important goal? Maybe the art team is asking for something that is important but not a priority. Or perhaps there is a better way to meet the need without doing the work the way they have requested. On many occasions, I have seen people file a request that is filled with "how to do this" instructions, when there is a better way to accomplish the goal. When you see what they are trying to accomplish, you can act as a partner to make it happen.
You should also ask yourself, "Why am I resisting this change?" Many of the times I refuse a request or dig in my heels it's because there is something about the work that I don't want to do. Maybe the change undoes work that I did on my own, and my ego is a bit bruised that my idea wasn't good enough. Sometimes the change goes against my particular tastes. Occasionally, there is something about the implementation itself that I am fighting against; I like the change, but maybe it is a lot of work for little payoff. And of course, there is always the possibility that there is a legitimate technical reason to not go forward with the change.
If your objection to the change is a technical one (or another legitimate issue), you can work to find a better approach to solve the underlying problem. But if your reasons for not going ahead with the change are not sound, it's time to set yourself straight and cooperate. The trick to working through these kinds of issues is communication.
I've outlined a general plan for resolving conflicts between creative and technical teams. Hopefully, you will be able to use these conflict resolution tips to keep your projects on track.