Our website process.

The Brief.

We will review the brief and our proposal in full to ensure that what has been asked and proposed is all correct. You would be surprised how often scope creep can occur between asking for a proposal, getting one, and starting the project.

The Questionnaire.

This is a crucial part of the first stage. If you have previously completed this questionnaire, we will review it. If you have not, we’ll ask you to and then firm up everything on it.

Complete the questionnaire

Housekeeping.

We will get you set up as a client on our systems and ask you to provide various details (address etc.) for billing purposes. You will also be sent an initial invoice to get the project started (new clients only).

Basecamp.

We use the mighty Basecamp to manage project communication. Your project will be set up on BC and you’ll be sent an invite to join us there.

The kick-off meeting.

We like to have a quick Zoom (et al) call to introduce the team and get the project started. This typically lasts around 30–40 minutes.

The kick-off agenda.

This is a very top-level discussion about:

1. Research
2. Content URL structure
3. Content deadlines
4. Wireframes
5. Design
6. Build
7. Go-live

Understanding your goals.

Here, we revisit the project goals to ensure the whole team understands where we are and where we need to go.

Competitor research.

We will research your main competition to see what they are doing, what they are ranking for and how we can do it better. This will result in sharing spreadsheets of data for discussion.

SEO research.

Researching your site for current keywords, content and keyword gaps and keyword opportunities. This research helps to inform site structure and content.

Site URL structure and planning.

The scope of this stage depends largely on the type of project, but it will involve planning and recording the site URLs on a shared Google sheet.

General content discussion.

Arguably the biggest bottle-neck for all projects, we will have a frank discussion about content, where it’s coming from and when it’s going to be supplied.

Content deadlines.

Later project stages can not be planned or scheduled without content, so we’ll mutually plan content deadlines for the different stages of the project.

Content for the wireframes & design.

We talk about content a lot. For the initial wireframe stages of a project, we will need content for the page we are working on. We prefer signed-off content, but if you supply draft content for the page, we expect only minor tweaks to this later on (text edits that you can do when the page is built out in WordPress, for example).

Wireframes.

We will guide you through this project stage based on your content, our research, and SEO considerations. Wireframes are non-designed layouts for the content hierarchy of the pages. We will use the content you have supplied to base these wireframes around.

We may suggest changes to content hierarchy, additional content needs or moving content elsewhere subject to best practices and SEO considerations.

Wireframes don’t touch design: they are the first stage in planning the page layout and information architecture.

Design.

Typically the homepage is wireframed and designed first. This initial concept design sets out the look and feel for the rest of the site. It’s worth spending time on this page and getting the design spot-on. If you have supplied brand guidelines, these will be used to inform the creative. We only design the best option for the page, so you will get an initial design that we can then develop.

Initial concept designs for different pages are the starting point for feedback and development.

Whole-site design.

As you supply the content for additional pages, we will design them for approval. As we work using ‘blocks’ for different types of content, we will start to create the block library for the site—these blocks will then be used to build other pages.

It’s not often required to fully design each page of the site as a composite design, as most websites have pages built from similar types of content. This approach leads to a more flexible site and a speedier build process.

Content in the form of blocks that can be used across all the sites pages.

Headers and footers.

We generally build out the main site architecture first, and this will include the header with main navigation and the site footer. Everything in between is content handled by blocks.

Block build.

The dev team will build the blocks for your site from the approved designs. These will be built and optimised for all screen types. Each block will be presented for checking, feedback and approval.

Functionality.

For most functionality to work, you need blocks and content, so once these stages are complete, functionality will be addressed and coded as required. This stage is so project-specific, we can only outline the process here.

Adding and editing site content.

So, we have completed the headers and footers, built the block library, and added enough content for the blocks and functions to work. Now comes the population of the rest of the site with the content. Building the site with blocks makes arranging and editing content easy.

Managing content.

The content supply is covered above, but the management of it is done on a shared Google sheet, with each URL for the site worked through in turn and marked ready for checking. Our spreadsheet allows for comments and notes, with each URL clearly marked (to-do, in-progress, question, ready for approval, etc).

Managing the content of a large site is best done on a shared spreadsheet.

Snagging content.

We use an online mark-up tool for final content snags (once the spreadsheet is complete). This allows for easy commenting and visual snagging of all content across the site and results in an actionable list for our team to work through.

Testing.

Before going anywhere near live, the site is fully tested for any functional issues, layout snags and other aspects. All testing is done on the development environment.

Getting the site live.

This process depends on the final live server for the site, but we generally pick up the WP install and move it to the live environment or server. One of the main reasons we use WP Engine for hosting is how easy they make this process.

Live site checks.

We have an extensive 50+ list of checks and tests on a newly live website. This list covers everything that needs to be tested and confirmed.

Training.

If preferred, this can be pre-live, but during this stage, we will take you through the site training. This is usually done via a Zoom call, which can be recorded and shared for future reference.

Ongoing support.

We offer a range of support plans for websites once they are live. These plans are time-based and can be used for anything, from design work to technical support.

Handover.

Once live, we’ll send over an invoice for any remaining balance, and the site is 100% yours. We retain no ownership of code. If you host your site with us or are on a support plan, you also get to use our developer plugins for free – no licences required.