The Development Phase

While different people and companies will have a variety of processes, the development phase is the staple and most important part of the project as it’s when your final product actually gets built. You’ll see visual mockups and documentation up to this point, but that all merely serves to bolster the development into being the best it can be. Before we get to that, let’s go back to basics.

What is development?

While most people know there is a thing called ‘code’ which is in a website or app, unless you work in the web industry, you might not know much more that that. In short, website coding is way or writing structural (first the title then the paragraph), presentational (title is blue and in a bold font) and behavioural (click this and show that) language we can put all together to make the websites you use every day. A large part of making a new website is the critical thinking and design consideration prior to this technical task, making sure the new website achieves what you want it to for your business or endeavour, but we should also keep in mind that a website, just like a car or building, has to be put together in the right way to ensure it is reliable, and hopefully a positive experience to be in. 

You’ll also be likely having your website developed into an ecommerce (online selling) or content management (offered referred to as ‘CMS’ and for brochure website of text, images and video) system. These systems are prebuilt online software that experienced web developers can plug your site in to, meaning you can manage your own content. In addition to the structural, presentational and behavioural language they have to write, there’s also (usually more complex) coding to make sure this prebuilt system and the website speak to each other correctly.

As mentioned, this phase comes after the design phase, while the design phase feeds into this, we shouldn’t ignore development up to this point. Now I’m not suggesting you’ll be writing any code or understanding how it all works all of a sudden, but you’ll play a part in keeping the project moving smoothly, so let’s explore the project up to this point, some stages you most likely will come across, and how thinking around development should feature.

In the kick-off meeting…

Right from the very first meeting we should be talking development. As with my previous article in the series, the design phase will probably start with a kick-off meeting to discuss everything. You should ask if the developer who will be building the website will be at the meeting, as they will have good insight into latest web technologies and practices, plus also be a sounding board for if initial ideas are even possible. It might be the case that the designer IS the developer, as this is becoming more and more common in the industry. If that’s the case, it means you’ll have that consistency throughout, so it’s nothing to be fearful of. It might also be that a developer hasn’t been assigned to the project yet, because of scheduling or another factor. If you find out this is the case, try and make sure someone technical is in the room to keep ideas in check.

By this point the ecommerce platform or CMS you’ll be using on your website will have been decided. If you’ve got an existing website, you may be sticking with what platform you’ve got. If so try and do an audit of all the technical things your current website does so you can take it to the kick-off meeting. You might not want all existing functionality carried over to the new site, but its common that small pieces of desired functionality are just simply not discussed, spotted at the last minute and ultimately lead to delays and further costs to integrate them back in. If it’s your first website, or your current website doesn’t do what you’re wanting it to, you might be moving to another platform. In the kick-off meeting, be sure to ask for a demo of the platform so you can see first hand how easy it is to use, and ask about how many sites they’ve built using it.

In the technical specification…

This might go under a different name (statement of work, schematic etc) but you should get a technical specification for the work, and if you start going into visual mockups or anything else design without one then ask about having a full list of functionality and technical information so its clear. When you get one, will feel possibly too technical, but ask questions if your unsure and spend time reading it. Some useful things to check this document or ask about during this time are…

• What custom features have been discussed? Are they all listed and described as you believe they should work?
• Are there any pre built plugins such as cookie pop up banner or SEO tools that you know would be useful or you would expect to be on there?
• Are they intending to add any visitor tracking code such as Google Analytics? Do you have an existing account where it would need to be carried over?
• Is there anything you’ve got on your current site that you haven’t talked about in detail but would expect to see on the new website, such as a newsletter sign up?
• Will your content be migrated from your old site automatically or will you have to copy paste it all over when the new site is built?
• What specific browsers and devices will be tested and supported?

In the design phase…

At this point you’ll now be onto the phase of design (although arguably the whole process is one of ‘design’), and this should feel a bit more like something you can get your head around. Designers, studios and agencies might have different processes, but normally it starts with wireframes (which are line drawings of key pages to show layout and structure) then mockups (which are JPG visualisations of how the wireframes look with your brand, colours, fonts and images on). This is done for you to see and comment on the visual appearance of the website before all the hundreds of lines of code get written. 

During this phase development should still be in our minds, as no one will ever see these mockup JPGs or line drawings, and they are simply a means to get to the next step of the actual website. We should be reviewing visuals and asking questions like “what happens when I click that?”, “will there be any animations for hover effects?” and “what control will I have for that section/page in terms of content, layout and versatility?”. It’s normally useful (but not always possible) to have a face to face meeting at this point, so if you can sit down with the designers and ask these questions and bring up example websites on screen for talking points.

