Education

Resolving conflicts between the creative and the technical teams

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.

Summary

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.

J.Ja

About

Justin James is the Lead Architect for Conigent.

28 comments
Lucky2BHere
Lucky2BHere

After nearly 30 years in this business, and working from both sides and the middle, there are a few things that need to be done first to make this all work. Stick with me on this one, even though a lot of what follows sounds squishy. These are critically important points. The best possible way to keep momentum and understanding going is to meet any issues head-on. That will keep them from becoming bigger and permanent misunderstandings: - Identify one person in each group to be the primary contact for all communications. If possible, choose them according to their ability connect with people in the other group. These people also have to be willing and able to deal with daily conflict. - Set up a *very* regular weekly schedule to discuss progress and issues with both groups. Daily between the two primaries. Don't miss them! - Set up an open, easily accessible forum for quick, public exposure. No anonymous postings! - Create - together - a master direction doc that clearly outlines goals for each layer, with business goals overriding all other goals (what is this project about in terms of value to the organization). Post that sucker up on the wall for everyone to see, every day. - Vet possible - and inevitable - changes throughout the project with the primaries. - Take group breaks regularly. - Lunch with the "enemy". - Do periodic, informal reviews along with the standard stuff. - Ask to see what the other team is doing - literally sit with them periodically. - Be careful in your wording when asking for clarification. Everyone thinks they're smarter than the other guy. Assume the opposite. Really. Some people feel colors, some people think in cubes. Both - and everything in between - are valuable. No project lasts forever - though it might seem like it. Whether it's 90 days or 24 months, there will be an end. Suck up all the knowledge you can during that period, most importantly, including how to interact with people who have different ways of looking at things. Ultimately, everyone wants the same outcome: a successful end to the project.

pgit
pgit

I have a nephew who's a graphic designer for a huge internet service company, I won't mention any names but one thing he mentioned was the budget just for M&Ms for the home office is something like $64,000 per annum. I have a friend who is the database developer for an equally huge and successful set of companies, I'll just say if you have cable or satellite TV you regularly see at least one of their many properties. The two of them landed these jobs and said they'd died and gone to heaven. There are none of the conflicts of the type being discussed here in these mega companies. In all their jobs prior those conflicts were the biggest grind, the #1 bummer they faced. The difference is entirely the atmosphere upper management has established. These companies can slather money around because they are successful, it's not that they are successful because they had a lot of money to throw at the business. Developers of every stripe are never in a position where they deal with conflicts directly with one another. There is trusted management immediately above every function that everyone absolutely loves to go to with their concerns, and conversely when a manager comes to you with an order for some change or other, people are happy to comply. If there is an inordinate amount of work involved, or it's going to be a lot of tedium, management recognizes this up front and invokes some kind or reward up front to go along with the chore. My SQL ninja friend takes extra paid time off after completing tasks that otherwise would have piled onto the list of reasons he should be looking for another job. Likewise my nephew has garnered some perks not the least of which being he gets to spend some time working with backend developers so he can expand his skill set a bit. It also helps to know what those developers face as their own "oh brother!" types of tasks. He never would have had such an opportunity anywhere else. He'd previously been in companies running very lean and piling too many tasks on everybody, while setting desirable (to the company) but totally unattainable goals. The result was management was always in a position to tell everybody that they were not working up to par. The time my nephew got to spend with the backend folks was on the clock, but unproductive so far as the department's output benchmarks are concerned. In fact developers probably wasted some time showing him the ropes. But obviously management at this place thinks there is some benefit to the ultimate bottom line in catering to the specific desires of their workers. These two tell me the issue of whether there is conflict between sets of developers is entirely a matter of the atmosphere the top brass establishes, including getting the right people into those management positions. The same "you've got to be kidding me" issues still come up, but whatever BS that entails is more than mitigated by management negotiating some indulgence up front. Usually that's more time off, a bonus of some sort (more often the likes of golf clubs rather than money) and occasionally a change to the everyday operations of the office.

Marc Jellinek
Marc Jellinek

With any well architected system, there is never a conflict between UI and back-end. They are separate functions. The difference is (alluded to by Tony Hopkinson) is that when a "creative type" drops a new UI element onto a wireframe or mockup, that requires implementation in the mid-tier and the persistence (database) tier. God help us all when something that was assumed to be a one-to-one relationship (like names) becomes a one-to-many relationship (like a history of changes to names). From the UI designers perspective, it's a couple of clicks within PowerPoint or Photoshop. From the mid-tier, database and QA perspective, it's tens of man-hours of new, unanticipated work... often without a deadline extension. I agree... always assume the other person has a point. But also always assume that any change has a cost. God save me from anyone who says "can't you just do THIS...". Want to know how long this problem has existed in application development cycles? Google "SMOP" (Small Matter of Programming) or "minor detail" from the Jargon File... originally written sometime in the 1960s. Then read the book "Games People Play" by Dr. Eric Berne.

