Web design and build process

 

1. Scope and documentation

Together we develop definition documentation to ensure that everybody has a clear understanding of the initial goals and requirements of the project. We need to be sure that we understand the big picture. We will fill in the fine detail together later, during the planning stage.

Outcomes

• We have agreed the project structure, basic deliverables and contracts.

2. Discovery

We collect insights from stakeholders about what they want the site to achieve. From this, we can start to define what the functionality and core priorities should be. We like to think about this in terms of ‘essentials’ (minimum viable product) and then ‘desirables’ (a prioritised list of other features). We find this helps clarify the thinking.

Information gathering varies from project to project, depending on timescale, complexity, budget and other factors. Here are some of the actions we frequently recommend:

• identify roles and responsibilities
• discuss the brief, the desired outcomes and goals
• identify how to measure success
• analyse the current site
• analyse competitor sites
• discuss content strategy
• discuss SEO
• discuss usability and accessibility
• interrogate and specify technical requirements
• develop user profiles and user journeys
• hold stakeholder interviews
• hold a kickoff site mapping session
• identify and collect brand assets and guidelines
• identify content assets – brand guidelines, text, imagery, video, etc

Outcomes

• With this raw information gathered we can move onto the planning stage, and start structuring the site.
• The client, with our help, can begin gathering content ready for addition to the new site.

3. Planning

Using the raw information gathered in Discovery, we work out the full technical specification and site structure, developing sitemaps and wireframes to show how everything fits together.

Site planning is a collaborative and iterative part of the web process, where we work with the client to ensure that we cover all aspects to everyone’s satisfaction.

Sitemap

• The sitemap shows the relationships of all the pages and posts on the site. We usually present the sitemap as a tree diagram.
• Sometimes the planning stage requires multiple iterations, at other times the client has already decided on all the specifics, and the planning stage can then be very brief.
• While it is important to define the fundamentals of the sitemap before we begin to design and build (top level sections, for example), websites are intended to develop and evolve over time, so the sitemap is never set in stone.
• The key is to have a carefully thought through and stable large-scale structure to the site navigation, with greater flexibility built in where appropriate.

Wireframe

• The wireframe is a development from the sitemap, where we identify each page and describe what it contains in greater detail. It helps us ensure that we have planned for every aspect of the site.
• The wireframe is usually displayed in a browser and looks like a skeletal website. We intentionally exclude ‘look and feel’ so that at this stage we can focus on page content, usability, strategy and functionality without distraction. We may include sample content, but a wireframe will also contain notes and comments for discussion.
• By keeping the wireframe unthemed, we can ensure that everything is structured so that content flows correctly whatever device or browser the visitor is using. It ensures that at this point we are prioritising the fundamentals, over which the theme will ultimately be laid.
• For pages where the layout needs to vary a great deal between different devices, we can develop ‘higher resolution’ wireframes to demonstrate how the layout alters in response to context. Typically we might do this for home pages and top level landing pages, and we might show mobile, tablet and desktop variations.

Outcomes

• Sitemaps and Wireframes are signed off.

At this point, we should have everything we need to start the design/theming and build processes in earnest. Usually, we will have made some early steps into design and build already, but sign off of sitemap and wireframe allow us to go forward with confidence.

Design theming

The goal of the theming phase of the web process is to develop and agree on a ‘look and feel’ that will work whatever shapes and size browser you are using, rather than visualising individual pages in fine detail at one fixed size (and therefore ignoring all the other shapes and sizes).

Modern responsive website design is highly modular, with sets of page templates built from smaller modular elements. This approach is often referred to as ‘Atomic design’. It is not a perfect metaphor, but we like it.

See atomicdesign.bradfrost.com/ and demo.patternlab.io/ for more information about the Atomic design approach.

The theme design aspect of the web process usually goes something like this:

• mood boards
• homepage visuals for desktop, tablet and mobile view
• standard inner page visuals at desktop, tablet and mobile view
• where required and as agreed, further visuals for other site elements

We present visuals online using a variety of tools and software, including Invision. Visuals can be printed from the screen if needed. Depending on the nature of the project visuals may be ‘static’, but there may also be visuals with some functionality to demonstrate dynamic elements, for example, drop down menus.

