NYCPHP Meetup

[lists at nopersonal.info]

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