Designers and Developers: Why Can’t We Get Along?
Test and Monitor | Posted August 08, 2012

In which a Web developer and graphic designer do their best to achieve world peace.

As long as there have been visual programs, programmers and designers have butted heads. The differences between the two sides of program development seem to often be at odds, even though we all know both team members are important to creating effective applications. Designers fume at seeing their designs implemented different from how they were originally laid out. Programmers gripe that designers nitpick over silly design issues.

Many conflicts are based on a lack of understanding of the other party, and we felt that this was the case with the designer/programmer schism. In the name of peace between the right- and left-brained, we (a programmer and a designer) present this list of lessons.

Designers say: We're not trying to be difficult

We're trying to do a good job. We're not trying to be difficult. Designers have a reputation among some developers of being high-maintenance. You think we prefer form to function, which isn't true at all. Designers are trying to come up with the form that best suits the function so that the function can be used to its utmost.

More and more designers are being tasked with being user-experience (UX) designers rather than graphic designers. It's important for a designer to understand what we are asking the user to do before we design for that need. Sometimes we try to add some nice graphics surrounding that experience, but only because we want the user’s experience to be a pleasant one.

Programmers say: We're not trying to be difficult

When we write code, the project’s completion is only part of what's on our minds. Apps change over time, and we work to make sure that those changes are easy to make. We need the code to be easily tested in our automated test framework. When we ask for changes in the work products we get from you, whether it's HTML formatting, file naming, or directory structuring, it's all with the goal of keeping things testable and flexible for the future.

Don't worry, we're not asking for these conventions in the name of endless flexibility. Building-in flexibility can be expensive, and we have a term for overbuilding for the future: "YAGNI," which stands for "You Ain't Gonna Need It." We try to avoid this.

Designers say: Questions of form can influence function

Form doesn't have to follow function. The form can also inform the function. You can design something to get a desired result that a programmer can make happen. If we want the user to click on a certain button or to perform a certain action, the graphics and layout can help a user know, or properly guess, how to get his desired result.

Much of our experience informs our decision to design something a certain way and that is especially true for online applications. When designing even the simplest things, such as buttons, form fields or photo selection, we use informed decision methods while making a choice. Placement, color, and visual cues tell a designer how someone will interact, but creating the environment for this interaction is where we get to "play."

A good example of this is in the navigation of some of the premier brands in the world. This screenshot of Porsche's tiered navigation show that a clean and well-structured design can make the function for a user very pleasant.


Programmers say: Naming matters

When we're constructing an application we have many different components to keep track of. In addition to your pages and graphics, we have source code files, database tables and columns, and many other components to manage. Consistent naming is the first step in keeping everything straight.

When a designer is dragging and dropping graphics in a file system GUI, it may not make a difference if the file is called submitButton.gif or submit-button.gif, but it makes a difference to us programmers. We have naming standards for pretty much everything from database fields to filenames to CSS classes. These may be spelled out in departmental coding standards or they just may be unwritten rules we follow, but having consistent names makes things easier to find.

We aim to make names descriptive and predictable. Naming similar objects distinctly is an important part of naming. The names submit1.gif and submit2.gif don't explain the difference between those two image files, but submit-green.gif and submit-red.gif do.

Designers say: Help us to understand

We can learn the rules, just help us understand them. The rules are what we can or cannot do. Developers sometimes talk to us in a language we don't understand, just as designers sometimes speak to developers in a language they don't understand. Once a designer and developer find understanding, the person that benefits the most is the user. Everybody wins (and we have more fun at the launch party).

To use the example of file naming above, just tell us upfront what the standards are so we can follow them. I guarantee you that if we know right away that we need to group images in a certain way or to name files with only lowercase letters we will happily do that as we work. Designers aren't confrontational by nature. Much of the time we are very much like programmers: we like to do what we do without someone telling us how to do it.

We designers have been trained not to follow the rules but to "think outside the box," and that doesn't necessarily mean it has to make the developer's life difficult. Once a designer understands the rules, she can push the envelope and get outside of the rules without making the functionality more difficult. Graphics can augment the functionality if done correctly.

Once we are aware of limitations of a platform or framework, such as WordPress, we can create a design knowing the places where it makes sense to push the envelope (background graphics, patterns and colors) and the places we shouldn't (navigation, embedded rare fonts and graphical navigation). Finding a unique or clever way to solve design problems gives designers the satisfaction of a job well done.

Programmers say: What works on your desktop may not work on the Web

Creating beautiful Web pages on your desktop is only the start. It has to look good when pushed to a Web server.

Distinctions between upper- and lower-case filenames may not matter on your Windows desktop, but when published on a Linux Web server, greenbutton.gif and GreenButton.gif are not the same, and the user, or at least the programmer and tester, will get 404s. I prefer to use all lower-case filenames when possible and I make distinctions between words with hyphens.

Validate all your links to assets and documents to make sure that what works on your desktop works when deployed. Whenever I get a Web page with broken images, or CSS file that doesn't load, chances are there's an incorrect link to the designer's hard drive that looks like this:

<img src="file:///c/Users/designer/assets/green-button.gif">

Remember also that a huge file's load time may not be noticeable when you look at the image in a browser loading from your desktop, but if that beautiful, full-color vista you use as a banner is a megabyte in size your page is going to load slowly when it has to be pulled across the wire. There are many browser plug-ins that calculate page weight, please use them.

Designers say: Graphics are only a support mechanism

