Planning a New Website? These are the Development Phases to Follow

Planning your next website ebookDownload the eBook The following is from our recently published eBook, Planning Your Next Website, of which you can download in it’s entirety for free. As a website support company, we see the good, the bad, the ugly (and the really ugly). We hope to help organizations make the right hiring choices when it comes to having their next website built.

Our Recommended Website Development Phases

Like dancing, if you miss a step, it may get the job done but might not look so pretty.

If you are developing a large-budget site with the help of an agency or studio then most definitely a full plan and process should be defined for your web development project and provided to you as part of the overall service. However, if you are working with a vendor that does not provide such planning as part of their services, make absolutely sure that you make a plan and follow it. Not following a plan or skipping any of the steps outlined in the following section could be detrimental to your project, deadline, and budget.

The following are the minimum steps or phases for any web development project. Of course, larger projects may include software testing, focus groups, or other phases as each and every project is different.

Website Sitemap / Information Architecture

This is your initial planning document. Those of us who consider ourselves fancy-pants developers may use snazzy terms like “Information Architecture” and develop a visually attractive document that graphically communicates the proposed structure of the site. No matter what fancy term or documents we use to describe this, at the end of the day it is just an outline. An outline that shows the structure of the website. Starting with the home page, it should lay out every major page and section. For the first pass, think simple such as the following example for a Widget company:

  • Home
  • Services
    • Widget Appraisal
    • Widget Repair
    • Widget Consulting
  • Products
    • Green Widgets
    • Red Widgets
    • Gold Widgets
  • About Us
    • The Company
    • Leadership
    • Staff
  • News
  • Contact Us

Run this document by all stakeholders and make sure it captures all the content areas your site is going to need. Though this document may start as a working document, by the time development starts, this document should be locked down. It will become part of the developer’s “bible,” but more on that later.

Features Documentation

Along with the Sitemap you should develop a features document that describes how each major section or page is supposed to function. If the contact form is supposed to integrate with MailChimp, the news page is to include a Facebook feed, or any other function required… document it. The more detail the better, allow nothing to be left to assumption or interpretation.

Documentation matters. If it’s not in writing, there is no record of it being requested. Don’t assume that notes are being taken in meetings and every phone call is documented. The features document is your chance to put into writing exactly how your site should work. Both your designers and developer (assuming they are not the same person) should follow the notes in the final features document as they build your website. This too becomes part of our developer’s bible.


What is the site going to look like? It’s not enough to ask for a “clean professional design,” believe me, everyone asks for that.

Whether to Go Custom or Use a Commercial Theme

At this point we must make a big decision: Are you going to work with a designer and/or a team of UX/UI experts on a truly custom design, or are you going to purchase a commercial theme? A commercial theme may be budget-friendly, as you can avoid the costs of custom design, but it comes with many limitations. Such as customization and performance implications, SEO, and content structure. On the other hand, a custom design will allow you to get exactly what you want, but it may add time and costs to the project. Pros and cons… can’t avoid them. I go much further into these pros and cons later in this document.

A Custom Design. You So Fancy

If you have chosen to have a custom design made, you will want to work with your designer to define exactly what the site will look like. In my opinion, the best sites out there use a set of defined templates for each part of the website – though there are tools that can be installed into CMSs that will allow you unlimited page layouts. These kinds of tools quickly create a chaotic unbalanced website and come with performance implications as well. I strongly encourage that you enter this part of your project by thinking about a set number of templates. Examples might be home page, executive bio, general interior, main news page, news article and contact us page. Some sites are super simple (simple is good) and may only have 1 or 2 templates, others may have many more. The number of unique templates will more than likely have an effect on the price and timeline of the entire project.

Depending on who you work with and your budget, you may go through a phase of UX/UI discussions and wireframe development prior to starting the phase of design that includes impressive comps in full color. Regardless, at the end of this phase you should have a set of templates that you are happy with … really happy with. Don’t assume everything can be changed, judged or refined later. Though nothing in pixels is set in stone, changes to the designs after this phase may cost more and affect timelines.

