Here at Best Rank we create websites and manage search engine optimization (SEO), among other things.  Our web design portfolio has about 30 select websites and will likely jump to about 40 by the end of the year, and that’s not to mention other non-website development related projects we work on (that we don’t mention in any gallery, yet).  Whew, it’s a busy time for us!

And since we’ve been continually developing our web design and development methodology I’ve decided to take the time to write a little about the process we go through when creating websites.

How we create websites

Because there are many different types of websites out on the web ranging from brochure/information sites to e-commerce sites to social media sites, it follows that website development is a complex process. Here I’ve tried to narrow it down to just five general steps that just about anyone can understand, and also so we can see the process from a bird’s eye view:

  • Gather requirements
  • Create work flows and mockups
  • Build out the site
  • Q/A and bug testing
  • Push to production

1. Gather requirements

As a first step we’re mostly concerned with figuring out what purpose the future website will serve and what steps we will need to take over the course of the next four phases to meet that goal.  

If you sell websites like we do then this stage will also encompass the sale, which is, naturally, where your sales team (maybe you) discusses details with the client and nails down what it is you’re going to build.

Do you already have a website?  Are you a mom and pop shop?  A large multi-national or global brand name?  Do you sell or want to sell products online?  Are you looking to acquire more leads?  Looking to become an affiliate? All of these questions are answered here.

Whatever the case may be, and if you’re the one who will perform the build, it’s usually a good idea to know the following:

  • Number of unique page styles/layouts. You may have a layout for the home page and another for the sub pages of your site.  Knowing the number of unique layouts will help determine how much work your team will undertake and what can be easily repeated as you build out the site later on.  Most sites we build end up having more than two layouts, for example one each for the contact page, category pages or product pages (if products are sold online).
  • Moving parts required. I say moving parts because a website may have features where the user can interact with the site vs. just reading text on pages.  You may need to build something custom where people leave comments (on a blog), log into a private area, purchase products online, etc. where they end up taking some action on the site. Your dev team will need to scope out that work very carefully as it’s usually the bulk of time your developer will spend on the project.
  • Amount of content to either write or upload.  Some clients like to write their own content or your team may need to generate SEO friendly content for them, but at the very least expect to upload that content. While it seems like a fairly basic task, it does end up taking time since revisions on writing that content may be needed.
  • CMS (content management system) preference.  This decision is usually made internally; the client generally won’t have a preference (since you are the developer), but someone has to make that call.  We generally like to work in Drupal or WordPress, two very popular open source and developer-friendly content management systems.

2. Create work flows and mockups

After the contract has been signed, it’s time to have your graphic design team mock up the unique layouts or have your project manager (PM) or technical lead generate the workflow documents. 

In the case of mockups, we usually start with wireframes since it helps give the client a sense of where items on their pages will be layed out before we get into the specifics of color and other subjective elements. This way we help ensure we never have to go directly back to the drawing board after the final mockups are generated.  Once the wireframes are approved you can start creating the final Photoshop mockups.

In the case of workflows, we usually go this route if the website project in question is somewhat complex; this way we help nail down what we’ll be doing. This way we can minimize any ambiguity in what we communicate to the client. Sometimes we may even charge for workflow mockups separate from the project implementation if the project looks to be very large. A client can, if they really wanted to, take the finished workflow to another company to have it built right away, so that’s usually why it’s a good idea to charge in that case.

You’ve heard me talk about “Photoshop” as it’s a very popular and great tool for generating mockups.  Another tool we sometimes use to create workflows is Balsamiq (http://balsamiq.com/), which is great for communicating to the client what the moving parts within the project will be doing without having them confuse the workflow docs for mockups. It looks like drawings/sketches which makes it pretty clear to the client it’s not a mockup.

Here’s a nice little demo of the balsamiq product:

 

3. Build out the site

This step is all about your development team.  It’s where they “code” everything.  

We usually set up a development or “staging” website that sits behind a protected login so only our internal team and the client can view the progress of the site build.

We really like working with the Drupal and WordPress platforms, two very robust and customizable open source CMS’s.  There are tons of plugins and feature additions for those two systems.  If you want to get really efficient your team can set something up so that all your favorite/needed plugins auto-populate into your staging website when you first setup the staging environment; it’s nice not to have to manually install the same plugins over and over again for each project.

Also, your team will turn Photoshop mockup(s) into a navigable, clickable, working website – we call it creating a “theme” or “theming”.  What’s great about WordPress and Drupal is that you can work on other parts of the site while your theme team does it’s part, slapping in the theme whenever you need to.

Your dev team will also create all the custom moving parts that don’t come standard with your CMS (if you use one) and upload all needed content & images to the site.

4. Q/A and bug testing

This phase is all about going through the development site and checking for bugs, CSS styling issues, usability issues, glaring mistakes, etc.  Your client will also get to see the new site as it nears completion to help get any feedback.  It shouldn’t be so much about your client’s revision requests (hopefully you can limit that in your contract when you originally inked the deal), but more about getting things set up the way your team first set out to do.

One big thing your team should be doing is checking for broken links using automated software to save time.  A good tool for this is called, “Xenu’s Link Slueth;” it’s a windows application.  We use it all the time to test for broken links and it’s free to download.  It crawls your website and generates a pretty detailed report.

5. Pushing to production

If you’re building a website for a brand new domain name then you don’t need to be too concerned with the launch date, however if your team is replacing an old, existing website then it’s usually best to launch at the end of the business day and preferably on a Friday as it will help your team bug test in production and minimize live traffic until Monday.

If you need to change the geo-location where the website files live (the DNS), then you will need to be careful since those changes can take days to fully propagate.  Again, near the end of the week is generally a good time to switch DNS.  And if you’re changing DNS servers, be careful to copy over the correct DNS MX (mail) record settings and or any other DNS settings as that can cause a big headache for you and your client if not taken into consideration.

Other items worth noting are

  • 301 redirecting old URLs to the newer ones is great for SEO purposes.  You don’t want to have old, popular URLs serving up 404 page errors and causing frustrated users.
  • Setting up your SSL certificate(s) should be done prior to launch if possible as well as grabbing a unique IP (needed for most SSL certificates to function properly).
  • After launch there may be some unforeseen bugs or errors that only generate in production and after launch unfortunately, so best to support the new site a week or two at the very least after launch.
  • Track the new site with some kind of analytics!  We use Google’s analytics quite a bit.

Other details

I’ve sort of over simplified the process of creating websites from the point of view of an agency, but you should get the general understanding of it all.  Here at Best Rank we actually have development check lists that contain over a hundred points to "check off" when we go through the entire website development process.  And we use basecamp for most of our project management and coordination.

I hope that helps! Until next time, Best Rankers!

Comments

Your email will not be published. Required fields are marked *

There are no comments yet.

Other posts you will enjoy...

5 Ways People and Organizations are Fighting Fake News
What Impact Can HTTPS Have on Your SEO?
Why You Need a Content Marketing Agency in 2017
Will Google’s Project Owl solve the Fake News Problem?