Developers versus designers is a struggle that has gone on for as long as there have been computers. The bickering has been around for ages, stifling productivity, and causing more agony and hair loss than the most obscure bug ever will.
I overemphasized the struggle a bit, but there is often a fair amount of resentment between developers and designers. This does not apply to all cases, but it does apply to some.
In order to understand the struggle I’m describing, it’s helpful to look at how developers and designers differ. The web industry evolves quickly; new standards come and go in the blink of an eye, and new approaches to developing web sites pop up quicker than you can say “Peter Piper picked a peck of pickled peppers.” As the technologies that enable web development evolve, the responsibilities of the people involved have evolved as well.
Designers are people who — like developers — have their own interesting personalities and opinions. They often see the world differently than the rest of us — a quality that helps them create great web sites. Whenever we work with designers, it’s important to not generalize, realizing they come in as many shapes and sizes as the rest of us. Thus, we need to have different expectations and approaches for each designer that we collaborate with. This is something managers often neglect when choosing a design company, and this can leave developers with wildly inaccurate expectations about the work they will receive from the designers.
A trend that I’ve noticed over the past couple of years — especially after the economy crashed — is that many traditional design firms have decided to expand into web design. This poses a problem, because these design firms think the same approach to design will apply directly to web design. This just doesn’t cut it, as anyone in the industry can tell you. The implication is that developers are expected to do all of the heavy lifting.
All developers will — at one point or another — dabble with HTML and CSS. A good visual aesthetic, however, is not typically a developer’s passion. In most cases, developers will only learn enough to properly represent the data they are working with. In fact, it’s usually easy to tell when web sites have been designed by developers.
“Necessity, who is the mother of invention.”
For some people, necessity turns into passion. Developers can become obsessed with knowing the ins and outs of browsers. They learn HTML and CSS as well as — if not better than — a good web designer. It becomes a labor of love. Not all developers will put themselves through this process; some prefer to become expert in backend technologies. From my point of view, this is a great place to focus my OCD.
Clash of the Titans
In my opinion, the struggle is usually a result of the gray area — the part of the work for which neither designers nor developers will want to take responsibility. One of the most common sources of conflict is arrogance. When a designer delivers markup, CSS, and other materials, a developer with related skills might question the work of the designer. This can lead to arguments.
A possible cause of this scenario is traditional design companies that move to the Web without hiring web designers, or taking the time to learn how the Web works. In these cases, developers are likely to have more knowledge and can tactlessly point out various things that can be improved, breeding arrogance.
There are many potential sources of confusion, and many types of power struggles that can occur during the course of development. In order to find a remedy, we must first question whether designer is sometimes being used in the wrong context. I’ve just been writing about developers and designers, but there is actually a third group of people — a group that lives in the gray area.
Front-end engineers have been around as long as we’ve been developing web sites. A front-end engineer is someone who will take a design and implement it on the Web. They’re also usually the ones with the most knowledge of web standards and how various browsers will implement each of those standards.
Nate Koechley of the YUI team gave a great presentation in March 2009 about front-end engineering and how it has evolved:
“The intersection of design and development was unknown — different teams worked in different ways, and the people tying the front-end and the back-end together were using vague and undefined processes. I think today we’ve seen the emergence of front-end engineering as really the true intersection of where these things come together.”
It’s only in recent years that front-end engineers have started to separate themselves from the other roles, becoming some of the most important people in the web industry. It is noteworthy that not all companies will have the budget to have dedicated front-end engineers, which is why we still see designers and developers that have assumed the extra responsibilities that a front-end engineer would normally handle.
Front-end engineers are those who have truly created Web 2.0. They are the Mavericks of today, constantly pushing the limits, attempting stunts that would make the rest of us cringe.
How can we eliminate the struggle altogether? I’m glad you asked!
First, the bad news. We can’t. There will always be a struggle, be it between developers and designers, designers and front-end engineers, or developers and front-end engineers. That’s just how the game works, but with the right approach and planning, we can minimize conflict.
There are a few simple guidelines that help. This is really a bottomless list, and I am sure others will have their own ideas. (Please share.) There is no silver bullet.
The first guideline is to collaborate with your managers to define the specifications and requirements for the design. I think this small cartoon explains quite clearly why an internal workshop session has to happen before anyone outside the company is contacted. Make sure the project’s schedule is clear. There is nothing more horrifying than getting the design too late, because of miscommunication or confusion.
After creating the specification, the next step is to find a company or send out a request for proposals. In either case, potential candidates should be researched very well. Examine their portfolio, quality of work, markup, and anything else you think is important. Don’t let your managers convince you to take the cheapest proposal if it’s not the best. Be stubborn about the most important points, and only compromise when necessary.
Ensure that there is a good platform for communication, where people can post questions, concerns, follow-ups, and the like. This can be a wiki, mailing list, Basecamp, or any other platform that meets your needs. The most important factor is that the people who need to communicate about issues can do so, but others — who might otherwise be mere observers — can also participate.
Set up a workshop where the designers, developers, and other stakeholders are all sitting together in a room, discussing the upcoming project, where people can freely talk about how they envision the design, implementation, and communication. Take as long as you need to complete this meeting. This process is important to refine ideas and get a better understanding of the of the project, and it’s also a good time for everyone involved to get to know each other. People are more inclined to trust and understand one another if they have met in person.
Ask the designers to provide you with wireframes as soon as possible. This is an absolute must. Wireframes will allow you to see if the designer understands what you want. When you have the wireframes, you can discuss them with your management, and the design concept can be tweaked before any visual design work is done. This step allows you to catch any misunderstandings before they jeopardize the entire project.
Ask the designers to provide frequent updates in a format that allows everyone to see progress. Ideally, the updates will include high-fidelity wireframes, which are basically a fully implemented design with dummy data.
Change requests should be discussed within your team before being voiced to the designers. There is almost nothing more unprofessional than an argument between co-workers in front of external designers. Keep the initial discussion internal, and get everyone to agree on the new approach before presenting it.
There comes a point when the design has been implemented and is being used in production, but further changes are required. Making the designers and front-end engineers use dummy data to implement markup will only get you so far. If possible, give the designers access to the actual app, with real data and content, and allow them to play around with it, so they can better understand the experience. Some people give the designers access to their source code repository, but I usually ask them to provide me with simple diffs or even the output from FireDiff, a Firefox addon that integrates nicely into Firebug.
Does this whole process sound familiar? That’s because it is! This is how a normal development project is run. Applying the same process to the design part of the project is a good solution that’s worked well for me.
The interaction between designers and developers is all about compromises, communication, and understanding. With the right planning and attitude, things can go better than expected, but “the best laid plans of mice and men often go astray,” so you had better be prepared for problems along the way. A good contingency plan will help.
I would like to emphasize that this article is influenced by the fact that I’m a developer that has worked with many designers over the years. I’ve had a myriad of different experiences working with them, some good, and some bad. I’ve also observed many interactions between other developers and designers.
Think about how you can alter your processes to better communicate your requirements and comments. Try to find a common ground to keep everyone happy, productive, and a little bit saner. Build up an atmosphere that focuses on mutual respect.
Hopefully I have given you something to ponder while on Christmas holiday.