I’m sure it doesn't come as a surprise that developers and designers don't always get along. They don't always talk the same talk, or walk the same walk. Perhaps you've been privy to or even a part of the conversations below?
A Developer's Day:
Designer: "I want this to fly in from the left and there should be a gallery of rotating pictures here. I have some RSS feeds that I would like to appear on the page here, which the user should be able to filter by keyword. Oh, and here are three responsive layouts that should appear labeled according to resolution."
Developer: "Okay, when do you need this by?"
Developer: "Um... it's Wednesday. How about next Friday since I have to squeeze it between some other projects?"
Designer: "I really need it this Friday. It's just a web page. You make those all the time."
Developer: "I'm sticking with next Friday."
Designer: "I'm calling the president."
A Designer's Day:
Designer: "Say, how is that page coming along?"
Developer: "Well, we're close, but first I need (insert phrase in Greek here) and then (long strings of letters with no meaning at all). After that, I just need (this part sounded more like Latin, perhaps Sanskrit) from you and we'll be done. Here's a mockup."
Designer: "Um... it's a white page with a buttload* of text on it."
Developer: "So? The info is all there."
Designer: "I don't even know how to talk to you."
~ ~ ~ ~ ~ ~ ~ ~ ~
Ah, the pleasures of developer and designer interactions. It may be “IT and marketing” or some other dividing line where you are. It doesn't matter what side of the fence you park your lawn chair on, most of us have had similar dealings. I know that many have skills in both areas, but the opposing team tends to define this as, "just enough to be dangerous."
Personally, I used to be strictly on the IT/developer side of things. People updated their own sites and marketing had one guy who would help people copy their info into OmniUpdate’s OU Campus™ web content management system... usually from a page previously done in FrontPage. I made sure the server was running, but content was for someone else. Then “someone else” left and there was just one new team member (marketing, ugh) and me who were scrambling to make an upcoming website redesign happen. All of a sudden, our yard sale of a site became important—as it should have been years ago—and both coding and design skills were lacking. As a result, I was elected to go to the OmniUpdate User Training Conference (OUTC14) this year (I will sing the praises of attending the conference in a future post) even though we’ve been running OU Campus for six years.
To prime myself, I threw myself into CSS, HTML, a smidgen of XSL, and I even read the torturous (for me, at least) Design for Hackers by David Kadavy. OUTC14 was fantastic; I honed my coding skills and learned a lot about design. The point of all this? I acquired the odd ability to see things from both sides of the fence. More importantly, I learned that developers and designers need to learn to play nice together.
One of the things stressed at the conference was the need for communication. When I got back, I arranged a weekly meeting (sometimes we meet more often) between our departments. Okay, “departments” for me means me and one other guy, but you get the idea. Shockingly, we quickly gained a better understanding of each other's needs and also learned each other's limitations. Heck, it was even good to hear each other gripe about the demands that are placed on us. Those demands come straight from the users and can be a great source for what areas need to be developed or added. You will also pick up skills from each other so that someday your departments may regard each other as “less than dangerous” or perhaps even “nigh-adequate.”
Another thing open lines of communication does is establish a common language. All too often, techies speak in acronyms and jargon. Much of what they are trying to say gets lost in that moment when a user's eyes glaze over. Developers will learn to put things in layman's terms when they regularly have to communicate them to someone other than a fellow developer. I can vouch for that, as I've been taught the trick myself. Granted, there will be some terms that designers will need to learn, but it is advisable for developers to learn to put things in clearer terms—particularly for faculty. Designers will also benefit by learning to express concepts more concretely. While designers understand that good design means more than making a site pretty, it's not always easy for them to express the whys and hows. Not only is it good to get developers to understand the concepts, it will help designers better promote site changes to faculty and administration in the future.
You can also show each other areas of OU Campus that can be better used by both parties. In the past, our designers entered much of the content for the users. By meeting, they learned about the approval process and can now save themselves hours per week. It's a whole lot faster to approve a page than it is to create and enter data for someone else. They also now know where the files are that make OU Campus tick and it’s removed some of the burden from the development side, since they can edit files on their own if they want to test something out like new CSS.
There will be days where all you do as a team is troubleshoot issues that are on the website. Many of them are things that were expressed to the wrong person. We've solved a few issues together where our server needed a configuration change and the designers simply didn't have the access or the knowledge of how to correct it. Prior to our regular meeting, issues like this were much slower to resolve and usually came from administration after someone got irritated enough to complain.
We’ve only been having our meetings for a short while, but we’ve already seen vast improvements in how quickly problems get resolved and how quickly design changes occur. Marketing now knows more about the structure of OU Campus and IT knows they have picked up the skills to make changes on their own. Our working environment has turned from one of launching volleys of requests at each other to one of collaboration, and things are moving along much more smoothly now.
*A buttload is 126 U.S. gallons in case you were wondering. That's a lot of text once you squeeze all those letters in there.
About the Blogger
Jim Heiney is the web/exchange administrator for Lock Haven University (LHU). He’s been at LHU for more than 15 years and is still amazed at how much more there is to learn (and he willingly accepts that fact) for those who work with technology. His philosophy of “never stop learning” has led him from English teacher to IT guy with a few other odd stops along the way. When not at work, he can usually be found at home with his family. In his spare time, he can be found writing, drawing, or playing the occasional computer game.