Defining the Design and Production Process

On this page, you will learn how one such site is built, including many of the processes required to get a site built from start to finish. For this example, I will be using a recent promotional site I built that is part of a much larger e-commerce site. Examine the functionality of this site and compare it to the screenshots/GIFs of this site in progress. You will see many similarities and minor differences that will help you understand this process better.

Step 1: Concepts
The Marketing/Promotions Department worked in conjunction with the outside merchandiser, in this case HarperCollins USA, to set up a prize to give away. Once the promotion is agreed upon, this information is passed onto the Content Group.

Step 2: Content Creation
The Content Group receives the promotional materials and information from Marketing/Promotions and creates a Microsoft Word document containing all of the textual data that will appear on the final web site. This includes marketing blurbs, page copy, headlines, product detail, etc. The Content Group will also set a publication date, which the Production Team is required to meet. This document is then passed off to the Production Manager.

Step 3: Production Management
The Production Manger then schedules the design and production of the promotion (web site). This includes one or more design reviews, peer reviews, and HTML production. A date is set to pass the final HTML and supporting graphical assets to the Quality Assurance department for full cross-browser and cross-platform testing.

About 90% of my job is within these steps, primarily the design and production areas and aspects. I will break this process down even further.

Information Architecture and Information Design:
The first thing I do when I receive a requirements document from the Content Group is I review it thoroughly for any immediate problems. If none are apparent, I will begin to form the basic information architecture and information design of the promotion by making the decision about how many pages the final site will have. For this specific promotion, I decided there would be three promotion-specific pages (the main page, the entry page, and the page of related products) and two secondary pages (the thank you page that is returned after a user enters the sweepstakes and the specific product info page).

Once I've made these decisions, I begin the graphic design process.

Graphic Design:
Because the promotion is part of an already existing site, I use a pre-existing template and layout that is similar to the rest of the web site. This creates a consistent look-and-feel and unity between the rest of the site and the promotion I'm designing. Other than following the existing design template I am free to design any way I want, as long as I follow the standard web design rules like websafe colors, small GIFs, and fast-loading HTML.

I begin by opening a design template I created several months ago in Adobe Photoshop. Here is a GIF of what this template looks like. As you can see, this Photoshop file is nothing more than a screenshot of a 4.0 web browser opened to approximately 800x600 pixels, with the guts of the page cut out. This is my image area, the area that I will design in.

As I design, I add the basic site template structure I use on most of features and promotions. Here is what our empty site template file looks like in Photoshop.

Now, the real design starts to take shape as I choose colors, graphics, fonts, navigation structure, and other design elements. Keep in mind that I'm not changing the basic template structure and am constantly evaluating my design decisions based on what HTML is capable of doing. Here's what the design looks like as I show it to our Creative Director for initial approval. Keep in mind that no HTML coding has yet been done, and everything you're seeing is actually a multi-layer Photoshop file.

The design is approved, some suggestions are made, and the design is now shown to the Marketing/Promotions people for their approval. They also make some suggestions, correct some mistakes, and the design is handed back to the designer in charge of finishing it (usually the same person who starts it).

In some companies, the Design and Production teams are completely separate. The designers never leave Photoshop and the production people don't know a Gaussian blur from a Sharpen Filter. In this case, I am doing both the design and the production, so I begin assembling the HTML framework for the promotion. I code everything by hand in a great HTML editor called BBEdit. Here's what it looks like.

HTML Production:
As I do the HTML production, I am constantly testing my HTML in both Netscape and Internet Explorer. One nice thing about my work environment is the setup I have. I have a Macintosh G3 with a 21-inch monitor on the right and a secondary 17-inch monitor on the left. Typically I have BBEdit open in the right monitor and a browser or two open in the left monitor. As I code, I switch back and forth on a constant basis, always testing the code. You can never test too much.

Some of you may have noticed some slight design inconsistencies between the Photoshop mockup and the final HTML-based product. This is normal. As I am doing the HTML production, I often come across a method that makes more sense both visually, and also works better code-wise. If the post-mockup version is cleaner, I often implement it without altering the Photoshop mockup.

Once I have an initial HTML template set up, I can finalize the structure of the code and then re-use it for every other page. If you are developing static pages, this can save you lots of time because you are re-using code. In my case, I'm using a proprietary mark-up language that was developed in-house which is embedded into the actual HTML pages. It is very similar to Microsoft's ASP and Apache's XSSI, in that you can use include files, but you can also embed programming logic right into your HTML. The page, while it is still HTML, also acts as a hook into an FCGI application that is running on our web servers, hence the .xcv extension you see on our files. This tells the web server that it is an executable page and should be processed by the FCGI app.

This embedded code has many benefits. It allows the production person to make the pages as fully dynamic as possible without resorting to using any one of the many Content Management Systems currently on the market. For instance, I used the "random" functionality of our proprietary language to display a different "McBealism" each time a user hits the page.

Another functionality of the dynamic executable pages is that I can use one HTML file (index.xcv) to render every page on the promotion. The differences between each of the promotion's pages are rendered depending on what variable is being passed in the URL string; index.xcv?section=home or index.xcv?section=list, for example. If it matches "home" then the index.xcv file knows to include all the "home" data, which is stored in supporting include files. If it matches "list" it will know to include all of the "list" data.

Quality Assurance:
Once I have finished the design and production, I pass the promotion and it's URL(s) to our Quality Assurance team. These people have a very good working knowledge of our site, our standards, and have a test suite of computers running all of the major browsers that they test the site on. They also check for mistakes, typos, or coding problems that may have slipped passed the production person. Once all problems have been fixed, the QA team will "sign off" on the site or promotion and tell the production person to go ahead and publish to the live web servers. All work up to this point is being done on any one of the numerous staging and/or development web servers that are only visible to our internal network and IP addresses.

Publishing of a web site typically consists of FTPing all of the files and graphical assets that make up the promotion to the live web servers which reside at a remote hosting facility in a different state. We have set up our telnet clients to use scp and ssh to eliminate the number of steps it requires to publish a set of files. It is a good idea for the production person to keep a good record of all the files they've built so that they do not miss any when they do finally publish, and have to spend time backtracking their work to figure out why something isn't displaying correctly.

The final step is to test the complete functionality of the site you've just published. Check for broken links, missing files, strange behaviors, and potential problems with any of the server-side scripts that may be running.

So, that's how a site is designed and created in a real-world shop. I'm sure many of our processes are similar to other companies, and I'd love to hear from others about their production processes and tips thay have learned to make their jobs easier.