You should also be looking at navigation and page structure to see what pages you need to create and write. Ask about the sitemap / structure of the site they foresee in relation to the visuals. While they can comment on structure and best practice, unless you’re paying them to be the copywriter too, it will be down to you and your business to actually write the words. More on that later.

If the designer and developer are different people working on the project, ask what the developer thought as a way of checking she/he has actually seen them. Sometimes, and through no ones fault, visuals can make their way to the client before anyone technical has had a chance to review them. It’s always best to just double check this before you start falling in love with any features or stylistic flourishes.

The last consideration at this phase is to dig out the technical specification and check everything that your reviewing lines up with what’s in there. As discussed, some of it might feel too technical, but if the specification talks about a newsletter sign up, can you see that in the mockups? And if so, do you have a visual of what it looks like when someone has signed up successfully/unsuccessfully?

Then, onto actual development…

After all the contact, discussions, review and feedback of previous stages, when the visuals are signed off and the project goes into development there will likely be a bit of radio silence as the developer gets their head down to start working through it all.

This doesn’t mean you should just sit and wait though. By far the number one reason (in my experience) of why web projects miss their projected go-live date is that content creation, refinement and entry to the new website gets underestimated as a task. Use this time to start putting together pages from the sitemap we discussed in the previous stage, so when the website is passed back to you it should simply be a case of copy and paste. It’s up to you how you do this, but I always recommend Google Docs which is a free online service which has all the features of Microsoft Word or any other word processor, but has the benefit of quick sharing and collaboration, without the usual headache of multiple versions of the same file floating around. This means as you’re writing content, you can share some sample pages with the developer to check it will work in terms of site and how you’re structuring it.

You should also look at collating any images or photography, so refer back to the wireframes and mockups to see what you need, and get them as high resolution as you can. A common question we get at Alloneword while developing a site is for image sizes. It’s not a silly question and very sensible to ask, but the truth of the matter is that we can’t tell at this stage while we’re still building and testing, as sizes may need to get tweaked as the development moves on. We wouldn’t want to give you a size for you to create 100 images just for it to be wrong. 

Receiving the test site back…

Test sites can go under a few names, such as a staging or UAT (user acceptance testing) site, but essentially there are all the same thing, which is a way of sharing, testing and checking the new website without disrupting or taking down the current one. Once you receive this link, it might have some of your content in, or just the homepage configured, and it’s now your time to enter content while testing it works for your needs, but also generally just works.

First thing is to see when you are getting training on the new system. It might be the case that no functionality has changed since your old website and therefore you know how everything works, but its more likely is there will be parts or all of it you don’t know how to use. It’s worth having this training as soon as you can so you can crack on with content and testing.

You may now be wondering why you’re doing testing. Shouldn’t they have done that? Yes and they will have done (in theory), but fact of life and development is that bugs in a website are inevitable, and multiple sets of eyes using the site in a variety of ways will catch as many as possible. They also won’t know what your final content is, so common issues clients find are to do with things like longer titles, images not all being the same width and height, and pages having an unanticipated layout. 

As you start to go through adding your content and maybe finding these bugs, ask the developer what’s the best way of raising them to ensure they all get looked at. Nothing can frustrate a developer more than constant emails and having to look through old email threads for multiple issues raised. Ask if they prefer a spreadsheet or if they have specific bug tracking software for you to use. As well as making their lives easier, it will means things are less likely to get missed. Be sure to put in the URL of where you’re seeing the issue, what browser/device you’re using, and (if relevant) the steps to take in order to replicate.

In summary…

As we talked about at the start, no-one is expecting you to write or fully understand web code  and that’s not your role in the project, we need to have visibility to it. The development IS the website, so we should be talking about it right from the start sin order for you know what you’re getting and the developers know what they are building.

Remember that the visual mockup stage is just a visualisation of what the website could look like, and there will be small differences in terms of alignment and font rendering on the finished article, so don’t spend too long on this stage striving for pixel perfection.

The modern web now also affords us a host of animations, techniques and interactions that really help set a website apart from another and carry your brand. Be sure to be involved in that discussion just as much as you would do on colour and image selection.

While development may not be your role in the project, content definitely is, so get cracking on that as soon as you can, and check with the developers it fits into how they are building it so the process doesn’t get slowed down towards the end.

Finally, testing is such a crucial part to any web project, and while the developers should be doing this firstly and thoroughly, it is everyone’s responsibility. Make sure you’re prodding every corner and almost trying to make it break. Bugs are a fact of life and you won’t have free support in years to come, so it’s cheaper to spot something now rather than a year later when you’re probably going to have to pay for the fix.