Remember, a commercial designer is a not an artist. They should be open to constructive criticism and assuming productive communication on both sides, it should only take 2-3 rounds of refinements to achieve the final designs. Make sure your agreement includes at least a round or two of reasonable refinements.

Don’t Forget the Developer

One of the most frustrating things that can happen is when a feature is designed, signed off on, and accepted only to learn that the developer says it is impossible, impractical, or too complex to the point of affecting budget and timeline. To avoid this, include the developer during the design process, let them review the design, and allow them time to raise any possible flags to avoid frustrations later in the project.

A Commercial Theme. Why Reinvent the Wheel, Right?

Commercial themes are much less involved than a custom design. Just do a Google search and you will find hundreds if not thousands to choose from. However, be aware that these were designed in the eyes of the author and not through your eyes. They may not meet every expectation you have and may have an impact on performance, scalability, customization opportunities and site structure. Talk to your developer about the pros and cons and read the theme reviews. Be sure the theme is well supported by the developer and that a large number of these have been sold. In a world where website cost varies from a few dollars to 6 figures… there is a difference between a $50 commercial theme and a $6,000 custom design.

Design is Subjective – Make Sure Everyone (Who Matters) Sees It

Again, this comes from experience. Nothing is tougher than when a project is almost done, been signed off on, or even launched when an important stakeholder, like a CEO, sees it for the first time and is not happy. Hell, they have the title of CEO and it’s their job to voice their opinion and their opinion demands action. If they don’t like it, but the project is complete or nearly complete, what are you going to do!? I can promise you one thing … your designers and developers are not going to work for free to redo a site because one person is unhappy, no matter how important they are. This is a disaster. I have seen it happen. Make absolutely sure you get approval from all stakeholders prior to beginning development!

Be Done and Put it in Writing

Sign off on the design. This is as much for you as your designer. Once you are happy with the design or theme sign off on it and mark that point as the time that no further changes will be made. Once development starts, changes to the design can have great effect on timeline and budget. Even requests such as, “make the font a little larger” can have a big impact on spacing and layout. So, sign off, because these final art files become part of the developer’s “bible.”

The Developer’s “Bible”

A good developer does what they are told (within reason of course), but first we must be told in a very clear fashion what it is we are to do. Before I start a development project, I put together what I call the “Developer’s Bible.” This is a set of approved files including the sitemap/information architecture, the features documentation, and the design files.

I call this our “bible” because it should be blessed by all parties, it should be undisputed by its “followers” and accepted as the highest authority. If these things are done correctly and thoroughly then the developer(s) should have no confusion about what they are to build for you, and you should have no doubt to what is going to be built.

At the conclusion of the project, if the developer(s) gives you a site that looks exactly like the design, includes all the sections and pages defined in the sitemap, and includes all the features described in the features document, then you should be a happy client. Not only should you be a happy client, but the developer(s) should be happy as well because they knew exactly what was expected of them. There was no scope creep, and budgets and timelines were met.

Test, Test and Test Again

This is the most overlooked step when planning a website. Seriously it is, by both clients and developers alike. We often schedule development up until launch while assuming that review rounds are testing rounds … they shouldn’t be. Make sure your development team gives you testing time. The more complex the website, the more testing time you should allow. Have many people test it, on many devices, and focus on whether things work.

This is About Testing, Not Your Opinion

When testing and asking people to test your site (hopefully hosted on a staging server for easy access to your testing group) make it clear to them you are not asking them for their opinion on design, styles, imagery, and the like. People love to give their opinion and at this stage. The fact that Jane Doe would like to see a different shade of blue is simply not where you are at. The time for artistic vision has passed, you are now just making sure everything works.

Instruct your testers to click through the site on desktops and mobile devices, to look at the pages for broken layouts and to test every major function. If your site sells stuff, testing should include buying stuff. If it has forms, fill them out and make sure they are received by the proper people. Do not launch the site just because a deadline is approaching, a CEO is getting anxious, or you figure your development team can squash bugs post launch. Test it because no matter how good your development team is, a website is made up of thousands of lines of code and even New York Times Best Selling authors have editors.