Outcomes

• The overall look and feel are signed off, along with the particulars of key pages and modular elements.

The theming process usually continues to run alongside the build even after the overall look and feel are agreed.

4. Build the site

Using the information gathered in the planning stage, and the look and feel agreed in the design stage, we start to build the website.

As with all the other stages, we make the build stage of the web process as collaborative as possible and will endeavour to make the ongoing build available for the client to view. We prefer this ongoing shared process to periods of silence followed by ‘ta-da’ moments, and we are sure you do too.

The build will occur in a private hosting space where it is only visible to the client and us.

Outcomes

• The build is complete and signed off, subject to testing and bug fixing

In some cases, the build might be more staged, with some parts of the site developed independently of others, at different speeds, and signed off separately. This approach can allow the site to go live sooner, with all the ‘essentials’ online, perhaps, but some of the ‘desirables’ added in later on.

5. Test the site

All projects are subject to ongoing in-house testing throughout the build, using a variety of browsers and devices. It is not something that only happens when the website is ‘finished’. However we also have pre-launch and post-launch checklists that we use for every project to ensure as little as possible is missed.

Testing is concerned with the functionality of the site and also with user friendliness, successful user journeys, accessibility and other factors.

Where budget is available, clients can arrange external user testing with a representative audience, or if required we can organise this for you.

Where budget is not available, you can test the site for yourselves at appropriate points during the build.

Outcomes

• The testing process is signed off.

In fact, the most rigorous testing will always be that given by real visitors once the site is live. Sign off of the testing stage means that the client is happy that the site works correctly and that we can confidently proceed to populate the site with content and then make it live. Bugs may still appear, and we will fix them when they do, as part of the maintenance agreement.

6. CMS training

The site is ready to have real content added using the cms. If you are managing content yourselves, we need to make sure you understand the cms.

While different content management systems often have much in common, there will always be unique aspects to the cms of any custom theme, so training and advice is a necessary part of the web process.

We aim to build ease of use into the cms and we provide on-screen guidance within the cms screens themselves wherever possible. As well as these help notes, we can provide ‘how to’ videos within the cms where needed.

Ideally, training is provided person to person, but sometimes training via telephone or Skype is preferable. The initial training session usually takes between two hours to a full day, depending on the complexity of the site and the cms.

As well as the training session, we provide ongoing support and advice as part of our maintenance agreement.

Outcomes

• The initial training session is completed.
• Clients are able to add content to the site themselves, with confidence.

7. Add content

Depending on what we have agreed, content might be added by us, by the client, or both. Typically we will add at least some representative content to the site to help our clients see how it all works.

Gathering content should be an ongoing process, undertaken while the site design and build are underway, so that by this point most of the initial content is ready to add. We have various tools to help you with this, including Gather Content.

Outcomes

• Initial content is all in place, in preparation for the site going live.

8. Make the site live

The site is ready to be made available to the public. While this might appear just to be a case of pressing the ‘go’ button, there is always more to it than that.

In fact, there can be different kinds of ‘live’. ‘Going live’ might simply mean making the site publicly available to people who know the web address. It might also mean getting search engines to index the site and display it in search results. It might mean a publicised launch date with press releases, newsletters and so on. There might also be a staged approach, where some parts of the site go live while other features are still in development.

As mentioned above, the most rigorous user testing is that done by real visitors, once the site is live. Therefore we recommend a ‘soft launch’ first, where the site becomes available but is not highly publicised. A soft launch provides further opportunities to hone and bug fix before any more high profile official launch.

Outcomes

• The site is live and available for viewing.

9. Maintenance

All websites need ongoing care and attention to keep them in step with the ever-changing environment of the web.

We have an ongoing basic support package to make your life easier and to keep your site as secure and up to date as possible. The package includes:

• regular backups of both the site files and the database with a premium backup service
• various premium quality plugins that we can only provide as part of an ongoing maintenance service
• monthly updates to the cms and plugins
• advice and support
• minor bug fixes and edits
• scheduled checking of the site for errors, bugs and quirks (optional – bit like an MOT)
• anything else we can do to help ensure the site stays up and successfully running

As the designers of the site, we have a vested interest in making sure that your site is a success and that you are happy!