Yitzchak Schaffer wrote: > After reading this article, I'm left wondering: what are the basics of > working with designers? I wasn't even familiar with the term "comp" > that's being used in the post and comments. Where can one learn the > fundamental assumed communication patterns, role & workflow > expectations, etc. that go along with this relationship? What is a > developer meant to do after being handed a PSD?
As someone who has worked (and continues to work) on both sides of the fence I think I might be able to give you a few insights. Most of what I'm about to say relates to professionally (though not necessarily formally) trained graphic designers who offer web design services, either as independent freelancers or as members of small design firms. Before I get started: If your designer can't or won't provide a signed written agreement that clearly spells out project scope, deliverables & dates, then run away. Fast. Workflow & Terminology 1. Discovery & Planning - This usually involves giving the client a questionnaire (it may also referred to as a creative brief, creative needs analysis, design brief, etc.) It covers things like existing branding (if any), target audience, goals, expectations, look & feel, and so on. Where web sites are concerned, there may also be a "technical needs analysis" or "technical brief" (in the form of a separate section or questionnaire) that covers questions about functionality, types of media that may need to be displayed, etc. 2. Design - Brainstorming to come up with concepts (sometimes also referred to as "concepting"). The client will usually be presented with 2-3 comps (also known as roughs or mock-ups) representing what the designer considers their best concepts. The client will then be asked which design s/he prefers, and the designer will go through a couple more revisions--sometimes incorporating elements from different comps--before the design is finalized. Note: To avoid scope creep, experienced designers will specify in their contract how many rounds of revisions will be allowed, and will require sign-off on each round. 3. Production - Here's where it gets tricky. Make NO assumptions about who is going to be doing the coding. If the designer is going to be providing the HTML, then find out whether that means that the designer will actually be doing the coding, or if it's going to be outsourced (to understand why this is critically important, see Type I, below). Type I - These are the web designers who know little or nothing about coding and have no desire to learn. This is not a problem if you know for a fact that the designer outsources to a skilled, trusted coder. If you don't know and/or don't ask, then don't be surprised when you're handed HTML pages created by a Photoshop plug-in like SiteGrinder, or when you find that your coding has been outsourced to some less than reputable 3rd party online rent-a-coder outfit that has produced hopelessly buggy pages and then vanished into the night. *shudder* Type II - These are the web designers who have basic coding skills. Use caution with these designers as they often know just enough to be dangerous. They haven't mastered things like modern best practices, browser bugs, accessibility issues, semantic markup as it relates to the separation content & presentation, etc. They tend to panic when they run into things like cross-browser compatibility issues or the need for advanced CSS techniques. I know this because I have pulled the backside of more than one of them out of the fire when a deadline was looming. Type III - These are the web designers who are knowledgeable about most things code-related. Anything they don't know they will seek an answer for quickly and efficiently, and they won't over-promise. They are well versed in the areas where Type II is lacking and, if asked, can produce a portfolio & references to prove it. They have the experience to know when certain design elements might prove problematic, and they know how to keep a project on track and within scope. These designers are in the minority, but they're out there. Type IV - These are the web designers who have have all the skills of Type III, and also some degree of developer & back-end knowledge. These designers are few and far between. They know that they're worth their weight in gold and will charge accordingly. Communication This is the single biggest hurdle in any field, IMO. Graphic design, whether for the web or print, is by its very nature a highly collaborative process. A good designer should be able to communicate effectively both visually AND verbally. If the client proposes something that the designer feels will negatively impact a design, then the designer should be able to explain why in terms the client can understand. That being said, it's also incumbent upon the client to provide timely, useful feedback. I'm sure you have all experienced how difficult that can be to obtain at times. Lack of feedback not only slows down the design process, but it can also quickly dampen the designer's enthusiasm for a project, resulting in reduced creativity. Last but not least, designers & developers need to respect each other's professional expertise. I've met designers who are contemptuous of coders & developers, seeing them as little more ill-tempered, geeky "code monkeys" whose sole sense of taste lies in their mouths. Likewise, I've met coders & developers who view designers as spoiled, temperamental artistic types who deal in "make it pretty" fluff that lacks any real importance. Sometimes both are true, but most of the time not. Good design, like good web development, comes from years of hard-won experience and dedication to craft. Sorry for rambling on so long, but I don't often find a thread here that I can contribute much to, so I got a bit carried away. I hope nothing I've said comes across as preachy, and that some of you find it useful. Bev _______________________________________________ New York PHP User Group Community Talk Mailing List http://lists.nyphp.org/mailman/listinfo/talk http://www.nyphp.org/show_participation.php
