How to build a website in six easy steps

For most web designers/web developers, building a website comes naturally. You design it, code it, and launch it. Right? Wrong! The practice of building a website may have got justifiably shorter (or longer) depending on how you see things working online - but the theory/trick behind a good site build still stands: Planning, planning and more planning!

The keyword reach associated with building a website is limitless, but essentially - as ghastly as it might sound; building a website without planning, can - and most of the time will mean danger ahead and ultimately less success in the long run!

So without further ado, here is Cheb’s guide to building a successful website.

Planning/Scoping

The “Ahh, guys? What are we building again?” phase

So, you want to build a website? It’s not rocket science - but it is a science, and an art! Just like baking a cake you have several ingredients: A handful of designs, a dash of slicing, a teaspoon of code, a sprinkle of love, and ‘bob’s your uncle’ - or, ahh, not! What many people in the web industry however don’t realise is that the planning phase of a website is so crucial, that it really can dictate how well the build of the website is. Essentially, if done correctly, the planning phase - or more importantly, the scoping sub-set of the planning phase, should setup the site’s structure, navigation, as well as functional specifications for the web site build.

Scoping (also referred to as Information Architecture) should reveal not only the clients’ objectives for the project and what they would like the site to achieve - but more importantly, extrapolate all the detail, business rules, as well as technical adjustments which will be needed down the track in order to successfully design, build and launch the website.

Without mentioning any names, I’ve worked with around six web firms, in some way or another, in Australia alone - and the sad thing is, only 65% of them actually ‘recognised’ the importance of getting scoping/Information architecture right! Obviously Wiliam Web Design is in the 65 percent that got it right! Overall though, not really the statistics you’d like in the field of web design and development - right?

At the risk of helping the competition too much - to be counted up with the ‘best of the best’ you’d be expecting your Information Architects/Business Analysts/Usability Evangelists/whatever you want to call them - to be able to at least come up with the following pieces of documentation in this phase of the web build. As a side note, the documents listed below will be discussed in detail in an upcoming post so stay tuned!

1. Requirements gathering documentation
2. Requirements analysis documentation
3. Functional specification documentation
4. Prototype development

You read it here first ladies and gentlemen! From this day forward, let it be known that Cheb D coined the term “The GASP Method for scoping/information architecture” which will be used to outline the bare minimum in terms of documentation/deliverables; that the planning/scoping phase of a good website build whether in Sydney, Melbourne, New York, or London - should deliver. I will outline the massive importance that these documents play in the successful build of a website in an upcoming post - for now, let’s kick on to design.

Design

The “Wow! so all you needed was good documentation and you came up with THAT?!?” phase

Never thought this would be a part of this post, yeh? Okay, so nothing overly-crazy here. You can’t build a website without design. The situation is that everything that happens from this point forward will start to effect everything else throughout the project. Think of it as the literal view of ‘The Waterfall Model‘ for software development.

Further to that - everything that was done right in the previous phase will already have a dramatic affect on the project as a whole, because the difference between a good and bad design decision does not always start and end with the designer! Whether you are building a web design blog or an E-Commerce shop-front, I think that holds true.

Designers as a collective, love to think that they understand everything about usability simply because they know good design! Sure, they would be one of the few people involved in the web design process who could have a say in how and why things will work - but having a designer nutting out the usability of their website as well as designing it, without the assistance of:

a) an objective individual such as an Information architect, and
b) an objective individual such as an Information architect with previous experience in online user experience design (UXD)/User interface design (UID), or usability and accessibility analysis;

is comparable to getting a developer to bug-check his own code or bombing for peace!! Good luck with that!

The issue however is that we have come to realise that good design is not necessarily always good usability, and more importantly that good design practices is not the same as usability. Something as simple as having a login box pop-up as a div overlay upon click, as apposed to always being on the page and distracting the user from more important areas of the page, such as a call to action - can be a big talking point.

It’s a double-edged sword! Do you hide the login box to begin with under a ‘login button’, or do you go with the norm and leave it showing on the front page, but risk it being a total distraction due to its positioning? A question that a designer shouldn’t have to, and probably can’t figure out on their own without some interaction from an information architect.

There is absolutely no doubt though how important this phase is in a good website build! It’s paramount that design is not only up to standard, but that is ’sets’ the standard! New techniques, interactions as well as connectives to modern technologies such as Ajax should all be encouraged and not frowned upon as ‘making more work for developers’.

Slicing

The “Do you seriously expect me to cut this PSD up for you in THAT many hours ONLY?!?!?” phase

Slicing is one of those things that in the past has taught me can greatly change how upper management think about the whole design process. Some managers think the hours dedicated to it are way too much, others think that’s just unscrupulous and without merit that it ‘generally’ is allocated the least amount of hours dedicated to it out of the whole web site design build process.

Which ever way we look at it, years of experience has taught me that not only are designers getting ‘crazier’ with rounded-corners, drop-shadows, beveled-edges and more; but Web 2.0 calls for all that snazzy stuff, and unfortunately, I don’t see that stopping, coupled with, we can’t stop technology - means we have to find a half-way house!

I personally think more time needs to be dedicated as a whole to the slicing process. Not only do slicers need to give the PSD (design) some life using CSS and JavaScript, on top of HTML - but cross-browser testing is a freaking arduous and taxing process - if nothing else! So respect to all you slicers, or Interface Hackers as I like to call them… I feel your pain!

Development

The “Okay, so I take the source files from here, and connect it to WHICH database?” phase

Development and slicing somewhat go hand in hand.. Whether the web site is being developed in C# (.Net), PHP, Ruby on Rails, or Perl for that matter - the task is simple and complex - or better yet, simply-complex!

This phase is important and hence why most of the time, you will find a good chunk of the hours allocated to a web-based build will be allocated to development. Unfortunately, that’s the nature of code! What you want to do, is make sure that there are adequate hours for the design and slicing - but ultimately, depending on the scope, budget and size of the project, actual development of the sever-side application as well as all the database connectivity as such should be the biggest chunk of the collective ‘development/build’ pie.

Obviously, if the project is just design and slice, then there’d be no time against development phase, or minimal (for testing, etc).

Testing/Quality Assurance

The “Yikes… You found HOW MANY bugs?” phase

It’s not easy to fight technology. Somehow, no matter how hard we try, Testing and quality assurance will (unfortunately?) always be a phase in the successful build of a website. To aid in keeping this short(er) than I expect it to be, I would just make the following suggestions in dealing with this phase.

1. Make sure the project plan/milestone outline clearly shows the testing phase as part of the project (from the get go!). This is important because the client has to realise that no matter what happens during the life cycle of the web build, how fast the build is, how many functions they take out, or whatever it may be - this phase is not going anywhere!

2. Treat it like you would any other phase. You wouldn’t get your delivery man to code your website, would you? Don’t get your secretary or janitor to ‘run through the site and tell you if they find anything out of place’. Believe me, it is sad but trust me - I heard that statement being said about two years ago and it’s been ringing in my ears ever since! Pay for a tester, they are worth the dollars you spend on them! and finally,

3. Make sure the quality assurance/testing is being done off a functional specification! For god’s sake people! Cardinal rule of unit/website testing. Go in there with a plan! Do NOT just pretend you are a user and ‘click around’. In my experience, around 60% of bugs found in this phase are always business rules that either the tester didn’t know about, or were simply forgotten. If they are on a document that has a signature on it, it WILL save your behind!

Deployment/Launch

The “So does that mean we can get paid now?” phase

Website design and development; once again, whether in Sydney, Australia or Sidney, Montana, USA - even though sadly many people don’t see it that way, is really an art. Wiliam has definitely set a precedent (and a name!) in the web design industry in Australia for not only delivering websites that work, but delivering websites that work great, and boy is that not a cliche!

It’s really about how you learn from your mistakes, co-ordinate change management in an ever-growing industry, and more importantly control technology that will ultimately dictate how you represent yourself as a web design agency/freelance web builder and best of all, how your competition view you in such a bloody competitive market.

So we’ve made it all this way. Launch the bugger! You’ve come all this way though and apparently you’ve survived. Don’t lose it all now! You want to make sure you take your time to get the launch right. Just like a top-secret launch sequence, make sure testing is complete, you have document listing where everything should go (server wise) - your databases are working fine and everything is connecting to where it should be - and then hit the switch!

Damn, wait.. Did you kill something? refresh, clear cache, refresh again, is it all still up? post to that forum that you created; is it threading correctly? Point is, make sure it doesn’t just stop when the last file is transferred. Building a great website involves a lot of co-operation from many people. It won’t happen overnight. Heck, sometimes it won’t happen over a six month period; but when you get it right? It’s a feeling like no other - or at least you’d hope so!

And that’s just about it… Happy web building people!

So, that was a long one. What are your thoughts? Do you agree on this model for effective website/web page design? let us know. Please drop a comment or if you like the posts, subscribe to our RSS feed to be alerted whenever a new post is available.