Advertisement

Developing a website, even a small one, can easily turn into a daunting task without some sort of documented process in place. There are those sites that require little more than a designer sitting in front of their monitor tapping out some html and css. Other sites can involve an army of team members from graphic designers to coders, photographers to writers and a host of others in between. What they share, or at least should, is a process for getting things done in a sensible and methodical manner.

This article will focus on the relationship of the front-end graphic designer and the somewhat back-end website designer, who I’ll refer to as the coder. The former is typically responsible for the site’s aesthetics (think, look, feel, fonts, colors, layout, etc.), while the latter is responsible for making it all work in a browser. Well, hopefully several browsers, computer platforms and various configurations.

Also, this article tends to address a front-end designer who works mostly in print, but also does some web design. The trend today is designing in-browser, which is a topic for another article. Suffice to say, some of what you’ll read is “old school,” but for many graphic designers, it’s the process that works for them and is comfortable.

At this point, some definitions are in order. What exactly is a “process?” Our knowledgeable friends over at Dictionary.com provides us with the following:

A systematic series of actions directed to some end.

A continuous action, operation, or series of changes taking place in a definite manner.

Those should work.

Ideally, this systematic series of actions will be documented in writing, so all the folks involved know what’s going on, what needs to happen, when it needs to happen and who is responsible for making it happen. Without clear documentation, a project can easily erode into chaos, usually involving questions, comments and thoughts such as, “I thought you were going to take care of that.” “Oh, sorry. I thought you meant …,” and the worst offender, “This isn’t at all what we asked for and we’re not going to pay for it.”

Ouch!

In the immortal words of Glinda, the Good Witch of the North, “It’s always best to start at the beginning.” That means an information-gathering meeting with the client, graphic designer and site designer(coder). Depending upon the nature and scope of the site, this initial meeting can also involve several client representatives, various creatives such as a writer, photographer, programmers, etc. The idea is to bring all the key players together to define what you’re trying to accomplish. Getting this right at the start will go a long way toward avoiding major headaches later. And, by that, I mean needing an aspirin the size of Manhattan.

The information-gathering meeting is the predecessor to the proposal, in most cases. You’ll define the audience, competition, goals, site features, schedule and such. You’ll also want to discuss the project budget. This is the part where the front-end ideals meet the back-end realities. For example, when the client says they want thus and so, a searchable database for this and that, a content management system (CMS), several forms and a load of other features … oh, and they have a buck and a quarter to spend, the red flag goes up. It’s much better to address these issues now, rather than later when a site is almost done … and utterly wrong.

The graphic designer, who likely works mostly in print, may not be aware of the time and costs involved with what a client requests. All those oddball acronyms can get pretty confusing, too. “Well, the CMS is based in PHP and the SQL needs to have PHP 5. Is the server set up for that? I can handle some of the stuff they want with jQuery.”

Huh? My head hurts now.

Although they may be a great designer with a wonderful eye, they may not be aware of various ways to get things implemented to the client’s delight. That’s why it’s so important to have the coder present at this meeting.

The proposal is where you’ll reiterate your understanding of the project, along with addressing the budget, site map, schedule, copyright issues, describing the design and production process and all the other project details. If you’re really clever, maybe add in some recommendations for marketing, useful feature sets, public relations, search engine optimization, etc. This is also called the “up sell.” Naturally, before any design starts, you’ll want to have a signed contract that details the various highlights of the project and also get some up-front money.

Those are all fairly basic points. Now it’s time to roll up your sleeves and get to work. This is where the process should begin to kick into high gear. It’s a good idea … no, mandatory, for all concerned parties to have a copy of the project schedule and responsibility assignments. This is often a spreadsheet that lists each task (design, production, content gathering and creation, etc.), start and completion dates, along with who’s responsible for the task.

Before beginning the design phase, I prefer to have the copy written and approved and as much of the content gathered or created as possible. It tends to help if you know what you have to work with such as logos, graphics, images and the all-important words. It’s more than frustrating to find you need to go back in and redesign things because the content isn’t going to fit the way you want, or a visitor will need to scroll for an hour and a half to get to the bottom of the page.

While this is happening, the coder is usually the one who will verify the FTP information to ensure they can get onto the server or make arrangements to set up accounts for a domain, hosting, database configurations, etc. Many clients these days are requesting a content management system, such as WordPress, Drupal, Joomla or a custom solution. This is the time to do the installs and ensure all is working correctly.

With the content gathered and the server behaving, it’s time to start the design process. It’s also the time to be sure the communication lines are clear and open between the graphic designer and the coder. Keeping the coder in the loop at the start helps to avoid any potential snags that can give you a stellar case of indigestion when you find your stunning design isn’t going to work.

Web design and development typically involves a boat load of pieces and parts, components and details. A trip-up on any one can spell doom for the project. Two of the biggest trip-ups are a lack of crystal clear communication between the front-end and the back-end and assumptions.

Assume nothing. Always, always, always play back what you think you heard or read. “If I’m understanding you correctly, you mean …” can save a project. It’s a simple question. Use it. Use it freely and often.

There should be no divide between the front-end graphic designer and the back-end coder. If you take a bit of time to strive for clarity and open communication, there should be no troubles … let alone a chasm.