Designers understand that graphics are the support mechanism, not the most important element in the application. Graphics should only be used when needed and not to dress things up unnecessarily. If your information needs to be dressed up it's probably not compelling in the first place, so why bother?

First of all, that isn't always true. Yes, some designers feel, at least occasionally, that what they do is the most important thing and everything else is secondary to their "art." These people are more "artists" than "designers." Designers create for users or viewers, not for themselves. When a designer works with a programmer or programmers, she wants to be part of a team that is creating for the end-user, to perform a task or to get something the user wants to obtain. It's a distinction that allows a designer to take the ego out of her work and concentrate on producing a quality experience.

That's the same thing the programmer wants. And programmers are not immune to ego, either.

Programmers say: Live the principle of DRY: Don't Repeat Yourself

The single biggest factor in a system’s maintainability is how little repetition there is. We don't write code to calculate sales tax in the five places that we need that calculation. We write the code in one place, a function called calculate_sales_tax(), and we use that five times. If the code has to be changed, we change it in one function rather then individual places. That saves time, and it means that we can't accidentally only change the sales tax process in four places.

CSS is the biggest example of DRY in the designer's world. Before CSS, all display markup had be specified in HTML like so:

<p><font face="Arial" size="+1"><b>This is a headline</b></font></p>

Now, of course, with CSS styles are specified like:

<p class="headline">This is a headline</p>

And the markup is in one place in a CSS file. If you use CSS, you're following the DRY principle.

Designers can help us programmers reduce complexity by exercising DRY in everything they do. If you have an image that is to be used on two different pages, put it in a common directory that each page can refer to.

Templating systems are another excellent way to reduce repetition. Did you have to go and change the copyright date in the footer of every page on the site on January 2 last year? If you'd been using a template system and your pages ended with something like ...

<!include footer.html>

... then you would have had to change footer.html, and you'd be done.

Designers say: Alignment and spacing really do matter

Alignment and spacing are important. It's all too common that we run into problems with a strict developer where we give him a design and it gets built with the alignment and spacing ignored. It's allowed to go to the default layout. Eeek.

The reason we use alignment and spacing is to ensure that the end-user has an easy time of performing the function you want them to perform. Without stylistic conventions, the user won't necessarily stay around for whatever functionality you've come up with. She can get lost in the crammed area of whatever you're trying to put in there and won’t know what to do. Using alignment for directing a user is one of the best ways to get them what you want them to do.

Make the process easy visually. If a user can find what he is looking for, accomplish the task that brought him to your website, or learn what he can do on your website quickly and intuitively, you have succeeded. If a user is forced to read instructions or interact with the site to figure it out – well, then you have work to do.

          Yahoo's member homepage  

Two examples come to mind. Compare Yahoo's member homepage (above) with or

          MailChimp's design organizes whitespace and alignment, making it easy to scan and decide what you want to learn more about  

One is overwhelming in scope, the other two are organized with whitespace and alignment, making it easy to scan and decide what you want to learn more about. Obviously, both sites service different types of audiences, but you can tell and cater to design-sensitive users who don’t wish to be overwhelmed by an avalanche of information.

Programmers say: Learn to use version control systems

In modern software development, a version control system (VCS), such as git or subversion, is a must. No qualified programmer would work without one, and neither should you. A VCS has two major benefits for the designer: change management and history tracking.

Have you ever played the game where you have to run around to your co-workers and say "Don't touch contact.html, I'm making changes to it." If you don't let everyone know, you and someone else might both make changes to the file, and then whose version do you keep? VCSs take care of that by keeping track of the files stored in it as well as the changes made. When you commit your new version of contact.html to the repository, only the changes are stored. When your co-workers update from the repository, your changes show up in their files. Best of all, if two people make changes to contact.html, both of their changes are combined automatically.

The second huge win of a VCS is that you have a history of all the changes that were made, who made them, and when. Did something break on the website between last Tuesday and this morning? The VCS can create a list of all the changes since last Tuesday. You can check out the state of the entire project from a given point in time to compare how things worked then compared to now.

Some designers make copies of their work in specially named directories, such as "Anderson Project 2012-07-13 snapshot," so that they can go back to a known good state of the project in case of emergencies. A VCS does that for you and more. If you're not yet using a VCS for your projects, ask your programmers about which one they use and to request that they show you the ropes.


There is, of course, much more that designers and programmers can learn from each other. We hope that whichever you are, you'll ponder the life from the side of the project. As we said, neither side is trying to be a pain. We both have quality issues we work with, and we just want the best for the project.

Try taking your project counterpart to lunch some time. Trade war stories about hard-to-find memory allocation bugs or the perils of writing CSS for Internet Explorer. You might find that you learn something from one another and that your project team will be stronger because of it.

About the authors:

Andy Lester has been developing business software for 25 years, back when "interface design" meant drawing arrows with asterisks to show the user which disk drive to put the floppy in.  He works extensively in open source and is the creator of the ack code search tool and many Perl modules.  He also wrote Land the Tech Job You Love, published by Pragmatic Bookshelf, and blogs about technology and work life.

Lauren Grey has been a designer for more than 15 years and started learning about HTML and code because she thought it would be important to know. Since hand-coding her first websites, she's learned how to balance design and programming in a number of different work environments. Currently working on an in-house creative team and constantly growing the skill set necessary to understand a tiny bit of what Andy is talking about all the time, you can see her work at

See also: