Key steps in creating a website

Services » Answers » Key Steps in Creating a Website

If I had a penny for every time I heard the question: "How do the SideClick superheroes always deliver on time and within budget?" - I'd certainly be a rich man. The answer is really rather simple. We follow a process that we have refined over the years to ensure that we address challenges and issues at the appropriate time. This ensures that there are no unexpected roadblocks or hiccups to delay the rollout of the project. It's a kind of critical path analysis that we have done without really intending to. It's just natural and logical when your ultimate goal is to deliver perfection, on-time and within budget. We all know that cost and time overruns can cripple a project. At SideClick we aim to completely eliminate these headaches. Here's how we do it.

Our process breaks down into 6 key steps (7, but we're not including maintenance — we're focussing on getting our site out there);

  1. Vision, Purpose & Compromise
  2. Requirements gathering & understanding
  3. Planning, preparation & timing
  4. Design
  5. Implementation & development
  6. Testing & Deployment

Vision, Purpose & Compromise

Understanding the vision for a website and its purpose are critical to ensuring that it be delivered successfully, on time and within budget. If this is an internal project, make sure that you have written down the vision and purpose. Continuously refer back to it to reinforce what you are trying to achieve and why. If you are developing a website for a client or friend, ask them questions. Prompt them to start thinking about this, if they haven't already. Questions like; who will use this site? why will they want to? what is the USP? which devices will they use, mobile, desktop and/or tablet?

The answers to these questions can have a fundamental effect on the final solution. If these simple questions cannot be answered then perhaps the project hasn't been adequately thought through.

As a simple example let's think about the SideClick website. Our purpose was simple — we wanted to communicate our identity, visitors must get an understanding of who we are and the level of our skills. Our vision for our website is to become the most visible web developers in Cape Town by the close of 2015.

So what about compromise? Well, we've established what we want to achieve. Is it realistic? Are we trying to bite off more than we can chew? Do we have a reasonable idea of the cost. Is the cost within budget? There may be compromises to be made along the way — make them early.

Requirements gathering & understanding

Now that we know the vision and purpose of the website we can begin understanding the clients requirements. Each and every client is unique. That is why it's critical to understand the requirements of the project upfront. Once we know what the client wants to achieve — only then can a solution designer begin to understand what is required.

In all likelihood the web designers and web developers will not be experts in the client's field. That is why it is critical to listen to the client. Communication is key. Listen very carefully to what the client wants and use your experience and expertise to guide and educate them. Avoid say things like: “No, you can't do that, you MUST do this”. Rather phrase it like this: “In my experience we may encounter the following problems. Perhaps we should consider doing it this way, or using these technologies.” Let the client know the challenges and allow them to make up their own mind.

It's also important to use your experience to extract requirements that the client may not be aware of. Unforeseen changes, scope creep and shifting goal posts can be expensive lessons to learn.

Important questions to ask; Will the website or web application fall within a particular industry? Are there any unique requirements relating to that industry? Are there specific legal requirements? Will the website or web application store any personal information? Is this information sensitive? In the South African context, does it fall within the Protection of Personal Information Bill?

These considerations may be a pain to think of upfront — but the effort will most certainly pay off.

Remember: measure twice, cut once!

Planning, preparation & timing

Failing to plan is planning to fail... right? There is a reason why people say that... but it is shocking to learn how many people do not plan out their projects before they begin. At the start, while enthusiasm abounds, it's easy to dive headlong into a project, but as the roadblocks and forced compromises start to pile up and take their toll - you can see why some projects fail.

At this point it is important to start thinking about the content that will be generated or consumed by the website/web application. How will this content be stored, presented and laid out.

Remember, we aren't developing our solution yet... we're planning. It's important to identify the applicable technologies, plugins, add-ons and frameworks that will ensure the project is a success. Identify possible stumbling blocks (no roadblocks since we have already considered the potential major issues in step 1). Stumbling blocks merely require creativity, knowhow or a little elbow-grease to resolve - there should be no cause for panic.

A very useful output from this process is a technical and functional specification document. The functional specification document presents features, requirements and supplementary technologies/products in a systematic and logical way. This document serves as a roadmap to guide designers in designing the interfaces and the developers in implementing system features. It is critical that a project's requirements are documented, it ring-fences client expectations and prevents scope-creep.

For example — if you intend integrating with a 3rd party application (like Facebook or Twitter), do your research. Don't settle on a framework or solution and then backtrack because no one checked if it supported your requirements.

What browser versions do we intend to support? If 0.1% of our users will use Internet Explorer 7 it doesn't make sense to focus our efforts on catering for these users.

If you find that there are too many stumbling blocks or you have to make compromises at this stage revisit step 1. Examine your assumptions.

Key outputs from this step; high-level sitemap, rough wireframes, high-level data architectures. The entire site should be planned - but don't panic if you realise that you may need to add a field to your database tables at a later stage - this is minor.


This is where everything starts to come together. Clients identify with this step the most as they can start to see tangible progress. While it may feel like progress has been slow this is where patience pays off. By further employing and enjoying the benefits of rapid prototyping the solution can really start to take shape.

At this point, if the project budget allows, it may be wise to employ a User Experience (UX) professional to further tweak the design and ensure that its target audience can relate, and that all of the design features and interfaces are accessible. We all know that a site may have fantastic features - but if they are hidden, inaccessible or plain ugly your audience may be put off. You have one chance to convert a visitor into a customer or ally. Don't let your design get in the way!

At this point we are at a key crossroads. Since the design of a website is something that everyone sees; the client, their clients and the whole world wide web. Communication is key. The client MUST be happy. If you become stuck — rather spend more time on the design, ensure that client buys into the design. Make up for lost time by either sacrificing non mission-critical features or absorbing the cost to ensure the project is a success.

Depending on the complexity of the project and the requirements of the client the designer will deliver one or more of the following;

  • A static design of a key page - usually the home page, in .jpg format.
  • A site wireframe - these are essentially sketches of pages, layout and links.
  • A click through prototype with mock layouts, in HTML.
  • An interactive version of the site design, fully implemented in HTML, CSS & Javascript.

Just how far design goes before development takes over is a very subjective issue. For our opinion check out our articles on the difference between web development and web design

Implementation & development

Implementation and development is where everything comes together. Development is the glue that binds design, planning and vision and produces the final finished product. This is where the most magic happens - but it's usually unseen and underappreciated. Simple features (like a text autocompleter) require an understanding and mastery of a number of different concepts and technologies.

It is very important to adhere to the specifications detailed in the functional specification document. This document represents an agreement between the developer and the client and it's important to deliver accordingly.

For anything other than the simplest brochure sites it is highly recommended that the developer use some form of development framework. Whether it be a CMS framework (such as Drupal, Wordpress or Silverstripe) or a fully fledged web application framework (such as Symfony or Zend).

The benefits of using these frameworks are numerous. The major benefits that can be realised for any project implementing these frameworks include;

  • Templating system that promotes reusable frontend designs.
  • Performance tweaks - your applications perform better (and on the web resources are scarce).
  • Security - a community of skilful and passionate developers continually improve the framework.
  • Mundane and repetitive tasks are taken care of by the framework.
  • Best practices are adopted.

Testing & Deployment

At university a lecturer once told me the no programmer can programme even the simplest algorithm and have it work perfectly first time. I didn't believe him — but boy was he right! Programming is a very intricate process requiring immense attention to detail. Programming languages have widely varying syntax, functions are named differently and not all features are common across different languages. For these reasons, and the fact that all programmers are human (except the SideClick superheroes), there will always be bugs.

Bugs are a nasty word. We hate bugs and we hate the word too. It implies something dirty, like a lack of attention or carelessness by the developer, but this is seldom the case. What many people may not realise is that developers spend almost as much time testing as they do programming. The reason for this is that web applications can be extremely complex. It makes sense to iteratively build and test, build and test. This is sometimes called white-box testing. It simply means that the person testing has an understanding of inner workings of what they are testing.

This is informal testing though - what we need for good quality assurance is an independent testing process. A process where the tester has no knowledge of the inner working of what is being tested. This is referred to as black-box testing. The idea being that the tester cannot see inside what they are testing.

When testing a web application there are 9 key areas to focus on;

  • Application logic - does the application actually deliver expected results?
  • Consistency - do we get different results for the same task?
  • Integration testing - have we integrated with 3rd party applications correctly? Are consistent results being return? Are we interpreting these results correctly? Detailed logs can help with this.
  • Load testing - does the system perform under load from multiple users?
  • User acceptance testing - does the system conform to the requirements as detailed in the specification?
  • HTML validation - does the site conform to standards?
  • Cross-browser support - does the site work in the latest version all the major browsers?
  • Backwards compatiblity - does the site work in older versions of the major browsers?
  • Onpage SEO - while strictly speaking this is not testing, it doesn't make sense to deliver a site without the absolute fundamentals in place.

All that's left to do is go live and some final testing in the production environment. It's important to be thorough here too as production environments are always different to development and sandbox environments. Sometimes it makes a major difference and sometimes not.

Final Words

Wow - that was a lot to digest. If it helps - download our development process as a pdf for future reference. This was not indended as the be-all and end-all of development processes. Some readers may not agree with us at all. This is simply what works for us!