Sometimes I think designers and programmers couldn't be more opposite. At Agency Fusion our success depends on bringing these two worlds together but it sometimes feels like we're trying to mix oil and water.
More than likely you've already had an experience dealing with an IT-type person that left you feeling a little frustrated.
Here are a few insights into the mind of the programmer, network admin, or other IT person. Hopefully this might help you the next time you find yourself wondering how to communicate with the IT species.
1. It doesn't make any sense to me.
IT people live in a world of logic and order. As a creative you thrive on thinking outside the box; everything's fluid, flexible, and your mind is trained to accept new and unconventional ideas and approaches to things.
For IT people, and especially for programmers, everything is about consistency, methodology, rules, and conventions. Creativity still plays a huge role for great programmers, but it's a different kind of creativity. More like creating a new mathematical formula than like creating a new logo.
When trying to persuade or convince an IT person, try to start with your objective (what you want to accomplish) and then present an argument that is as logical and formulaic as possible. Probably the least effective argument you can make (although not invalid) will be to say something like, "I want to do this because it will look really cool."
2. It's my problem when you're done.
If you were hired to redesign a company's website, it was probably the person in charge of marketing that engaged you. Your new client's IT staff is probably going to get involved at some point during the project and you may feel some initial resistance from them.
One of the main reasons they'll push back is that after you deliver the shiny new website and move on to another project, they're the ones left to maintain it.
There are a few helpful steps you can take in this situation.
- Ask for their input even if you're convinced they aren't going to add value. They'll feel better knowing you're including them and may provide some insights no one else has considered.
- Earn points by showing interest in their world. Programming and networking may seem like fodder for a yawn but they love it and will accept you more readily if you seem somewhat interested. Ask a few genuine questions or mention a Wired article you've recently read.
- Build their website with a Content Management System (CMS) which can help by making it possible for the marketing department to make changes directly, rather than bugging the IT department for small text changes.
3. It works, doesn't that count for anything?
One of the worst things a developer faces is the "unveiling" of a particularly difficult project only to have those who're looking on respond with disappointment in how the project looks. You know…the whole "judging a book by its cover" thing? A developer may spend hundreds of hours on a complicated project and be so proud that it does some amazing thing but be utterly deflated when no one appreciates the effort.
If a developer ever wants to show you something "really cool" just play along and act excited even if the thing looks like crap. He or she is more passionate about making it work or proving it can be done than the style in which it's done.
There'll be time later to discuss the appearance of the thing. Throw out some genuine compliments first to stroke the ego and then talk about improving it later.
4. I know it seems simple, but it was really hard to program.
Somewhat related to the previous point, developers are often tasked with doing complicated things that appear simple when finished. Just because something is easy to use doesn't mean it is easy to build. As a developer it's frustrating to hear a designer say, "It's really simple…you just type in the data and it creates a report." True, it's not as hard as building a nuclear reactor, but it will take more time and is more complicated the final result might indicate.
The level of unappreciated complexity increases exponentially when the extras are added in, such as validating data entry, handling system errors gracefully, drag-and-drop style functionality, etc.
5. It's a nice picture, but it doesn't do anything.
As a final thought to help give you some perspective on working with IT people, it might help to realize that for some IT folks you are just as much an enigma. Just as you might not understand the programmer's passion for writing code, some programmers might not see what's so great about creating graphics. Code might not be visually stimulating, but graphics can't make data move between systems.
Both disciplines and passions are critical in any successful technology endeavor so I think the goal should be to learn "how the other half lives" to increase the likelihood of a successful partnership.
What do you think? How can designers and developers better relate to one another? Do you have any insights into working with IT people?