Old Timer 8080
Old Timer 8080

I just got this message from your server..and it sums up what the real problem is from a HARDWARE ENGINEER standpoint: Takeaway: The people who write the code and the folks who are in charge of what the application should look ARE often butt heads. When you get a call from the front office types saying: " How long will it take to create this product I just sold ", you know you are going to have a rough week ahead. I cannot count the times I've had to say " NO, THIS HARDWARE PRODUCT WAS NOT DESIGNED TO DO THAT " and have the OTHER SIDE ( program and software design people ) try to fit the proverbial square peg into a round hole... That just makes these types another kind of " HOLE " in my book.. I haven't really seen a change in the hardware vs software " war " that has existed since computers came into being......

juaniotoo
juaniotoo

Read with interest your posting of the conflicts between the graphic designers and the programmers, and I must say there are times I'm trying to do graphics, invariably something goes amiss. Usually what was supposed to work, does not. Take the tool bars out of say, Photoshop, Illustrator, or in particular Dreamweaver and Flash Pro. These awesome software programs will, at times, have glitches. You can imagine the expletives I fire off at said programmers due to their inefficient or sloppy work. I've been wanting to say this for a long time.

bpmmx
bpmmx

Conflict begins at: "...we (the programmers) know best...", and continues even if/when you (programmer) ask: "to explain the underlying assumptions and reasons behind their request..."... If the Programming Dept. is truely on equal sides with the Designing Dept., then the above procedure has a good chance to widen the gap between the two, not bridge it, be cause it seems as if one (in this case programmer) is questioning the (authority of) other, and believe you me - nobody likes that, specially if you're already an established department (programming or designing) - meaning: you know what you're doing (in your dept.).

Scuffer
Scuffer

Many times I've had programming or system implementation people just give me blank looks when I start asking questions about accessibility or user-centric design. As long as all the form inputs end up in the right database columns, the money goes to the right place, etc., it "works, " right? If the developers understand the UI they (or the vendor) built, the end user won't have a problem, or so they seem to think. Or they think usable design is an afterthought, like a skin that can be added at the last minute. Lots of programmers, especially if they are doing web applications, need to become more familiar with front-end design considerations, but I'd also say many front-end designers could stand to learn about more about those "under the hood" issues too.

wsargent
wsargent

I would also look for a territorial bias on either side that overestimates the value of their contribution. It is very healthy for team members to want to contribute their best effort, but sometimes self-interest blinds or trumps the business interest. Although it is often expressed less bluntly, it boils down to "my contribution is more important or valuable than your contribution." Communication skills can uncover it, but in cases where exposing it is difficult or may create new problems, a solution is to refocus the discussion on the common goal.

endlesslove7
endlesslove7

It is totally a different case when it is the designers who don't consider usability and feasibility of certain features that they put into their mock-ups. The sad truth is, it is their designer mock-ups that goes to the management and gets approved. When photoshoppers do the information architecture and system design, programmers/developers scream "Dissaaassteeerrr!!!!" vote up if you agree.

Tony Hopkinson
Tony Hopkinson

sort of implies technical are not creative... Anyway, some of us have never believed that the ways it looks doesn't matter, after all "It works" is very subjective as far as UI goes. The 'fight' for me generally revolves around Add some feature to a standard control that has nothing to do it it. Bloat features quickly from other applications leading straight into monolithic design. Not appreciating that in order to achieve features in the UI, the control and data layers need to support them, as in change box to red if X, when X isn't persisted, or it isn't passed through to it, or hopefully both... I've worked in places where looking good doing it wrong was more important than getting it right, always a mess that, and quickly.

AnsuGisalas
AnsuGisalas

Maneuvering communication mismatches is difficult. A good starting point is a basic assumption that the other person could have a point. Looking closer at ones own reasons for resisting is great advice, albeit hard to do in some cases.

metalpro2005
metalpro2005

If we are going architectural, please keep in mind that every stakeholder has got principles for his/her line of work. These principles needs to be negotiated and agreed upon before any work can be done. To make things even more complicated, these principles apply on a conceptual level (what), on a logical level (how) and on a physical level (with what). Discussions often arise when these principles are considered 'common sense'. Or that a discussion starts, because people are talking from different perspectives i.e. principle on a conceptual level are being applied on a logical level. And do not swap principles with requirements ! Requirements are not negotiable. What you often see is that principles are promoted to requirements and are frustrating the entire team.....

HAL 9000
HAL 9000

