The short answer is both. While the front-end graphic designer is busy with design, layout, typography, image research and such, the back-end web designer (let’s call them a coder) is busy setting up the server, databases, installing software, writing various custom code and the likes.
The trick is to keep the communications open so the left hand knows what the right is doing and vice versa. When the communication fails, problems rear their ugly heads and they do it fairly quick.
The typical process involves an information-gathering meeting with the client, the graphic designer and the coder who may or may not also be a programmer. Depending upon the nature of the client company and web needs, this meeting might also involve several others, such as a writer, marketing and/or public relations person, photographer, etc. A slew of questions are asked (or should be), everybody shakes hands and goes off on their merry way. If you’re really lucky, the client will have prepared a project brief that addresses all the important points about goals, target audience, competition, desired site features, budget, etc.
Next up is the development of a proposal/project brief, which, if all goes well, will be gleefully accepted by the client and money will exchange hands. Ideally, that means the client’s money going into the designers’ hands.
Some graphic designers also write code and some coders are also quite familiar with design and layout, typography and other front-end aesthetics elements. So, clearly defining responsibilities is pretty darn important. You don’t want to be tripping over each other’s work in the thick of things.
The graphic designer begins to design, based on the information gathered at the initial client meeting. What happens next can be where the challenges begin and I’ve had this happen a few times when I was the back-end guy building the site. I’ve mostly been the front-end, so I know, all too intimately, both sides of this equation. It’s critically important to keep the coder in the loop before the client sees anything. It’s the kiss of death to get an approval from the client only to have the coder say, “Um … yeah … that’s not going to work.”
Let me close in a bit tighter with the subject of the headline – in my experience, the graphic design comes first. It’s kind of tough to code pages when you don’t have a clue as to what goes where, what fonts are to be used, color, etc.
Another problem comes in when the front-end graphic designer doesn’t really know a lot about what happens under the hood of a site. My word of advice? Have a show and tell session with your coder. Have lots of them. The thing is, what works in print doesn’t always work in a browser.
With as brochure, ad, billboard, etc, when a designer puts something somewhere, it stays there. That is, of course, providing the production person at the printer, magazine, etc. doesn’t start getting “creative.” Okay, I’m going to take some heat for that remark. The designer has a color swatch book and can have a relatively good idea of what’s going to come off the delivery end of a printing press. Various forms of color hard proofs exist, as well as dyluxes and all that stuff. Johannes Gutenberg would be a proud man. Unfortunately, he can’t be proud because he’s been of the dead persuasion since 1468.
Enter the flexible, fluid world of the web. It’s a dodgy place where, just when you think you have a handle on things, they change the rules. That can make my life a living Hell at times. Hell, by the way, should be capitalized. It’s a proper noun when used in this context. Depending upon your point-of-view, religious affiliations and scare factor, Hell is apparently a place, as well. But alas, I digress.
When a graphic designer starts into designing it’s always a good idea to develop a wireframe (a stripped down, graphics-free version of the design) send progress pdfs or printouts over to the back-end person. Screen sharing is pretty handy, as well. They can [hopefully] tell you if your ideas and brilliant designs are actually produce-able.
A front-end designer might work on a Mac and the coder is using a Windows PC. Colors render darker on a PC, so while our front-end person is seeing a lovely palette of delicate colors (if they haven’t changed the default gamma), what the coder is seeing is quite different. The former might use Safari as their primary browser and the latter uses IE. Again, there may be differences. The point is, address usability and function early on. Test, test and test some more. There can be times when one needs to make a design sacrifice or two in the name of usability.
And here’s the thing. We have these wonderful ideas in our heads. Ideas, concepts and layouts that are utterly crystal clear and makes perfect sense to us. But, what often happens in human communication, is that what’s utterly clear to us is total mud to someone else.
After working as a team on a few sites, communication tends to become more intuitive. You develop a comfortable process that works for both of you. And that’s when it’s time to put away the antacid.