Managing Web Projects #8 – The Design Process
Before you being to plan your design, you should first consider whether it will be:
- A full re-brand
- Web presence only
Whilst this will be set out in the Technical Requirements Specification (TRS), it will directly impact how you go about the design. For example, if you are going for a full re-brand you’ll have to come up with the colour scheme, logo and “look and feel” of the brand which you can then translate to a web format.
If you’re not doing a full re-brand, do you have all of the required graphics in the correct/usable formats? For example, you can scale down a 300dpi print logo but you can’t scale up a 100×100 pixel gif.
Make a checklist of all of the elements that are mentioned in the TRS – logo, colour schemes, font types, photos (client supplied and stock) etc. and list who will be providing it. That way you won’t be missing that all-important element half-way through the design process, your head is clear and you can start thinking about the design itself.
As mentioned in Managing Web Projects #7 – Sourcing the team and managing the project, design and development can happen concurrently. In this article I will be focusing only on the design aspects for ease of clarity.
Okay, can I get my pen and paper out and start scribbling?
Nope, not just yet!
As mentioned, the design basics will have been set out in the TRS. This will include items such as minimum screen resolution, accessibility requirements, basic site layout, functionality etc. which will all have to be taken into consideration before you can begin your design. Another factor that will have to be taken into account is the back-end coding and functionality, which are quite separate from the functionality of the design.
It is important that the designers understand the implications of the TRS and back-end functionality, for example there is no point designing a 100% flash-based website (which might look nice) when your core audience will be using a text-to-speech browser. The designers also have to take into account the functionality the developers will be adding to the site. I’ve been in several situations where a designer has come up with an (admittedly) wonderful design that the client loved, however it was completely unworkable in a real-life web environment.
Of course though, you’ve held your kick-off meeting so everyone knows what’s expected of them, right?!
Yes, we all know what we’re doing. Now can I get on with it?
Not if you want to do it properly!
Before the design process “proper” begins, it would be highly beneficial for the designer(s) to sit down with the developer(s) with a few rough sketches of the planned site’s layout so that they can discuss feasibility, usability and (most importantly) accessibility. There is no point after all having a designer design a fixed height page (not that any self-respecting designer would… right?) when the search results page is 3 times longer than the space allows.
Another point to consider when doing the initial design is the client’s existing brand image/style guide. The style guide can be part of the TRS or, as I prefer as it is a very “organic” document, a separate document. There isn’t any point in your designer designing a website in blue and orange when the client’s colors are green and yellow. Plus some larger clients have very (and I mean very) strict rules about logo usage, font sizes/colours etc.
One of my previous clients (who shall remain nameless for fear of being sued ), had strict stipulations on logo size, positioning – everything, even down to the white space around it – and whoa betide you if you got it slightly out of place!
Okay, I don’t want to get sued… what’s this “style guide” all about?
The style guide may be provided by your client’s design/PR/marketing agency or you may come up with one yourself. Even if it’s a one-man-band you’re working for, it’s always worth coming up with a style guide – it’s especially handy when they come back to you 6 months down the line for some updates and you can’t remember the font you used for the graphics!
A style guide should cover all of the major elements of the website (and printed materials if you’re doing a full re-branding). At the very least you should cover:
- Corporate colours
- Fonts (colour, face, size)
- Line spacing
- Text formatting (centred, justified, left/right aligned)
- Logo size
- Logo position
- Link colours, sizes, hover colours etc.
- Fonts for images (e.g. image headers)
- Heading sizes
- Minimum/standard image size, position, borders, drop shadow etc.
- Background colours
- Page Layouts (standard location of navigation, logo etc.)
There may be more added depending on the size and type of website and indeed, size and type of client but the above should be enough for you to start with.
If you are writing the style guide on behalf of your client, make sure they agree with it and sign it off before you go ahead otherwise you’ll have wasted a lot of time on a useless design!
I have my style guide… Now can I get on and design?
Yup! But you’re not going to do just one design are you?
It could be that the client has already come to you with a design template that just need tweaking, but when you’re designing a website for a client from scratch I prefer to give them three alternative versions of the design, this way they have a choice (and clients love it when they think they have a choice) and have an input into the design process.
I’m not going to go into the actual intricacies of design here, you can either design or you can’t (well that’s not true, I’m somewhere in the middle) and I’m sure there are much better, and more qualified sources than me out there. Anyway, this article is about managing the design process not about the design itself!
I’m Michelangelo when it comes to website designs, I’ve got my 3 – I’m off to email them to client!
Really? Where’s the personal touch?
How is the client going to understand why you put that button there and aligned that image to the left instead of the right? Guesswork?
Unless it’s physically impossible, I like to present my design ideas to the client in person so that we can discuss each of them, why certain things were done a certain way (due to usability, back-end functionality etc.) and what they like (or don’t like) about each design.
When delivering a design to a client, I usually present it on screen so that can see what it will look like in a “real world” situation, it’s all well an good carrying in an impressive looking A2 printout mounted on board but that’s not really how your design is going to be seen is it?
Take your time to go through each of the design options, explaining the process used to get to where you are now, this is important if a client starts saying things like “Why can’t that be here?” if what there pointing at physically can’t be anywhere else.
Make sure you make lots of notes (my article on writing good minutes may be of use), let the client say “I like that bit from that one, and that bit from that one” and if you can’t combine the two ideas, say so – and why – at the time.
When you’ve dissected all of the designs, go back and write up your notes. Annotate any important points (of why this is a good idea, why this is impossible etc.) and send a copy to the client and ask them if they’ve reconsidered any points, though about something different etc. When they come back, you can then revise your designs and begin the process again until they are happy (if they ever are!)
Argh! These revisions are doing my head in!
Some people are never happy unless they’re complaining, or think they’re in the driving seat.
Aspects of the development process will require the design to be completed (as mentioned in my previous article), you have to make it clear to the client that there are certain timescales that must be maintained.
You should really get a written agreement of when the design sign-off is going to take place by, this can (ideally) be in your contract, or clearly stated on the revision sheets (which you are sending to the client aren’t you?!).
The client should understand that if they faff about for ages “uming and ahing” over the design that deliverable dates will be put back (again, this should really be in your contract).
Some designers will do a maximum number of revisions, especially on a fixed price job, others will do say 3 free and the client must pay for the rest. It’s not really an issue if you’re on an hourly fee scheme, although the deadline issue still holds true.
On the subject of revision sheets, these are especially important not only for keeping track of the changes you have made but also for accountability – especially if the revisions are chargeable. The revision sheet should contain the following information:
- Date of Revision Request
- Revision Number
- Revision Requested By
- Revision Requirements
- Notes
- Time Spent On Revision
- Date Revision Signed Off
- Revision Signed Off By
- Date Design signed off
- Design signed off by
- Due Date
Hopefully you won’t have to go through too many revisions (although I did work on a project that went through about 50 – argh!) and the design will be signed off sooner rather than later.
Now, dependant on the type of designer you are (or have employed) will depend on whether you are in charge of building the site templates from your designs or not. For the purposes of these articles I will assume that the designer doesn’t build the HTML templates (as that’s what I’m used to!), which will lead us on to the next section, the Development Process.
Don’t forget to check out the e-book version!
- Follow Katy Whitton on:
