Our Web Design Process

Clients find our organised and structured approach to projects very reassuring. Whilst we don’t want to be too formulaic when it comes to the creative side of things, wrapping the overall project in a tried and tested procedure helps guarantee the project will come in on time, on brief and on budget.

To help you understand a little bit more about what a web project might involve here is a typical process from an ecommerce build. For the sake of argument lets says its an ecommerce website selling mobile phones.

Stage 1: Planning / strategy

Before we do anything in a project we decide on which project management tool we are going to use to organise tasks and manage communication. Sometimes a client will have a preference already based on previous experience which is fine, if not we use http://asana.com/product.

1.1 Consultation

No matter how good the brief is we always like to spend time with a client before we do anything. We like to communicate with as many different people within an organization as we can, from the CEO to the sales team. Getting these different viewpoints of what people need and expect from the new site is invaluable. We usually allocate 1-2 half day sessions for this.

1.2 Competitor analysis

We do this together with you as you will know your competition better than anyone. Always useful to see what other people are doing.

1.3 Current site analysis

Assuming there is an existing website we will always spend time analyzing the current web stats. This will tell us what users find most important on the site so we can ensure this is carried through to the new version. You would be surprised how often a clients viewpoint of what is important on the site differs from what user behaviour tells us is the case.

1.4 Scoping

The aim here is to specify everything that might be required in the project from start to finish (i.e. design, user testing, SEO, build etc…), and then each item is given a time/cost.

This process then allows the client to really understand where the budget is being spent and pick and choose around this. For example there may be a feature which is something you think would be nice but non essential, and you assume it’s pretty simple. If you can see that in reality this will cost 10% of your overall budget it’s an easy decision to leave this feature to a later stage.

It’s very rare that a client has more money than they need in a project and compromises frequently have to be made. What this process does is ensure that these decisions are made transparently by the client as opposed to us.

The result of this phase will be a sign off of the stage 1 functionality list and budget. This will effectively be the green light to go.

1.5 Key people

Now we know the projects requirements we can get everyone we need involved, for example SEO experts, designers, copy writers. It’s very important we get all of these skill sets involved as early on in the project as we can.

1.6 Timeline

A detailed timeline is now created plotting all key dates from now until launch. We tend to use this tool as it helps to visualize things better.

1.7 Client requirements

Much of the work in a project is for the client to complete, and these deadlines are as crucial to the final launch date as ours. Generally this includes things like compiling content and images, or meta data for the search engines.

We will provide you with a clear brief of exactly what’s required, as well as helpful documents like a spreadsheet to manage the SEO meta data.

Stage 2: Design

2.1 Sitemap & key user journeys

A working sitemap is created based on everything we have discovered so far (i.e. competitor analysis, site analysis, scoping etc…).

We then map out the key user journeys for our target audiences. These will be the most important things we want end users to do in the site. This will help us design the prototype/template, as well as create measuring devices for these journeys later on.

In our case for example we might focus on:

• How a user with a specific mobile phone in mind would find that phone as quickly as possible, be reassured it’s what they want it, and click to buy.
• How a user coming to the homepage without a firm idea about what to buy might be channelled to a “Find a phone search”, or indeed towards a product you ideally would like them to buy.
• Analysing the purchase process to ensure it’s as simple and reassuring as possible (to minimize cart abandonments).

Once we have these key journeys defined, we have the information we need to create the prototypes and some key test/goals to setup in our analytics software once the project is complete.

2.2 Prototyping (wireframes) & testing

This stage is important to any build, and it involves mocking up the basic outline of key pages in the site. Often these are created as clickable documents (usually PDFs), which can then be tested by real users.
Here is the software we tend to use, just to give you a flavour of what we mean.

So for example taking our 1^st user journey above (i.e. user with a specific type of phone in mind), we would need to mock up the homepage, product listing and product details pages. These would contain the necessary elements to make this user make the right choices, in the most efficient means possible, with the end result being them clicking the “buy” button.

We will then get real users (this can just be friends and family) to test this process by saying to them something like “Start here, search for X, make sure it’s the right model and it has good feedback. If so buy it”. We would be there in person to see what they do, and we can also video these sessions to examine later on (and show you).

Refinements are then made based on feedback and sometimes the wireframes are retested.

The value of this work is that very early on it tells you things like whether your navigation system works, and whether or not the priority of elements on a page is correct. This is particularly true when you test different user journeys and are trying to balance the needs of competing users.
i.e. someone with a specific product in mind will need very different tools to one who wants to browse the site or be guided by us; we need to make sure both users can use the site equally easily.

It’s very important that all these decisions are made and in effect proven to work before a graphic designer gets involved. It also provides a very clear brief for the designer and helps ensure that design is linked to the key business objectives, which wouldn’t necessarily be the case if a designer was purely concerned with aesthetics.

How far we go with this stage is dependent on budget and your requirements.

2.3 Concept

The graphic designer will now use the wireframes together with any other documents like style guides to come up with 1 or more concepts for the site. How many concepts we do is a personal choice and again something we will decide on during scoping.

2.4 Screens

Once a concept is agreed on the core screens will be designed; by this we mean the most important screens such as the homepage, search results page, product details, shopping cart process etc…

With ecommerce builds there does tend to be a lot more screens to design in full than with a standard website, it can often be 15-20 pages in total (a normal site would be more like 5-10).

If time is tight in a project we sometimes sign off parts of the site before others, so that the actual build of the pages can begin alongside what will be a lengthy design phase. If time isn’t a major concern we do recommend that all screens are designed before being built and signed off, because more often than not even if a screen is deemed complete, later on something somewhere else means it will need revision of some kind (it’s the nature of ecommerce sites).

Once these are signed off the build can begin.

2.5 Additional design work not critical to the main build

This might involve things like Facebook pages or Email templates to use for your email campaigns.

Stage 3: Build

I won’t go into great detail about this stage, it’s basically where we lock ourselves away in a dark room and build the site.

3.1 Alpha / Beta testing

Once the build is complete we begin testing. This will initially involve a small core group, and gradually involve other people. This is a very agile and intensive stage usually spanning a couple of weeks, involving daily fixing and testing. The result is a master spreadsheet all pages individually signed off

3.2 User testing

Its always worth testing your site on real users before its released into the wild. This can be done on an informal level involving friends, family and colleagues, but we also recommend we do more formal testing using real users with no allegiances to the project (i.e. your best friend is unlikely to be completely unbiased). Depending on budgets we can create real life user testing sessions on site, or we can use fully online services like http://www.usertesting.com/. In both cases we revert back to the user journeys we created for the wireframe testing and modify these to be applicable on a fully functional site. The result is a number of videoed sessions of real users using the site. Its a surprisingly scary experience seeing commentated videos of people’s opinions on months worth of your work, but the feedback we have received using these techniques over the years has proved absolutely invaluable.

Stage 4: Launch

4.1 Migration

Prior to the launch date the site will be migrated from the test environment to the live one. Basically all our sites are setup to have 2 environments, a live and a test one, both are separate applications and databases. So for example we will have http://test.mysmartphoneshop.co.uk/ and http://www.mysmartphoneshop.co.uk/. This setup allows us in the future to test and release new functionality on the site without affecting the live environment.

4.2 Launch

The live site will be launched, after which there will then be live testing.

Stage 5: Post Launch

Once the site is launched there will still be various tasks to complete, these will include:

5.1 Bug fixing

Any bugs will be logged and tracked using software. There is a standard 30 day free bug fix policy as part of any contract.

5.2 Analytics configuration

The analytics software we use (Google Analytics) will need setting up with any goals we want to measure based on our original user journeys. So for example we would set one up measuring how many people how hit the homepage end up buying a product. What this helps us do is assess if the design and functionality is successful at achieving our goal, and refine this over time.

5.3 Training

Any CMS training required will be completed.

5.4 Promotion / SEO

Much of the SEO strategy will be to implement once the site is built. Some of these will be immediate tasks like press releases, or making sure all pages from any existing sites 301 redirect correctly. Others like blogging and social media strategies will be longer term.

5.5 Additional functionality

Very often functionality not envisaged in the original scoping phase crops up during the build process. This is usually separated out into a separate stage 2 build process so as not to affect timescales for the main project.

Stage 6: Ongoing

Once a site is released it generally requires no ongoing maintenance and will operate indefinitely without any outside input. In most cases however websites are continually evolving animals and any such work is completed on an ongoing basis using our standard pay as you go support system.

6.1 Testing / analysis / refinement (optional)

Some clients like to spend time in the few months after launch (and longer term) testing and analyzing the site against its core goals. This is particularly relevant to ecommerce sites.

So for example it’s been discussed that we will look to create a more innovative way to help people choose phones (e.g. a funner way). We will need to find ways of assessing whether or not this method works, so we could for example setup a goal in the analytics software that measures and reports on how many people who start this “fun” way of searching actually end up buying a product Vs say people who use a more traditional route of searching.
This then allows us to make decisions based on this… if conversions from the fun way are 30% less than the normal route then we need look at refining (or scrapping) our fun way. Conversely if they are 30% better then we need to look at ways we can channel more users into using this method.

Another useful tool here is what’s called A/B testing. This is where we deliver different versions of pages to different users.
e.g. to 50% we deliver a page with a small blue “buy” button, and to the other 50% it’s a very big pink “buy” button.

This allows us to directly measure which version of a page is more successful in achieving our goals, and refine the site accordingly.

The one further thing to say about this kind of work is that it’s generally quite time consuming, as well as being fairly technically advanced (i.e. the analytical side of it).

Therefore we recommend the clients take on as much of the work here as they can. There will be a learning curve but in the long term it will be much more beneficial for the business for this knowledge to be internalised.

The other point in relation to this is that this work is not necessarily something you would undertake immediately, especially if its a new business, it may be something you do once the business is more established. One reason for this is that in order for A/B testing to be useful we generally need a fairly high volume of traffic (thousands of users). Testing on a few hundred users won’t be a properly reflective test, so its better we wait until this is the case.

The economies involved also rely on higher levels of traffic. For example A/B testing which improves conversion rates by 5%, might cost £1500 (this is a completely made up figure). This would be a much more cost effective exercise on a site receiving 10,000 users per day Vs 1000.

If you’re looking for a web design agency in Brighton contact us now to find out how we can help you improve your online presence.