Design Process. How the work gets done.

It benefits everyone if we can give our clients a better understanding of the design process. (There’s a lot more goes on than meets the eye).

Web design process

NB. Not every project will adhere strictly to the sequence outlined below, but the majority will at least follow it in a loose sense. Generally, the process of web design works like this:


Kick off! You contact us and brief us on your requirements. The brief is your statement telling us clearly and precisely what the design needs to achieve. The importance of having a proper brief from the outset cannot be overstated; it is is the key information that we will refer to throughout the design process to ensure that we’re doing what you have asked us to do. See our FAQs for more about why a good design brief is so important.

At some point (no later than the Proposal stage, see below) the brief will need to be formalised in writing. We can do that for you if necessary, but we would honestly say that a brief is always better if originated by the client. If you are not sure quite what a design brief should contain or how to go about writing one, the following links might prove to be of assistance:


An informal face-to-face chat (geography permitting). This can be done over the phone or by email if a meeting is impossible, but meeting in person is preferable by far. We will ask a lot of questions! This is to get as good an understanding as possible about your business, and about what you are looking to get from your web site. How many questions will depend largely upon the quality of the design brief submitted previously (see above) but web projects always need more than print-based ones because there are so many more aspects to consider.

It might seem tedious, but skimping on this vital preparatory stage is a terrible false economy; skipping an hour-long meeting now might add 100 hours of development time further down the line due to misunderstandings or poorly communicated information.

This Q&A process is also known as a Needs Analysis.


Based upon the brief, the needs analysis and our understanding of your requirements, Shark Attack will put together a written proposal, together with cost estimation and approximate timeframe. This will explain how we intend to meet (and exceed!) the project requirements, and to highlight the various ways in which we think our proposal represents excellent value for your business. This is presented to you, the client, and might take the form of a simple written document or of a pitched presentation, depending upon the nature of the project.

The proposal does not include ‘mock-ups’ or other such creative work.


You (hopefully!) accept the proposal and contracts are signed. At this point we ask you to make the required downpayment on the cost of the project. This is typically 50%, although for very large projects this can vary (see the FAQs page for further details).

Work cannot commence until contracts are signed and the initial payment has been received.

Concept & Scope

This is the point where we start to get down to the nitty gritty. In discussions between Shark Attack and yourselves, the project is defined based upon the proposal that you accepted. This means being clear about the site’s functionality — what needs to provide to its visitors, what they must be able to accomplish during their visit, what interactivity is to be built in, which browsers it must support as a minimum, whether it is a static site or a dynamic one driven by a database and a CMS, or whatever — as well any agreements about ‘concept’ (”it has to have a circus theme!”).

A document is drawn up stating what has been agreed. It is sort of a response to the original Brief and it is equally important; later on both parties can refer to this document and determine whether the designer has addressed all of the issues specified in the Scope, or whether the client has started to request extra functionality that was not part of the original proposal (a very common phenomenon called ‘Scope-creep’).


We conduct further research into your business, your competitors, and your market in order to better address the requirements of your business and your web site.

Content development

Normally this stage and the following stage, IA/Design, progress simultaneously and have a direct bearing upon each other. Information Architecture, for example, should be reasonably well worked out before content development begins, but as content evolves it might require a re-adjustment of the IA.


Design goes through several stages:

  1. Information Architecture

    The design of how the content of the site will be arranged and grouped, not visually on the page, but logically within the site as a whole. The Dewey Decimal Classification used by libraries is an example of one kind of information architecture. Hierarchical lists and flowcharts are typical tools used.

  2. Wireframes and prototyping

    Wireframes are the most basic of page designs, where content is represented in the most general way simply by blocks on the page. Buttons, scrollbars, menus, are all shown in the most generic way possible, with no colour used. The idea is to see how well the page works at a functional level without being distracted by any actual visual design.

    Prototypes are a way of turning these rough ideas into a testable format, either with paper or with an onscreen clickable form like a PowerPoint presentation.

    These prototypes are then used for early-stage usability testing to see how well the page layout copes with the ‘human element’.

  3. Visual design

    This is when the graphical look of the page is created, normally in an application like Adobe Photoshop. These static ‘page images’, in combination with the wireframes and prototypes, give a clear vision of how the designer envisages the site being used.

    It is vital that the design is ‘signed off’ (ie. officially approved) by the client before the development stage of the process as it will be harder to change later on.


This the point where we start to hammer out code and actually build the web site, its templates and, subsequently, individual pages. The code has to be constantly checked for Quality Assurance (QA), eg. cross-browser compatibility, validation, accessibility and web standards compliance.

At the end of the development stage we usually advise clients to invest in some more usability testing. This used to involve having access to a proper usability testing lab, putting it out of the reach of small businesses; thankfully that is no longer the case. At Shark Attack we use Silverback for our usability testing, which means that the process can be carried out for a tiny fraction (perhaps as little as 1%) of the amount that it used to cost.

At the end of the process the site is effectively complete, and we will ask you to sign off on the project, thereby indicating that you are satisfied with it. We will then ask you for the final payment installment prior to uploading the site files to your web server for the site’s launch.


Files are uploaded to your nominated web server, and a link check is performed to make sure that everything is plumbed in as it should be. Then we shout Hurrah! and everybody has a beer, or something.

Post launch

With the site live we will (optionally) arrange a maintenance plan with yourselves. A few weeks after launch date we like to contact the client and have a bit of a post-mortem to see how it is all working out. There are always lessons to be learnt, after all.


Selected work

Latest blog entries

Copyright © 1999-2017 Shark Attack. All rights reserved.