Any organization who employs Stylists have the same problems between the Engineers who develop the thing that they are working on and the people Tasked with making it look good enough to sell. The solution which can be as above all depend on what it is you are developing. For instance Car Designers comprise 2 distinct teams often many more but you have the Designers who make it do what it was designed to do and the Stylist who make it look salable. You can then also throw in the Accountants who tell you how much you can spend to make the thing to begin with and so on down the line. Most times with Production things you need the Developers and Stylists to get together and agree on how you will make something look and this isn't always the easiest thing to achieve but it needs doing. Then for some instances there are times when the Designers have to control the Stylists like in the case of the Porsche 959 the Stylists where told that they could change the color any way that they liked but they couldn't change anything else. It all depends on what it is you are designing for. ;) Col

Sterling chip Camden
Sterling chip Camden

or, more technically, a stakeholder. A lot of conflicts arise because the stakeholder relationships aren't clear. I find that treating them as a user helps me bring it back to "what do you need out of this?" and helps me weed out the dictates on how to do my job.

pgit
pgit

This post is exactly the reason I love TR, the articles are good, and folks with experience sharing their knowledge like this is invaluable. - Create - together - a master direction doc that clearly outlines goals for each layer, with business goals overriding all other goals (what is this project about in terms of value to the organization) That's priceless.

Tony Hopkinson
Tony Hopkinson

Change is a given. Designing so you can cope with change (how much flex depends) is initially expensive, but saves buckets in the long run. But we are driven by short term requirements, so that work doesn't get done, and your implementation gets further and further away from your needs. Another issue we all need to factor in is stunnigly illustrated wtth the two gigabyte flash intro on a web page, for dial up customers.... An extreme example admittedly, but just as you can't take usability and presentation out of the implementation, you can't discount implementation considerations in the design. Far more likely that it was simply the best they could do with the resources they had, than they were just sloppy, far more.

Tony Hopkinson
Tony Hopkinson

If 'you' can't take being asked why without feeling insecure, that is not the other guy's problem. Works for either side of the divide that. Which raises another point, why is there a divide?

Tony Hopkinson
Tony Hopkinson

One of the first principles of good design that. last minute, well that's never a good idea, ever.

Sterling chip Camden
Sterling chip Camden

... and the "logical" arguments on each side often degenerate to mere rationalizations. If you can close your eyes and hear nothing more than barking at each other, you've reached that place.

Sterling chip Camden
Sterling chip Camden

You really need to have someone wearing that hat, even if they're also wearing another one. Designers too often mock something up without considering all use cases. Programmers often consider only the use cases that they have to code for (or around). Users often consider only the use cases that apply to them personally.

jazzygodfrey
jazzygodfrey

"what do you need out of this?" these kind of questions will help you understand their needs well and will not give room for conflicts

Sterling chip Camden
Sterling chip Camden

Presentation should always be separated from business logic, definitely. The problem occurs when programmers assume that they've done a good enough job of that, then when the UI design changes they find all of the assumptions about presentation that they built into their logic.

Tony Hopkinson
Tony Hopkinson

He is as well, doesn't like people messing with his standard at all... Like most programmers who do UI, I love standards, ten slightly different versions of edit box, is major PIA. If you end up there I guarantee the people who put you in that position will want you to change them all at some point. It's a rule.

Tony Hopkinson
Tony Hopkinson

new , and even less opportunity to pick how, this was a sort of side project POC, to come up with some numbers for a huge project though. So I gave it a go. Project hasn't got off the ground, but the fresh viewpoint gave rise to some powerful ways of looking at the legacy mess, some we've now ploughed back in and we have plans for more. As you say just enforcing separation of concerns is useful, but teasing out some cohesive functions from the legacy code, and then being able to prove them (with a bit of jiggery pokery) with no impact on the live code base, has opened up some interesting opportunities. GUI centric designs have an awful tilt towards monolithicism. There's natural tendency to keep following the pattern, even though page one, chapter one of any programming book should don't f'ing do this. Start from a CLI though and you tend towards modularity, valuable just for that.

Sterling chip Camden
Sterling chip Camden

... is a great idea, not only for its enforced separation of concerns, but also for unit testing (and even for usability for geeks like me who hate the mouse!)

Tony Hopkinson
Tony Hopkinson

There will always be some, the trick is to always keep the separation, or at least get it back if it's a rush job. Once you lose it for more than a version, getting it back is a really hard sell. So when you find yourself putting that first ( OK twentieth ! :( ) if statement in a UI event handler to do a bit of extra logic, because you didn't want to persist it and couple up through the controller... A slippery slope, very slippery. One of the things I run into regfularly is when designs are UI centric, is the number of assumptions that they can effectively force on you. You start thinking about it from the point of view of the options the UI control has, instead of the functionality you need. Really easy trap to fall into. When I can with new stuff, I've been starting with a noddy POC UI that simply exercises the other layers, better still a command line capable one, (al la 'nix) If you start like that and incrementally add features, refactoring as required you end up with loosely coupled flexible deisgn. Start from the GUI form or web page, and your implentaton options can narrow down into about one and chock full of assumptions. Version two comes along and you tell the boss rewrite and look like a muppet, or throw separation of concerns in the bin and be a muppet.