In this post I would like to outline the basic workflow I follow when designing and building a website from the ground up. This is by no means a complete list, its intention is to clarify for myself, if anything, the basic steps required and hopefully to give some pointers to aspiring developers on how to design their own workflow. I also intentionally leave out stages where server-side scripting is involved, for example, for simplicity.

Step 1. Determine that a WWW site is the solution.

This step is far too complex to explain fully here: suffice to say that you must always decide on the optimum way to proceed with a project, before actually embarking on it. Are you a locally-based business who would find it difficult to work outside a 100m range? If so, perhaps a world-reaching website is not the best solution to advertise your business: you may find that, at least in the short term, your resources would be better spent setting up billboard/on-vehicle (eg. bus) or local radio advertising, for example. Once you know you want a website, put some resources into it: remember, first impressions count, so you want to your new website to impact hard, or those potential customers might leave and never come back. Pool your resources, bring together any information which might help you organise your site, be it photos, your company logo/coat of arms, letterheads, posters and other promotional gear, and use those to make sure your website forms an extension of your existing promotional material (and reduce how much time you need to lean on your graphics designer.)

Step 2. Draw-up a spider diagram

Nobody can visualise the perfect website in their head: design, colour scheme, layout, content, categories, tags – these should all be noted down and linked together, in much the same way your site’s pages will need to link to each other. Do you need to design a new logo for the site? If you have a colour scheme in mind, you should use it in the logo to bring the look together: if not, you should design your logo and then derive the basic colour scheme from there (see below.)

Step 3. Content is King

Now that you know what kind of content you need on your site, your best next move is to get some content written down: use an existing editor, such as WordPress, even if you plan on building your own CMS, to quickly set those wheels in motion and generate unique, relevant and useful content for your site. Link early, link often: outbound links should direct the user to further information, in the same way you would (hopefully) direct your customers elsewhere if you did not have the item they wanted. You might not have their custom this time, but they are likely to gratefully remember your helpful advice and recommend you to others.

Remember: Content is King. In the past, design was involved and tied to the editing process, as <font> tags and <b>/<i> etc. were used to style the content. Fast and effortless, but changing the layout later, or even just keeping it consistent, quickly becomes laborious. Instead, use modern techniques. Mark up those articles in a semantic way, using <p> for paragraphs, <h1> etc. for headings, <ol> for lists of items where the order matters, <ul> where it does not, etc. These allow CSS to be utilised later to apply your chosen design to the content, at the same time enabling future changes in design to be implemented with ease.

Step 4. Decide on a colour scheme

Your colour scheme will usually have little to no bearing or effect on the content of your site, so you can safely leave this part until now provided you semantically mark up your content. I always recommend the following basic guidelines when choosing a colour scheme: black and white can of course be combined with anything, so these are the first two items in your colour scheme. Now choose around 4 other colours: there are many excellent tutorials on the web for this, aPaddedCell article here being a good example.

Step 5. Basic HTML structure

Aim for either HTML 4.01 or XHTML 1.0 compliance. Which to choose depends on many factors, personally I prefer the strictness of XHTML where possible. Once decided, begin building your basic code structure template: use a <!DOCTYPE>, include the <html> tag, include the <head> and <body> and try to close elements where possible (eg. <p> tags, but never <img> tags) to eliminate the possibility of a “tag soup” as this post explains.

Try to avoid writing any CSS until you have the HTML structure laid down. When building a house, the foundation must be solid before you start building the walls. With HTML/CSS, you follow a similar pattern: this also allows users with outdated browsers, or those with CSS disabled, to continue to use your site: allow for “graceful degradation”. Make allowances in the code for the CSS to be applied, though: if there is no suitable semantic element for a block of content, a <div> will of course be used – It would be a good idea to assign these semantic, relevant classes so styling rules can easily be pointed at them later. Use <div class=”links_wrapper”>…</div> instead of <div class=”blue”>…</div> so that classnames reflect the purpose or function of an element, rather than their styling. For sections which will only exist once on the page, it may be more suitable to use an id, eg. <div id=”footer”>…</div>. Avoid use of the style attribute: it has much the same drawbacks as <font> or <b>/<i> tags.

Step 6. Begin styling your site

This stage of the development is where the fun (and headaches) begin. With so many browsers out there, each with its own quirks, it is virtually impossible to make your site look the same across all browsers, possible user configurations and eg. MS ClearType and similar settings. There have been major improvements in this area, particularly with the advancement of standards-compliant browsers, and it is clear that websites should be developed to accommodate the user’s settings, rather than compensate for or override them. Using ems for measurements (where applicable) is preferable as it allows proportional scaling of the page’s text by the user (a good comparison of units em, pt, px and % is available here, be sure to read the comments too.)

Once you have your layout looking acceptable in modern, compliant browsers (Firefox, Chrome, Opera, Safari etc.) and have your semantically marked-up pages easily styled consistently, it is then time to test for Internet Explorer. There have been many articles on IE-related headaches and workarounds, too many to count or list here, but my own technique is to begin with the latest (currently IE8, although an IE9 RC (Vista+ only) is currently in the works), apply any fixes in a separate stylesheet included using conditional comments:

<!-- ... -->
<head>
<!-- ... -->
<!--[if lte IE 8]>
	<link rel="stylesheet" href="css/ie_lte_6.css" />
<![endif]-->
</head>
<!-- ... -->

… and then move back a version & add fixes for IE7. I often find it useful to apply the fixes as shown before, so all IE8-related fixes are applied to 7 & 6, as this usually results in less work and less CSS, but YMMV.

Step 7. Review, Rinse, Repeat

So you have your basic website: but are you happy with it? By now you will undoubtedly have identified some problems with either your own workflow or the way in which your content is marked up, so go ahead and correct those errors now while there are few changes to make: it will save you time in the long run. Remember: build a solid website first and then publicise it: you want your first impression to impact your audience hard, draw those customers in and keep them there, but you want to build solid, useful content first and not concentrate on link building to begin with – after all, what use is a high-ranking site with many inbound links and a high PageRank if your customers have nothing to read when they get there?

---

This post is by no means complete, I intend to improve on it at a later date, but please feel free to leave a comment.