How do you do it?

Simple. Assuming you’re using a static page as the home page, try this:

function only_home_settings() {
// only add this meta box to the page selected as front page:
global $post;
$frontpage_id = get_option('page_on_front');
if($post->ID == $frontpage_id):
add_meta_box('Home', 'Home:', 'only_home_form', 'page', 'side', 'core');
endif;
}

// other meta box bits (form function and save function)

add_action( 'add_meta_boxes', 'only_home_settings' ); // ...add the action as normal, as well as other add_actions for this meta

It’s not always that simple, though. Sometimes your client (or you) is going to want users to download a PDF rather than open it in a browser window (which is the default position for most browsers) – especially if it’s a big PDF. Really big files are going to take an age to open in the browser and may well stop you doing anything else while they load.

Of course, the best way to get around this is, again, simple and gives the user choice: tell the user how big the file is (you can use something along the lines of filesize( get_attached_file( $post->ID ) ); in the appropriate place) and let them pick what to do.

But, again, you might not want to do this. For any number of reasons. So what do you do?

The easiest option is to use a .htaccess file in your uploads folder with rules like these. But from time to time this won’t work: IIS servers, some other kind of server settings. I recently came across this issue on WP Engine hosting, but neither they nor I know completely why just yet. So what’s the other solution?

First up, you’ll need to create a template or loop for the attachment itself, and link to this using get_attachment_link($attachment->ID); (possibly with some kind of checking so this only happens for PDF files) – you can put your loop into your normal template structure using:

if(is_attachment()):
get_template_part('loop', 'download');
endif;

In your normal single.php file, of course.

Now, in your loop-download.php file, you can do a normal loop, but this time include a hidden iFrame where the attachment itself will go. As the source of the iFrame, you’ll want to link back to the attachment itself, but this time add a query string saying something like "forcedownload=true" to the address (we’ll get to that in a second):

<iframe src="<?php the_permalink(); ?>?forcedownload=true" width="1" height="1"></iframe>

(You’ll need to hide this iFrame with your CSS, or you may end up with a little square on the page).

Right – you’re done with the attachment pages now. Let’s move on to header.php.

At the very top of this file (any spaces may well cause a “headers already sent” error) you’ll need to put the following:

<?php
if(is_attachment() && $_GET['forcedownload'] == 'true'):
header('Content-type: application/pdf');
header('Content-Disposition: attachment; filename="download.pdf"');
readfile(get_post_meta( get_the_ID(), '_wp_attached_file', true ));
endif;
?>

What we’re doing here is first checking that we’re on an attachment page and then checking that the query string is set… if we don’t do this, the download will start when we click the download link, and we won’t get the “if your download doesn’t start…” bit. By loading the attachment template first, then loading it into itself and forcing this version to download, we get to see whatever you’ve put in the attachment template as well as the download dialogue. This could be anything in addition to the “if your download doesn’t start…” text – perhaps a link to related downloads or something like that.

You might need to add some extra checks for different file types if you want to do them in different ways, and always be careful of your images linking to attachment pages… if you do this (and WordPress will do this by default) you may well run into some odd behaviours unless you check the attachment file type before sending those headers.

Let me know if you use this code by leaving me a comment!

I’ve been working for myself now for nearly five years. It was November 2006 I first registered for VAT, having done a bit of freelancing for a little while before that. I’ve loved every minute of what I’ve been doing since and it’s going from strength to strength. I’ve learned more than I thought possible and continue to do so. I never thought I’d fall in love with any software, let alone a content management system, but WordPress and I have ended up having an amazing and fulfilling relationship, albeit with the occassional argument about (metaphorical, PHP-based) toothpaste lids.

I’d like to say thank you to all the people who’ve supported me through the past five years; clients, suppliers, people I’ve met through networking (not least those at Cam Creative), friends (Lucy & Matt, Josie, Tracy, Nat and Michael especially, at various times), family, attractive waitresses at CB2, and those random strangers who pop up every now and then to give you help.

Over the last couple of months I’ve become extremely busy; lots of really exciting projects, including a couple of youth projects (one of which is the return of the brilliant Next Top Boss). I love being busy, of course, but this has gone to extremes and has meant far too many all-nighters, worked weekends and missed opportunities. On the plus side, I can get back into a pair of trousers I had given up as lost some time ago.

On the negative side, it’s meant a bit of a slip in the standard of service I can offer, which has been very difficult for me to deal with. I’m not happy if I can’t respond to your calls and questions as soon as they come in, and I can only apologise to those of you who I’ve not been able to do that for just recently. I hate working like that.

For that reason, I’m starting to make some big changes to Maltpress; we’re going to be going Limited, hopefully early in 2012, although perhaps timed around the start of the financial year. We’re also taking on some help.

Say hello to Clara!

Clara Bear is a very, very (scarily) talented developer I’ve known for 20 years or more, and is one of the few people I really trust to be able to produce the sort of work our clients deserve. She’ll be working with us on a freelance basis while she takes care of her lovely little son Sam.

Maltpress gets talent and greater capacity; you, our clients, get even better service, excellent WordPress (and other) development, and the same sense of fun and attention to detail you’ve come to expect. Clara’s poised and ready to take on some big projects I’m working on securing at the moment, and is also ready for anything new you might want to talk about. We’re especially keen to talk to people about pushing WordPress to the limit; using the excellent existing content management capabilities to produce some really cutting edge work. Combined with the brilliant design work of Mario at JDJ Creative, the hosting and infrastructure work of MDK Web and Media, and the other excellent freelance designers, developers, writers and consultants in our network, we feel ready to take on any WordPress project you might want to throw at us.

We’re also very aware that there are those of you with bigger requirements; not just web development or content, but also wider communications projects you might want to talk about. For that, we’re incredibly happy to continue working with The Foundry House, stunningly good providers of PR and communications services with some very exciting social media experience and ideas.

I’m also trying to think of ways to formalise the role of my dad, Andy, who’s been helping keep me sane with some paperwork in the run up to his retirement.It’ll probably involve paperwork, helping us become Limited, and helping me respond to you as quickly as I used to when I started out (and as quickly as you deserve).

All this extra capacity means I can take on far bigger projects, but I don’t want to neglect the little projects for start-ups (especially creatives) around Cambridge which I do for the love of the work.

What I haven’t told Dad or Clara yet is that in five years’ time they have to get tattoos like mine.

So last time we talked a bit about time management, and why Gantt charts – even simple ones – are a lot handier than you might think. But how do you actually do the doing? It’s not just enough to send your Gantt to your supplier and leave them to it – you also need to make sure you know what’s going on.

The good

A good web developer will send you regular updates on progress. Make sure you check with them at the outset how they deal with this sort of thing. It might be enough that they just email if they’re going to miss a milestone; it depends how time-critical your project is, how much you trust the supplier, and so on. If you don’t know them that well, agree with them at the outset that they’ll email you every Friday morning (for example) with an update on what’s done and what’s next. A lot of the time they’ll work hard for a while and have nothing you can really see – loads of technical set-up work, for example, which doesn’t show on the front end. Getting updates can put your mind at rest that things are actually happening.

You might be working with a couple of suppliers at the same time, in which case it’s (possibly) your job as project manager to make sure they all know what’s going on. There’s nothing worse as a developer than to expect a design, plan your workload around it, and then not hear anything about it for a week or more because the designer fell off his trendy scooter and no-one told you. If you’re managing the project, get everyone involved to email you their updates on the Thursday, then send the pertinent updates to everyone on the Friday morning.

The bad

You’ll get some developers – good developers, good workers – who slip up. We all do it. I did it recently; I took on a job which was interesting but had no budget, and because it had no budget I got complacent about project management, didn’t spec it, and it soon got out of hand. The natural reaction to this as a developer is to cut off communication, bury yourself in the work as much as possible, and try to push it through as quickly as possible, which I did; we all ended up getting really frustrated with each other for no reason, and a simple project took twice as long and caused twice as much heartache as it needed to.

Burying ourselves in the work is great in many respects, because it means that we’re actually doing it for you and want it cleared out of the way. But from your point of view, you’ve made one or two changes – which seem to you to be quite minor – and now your developer is in a strop and ignoring you. Shutting off communication also means that we don’t get the chance to discuss those bits of the project which are causing us issues – bits that you might not even be that tied to. When we’re trying to finish a project we can be of the mindset that “damn it – I’ll just do this extra thing and get it out of the way” when really we should be telling you the impact it will have.

Don’t panic; but don’t let us get away with it. The best thing to do with a quiet developer is to call them, on a landline if they have one, or on a number you’ve not called them from before if not (otherwise we see the number and suddenly we’re in a meeting…). Don’t get annoyed or upset; we’re working on it (hopefully). But do remind us of our commitment to you, ask if there’s anything you can do, if the spec is clear, and what the updated plan is. See if there’s anything we need which might help. Often, some real content – a product, an article, a content page – is a brilliant thing to send through because it lets us see what you want in context, and it reminds us that we’re actually working on someone’s business, not an anonymous project.

The ugly

There are, of course, those projects which reach a point which becomes impossible to salvage. Maybe your designer has overpromised – which can be a common cause of delays – or has taken on another project with a bigger budget which, sadly, has a bit more weight when it comes to deadlines (although in reality clearing the smaller projects first is a better way of working). Maybe they’ve utterly misinterpreted your brief, or just don’t care. Whatever the cause, if a project is dragging for months, or the changes you send through just aren’t done, tt might be time to sack your supplier.

First up, think carefully about whether it’s possible to salvage it. If it’s an agency, talk to your account manager or the owner and see if they know what’s up; it could be that they don’t, and can put someone else on your project or just have one big push to finish you off. Agency owners should care about all clients, big or small, because they know about reputation and repeat business; people working for agencies can often lose sight of the fact they’re working for a business which needs to care for customers. They just turn up, code, go home.

If it’s an individual, talk to them, and see what the issue is. If it’s a genuine problem they have no control over – bereavement, personal issues and so on – then discuss if there’s anyone else they know who could help out, and ask them to bill for what they’ve done so far and hand it all over (this might require some handover documentation).

It could be that all the project needs is a bit of clarity. Most developers won’t take kindly to the idea of coming in and sitting with them as they make changes; it’s too easy to say “oh, just try that font a little bigger… now smaller… now purple… now take the swearing out…”. What does help, though, is a clear end point. Make a list of all the things which are needed in order to get to a point that you’re happy enough with the project to move on. Refer back to the original functional spec. Set a clear deadline – first a deadline to get your developer’s agreement on what’s left and if anything is not possible, then a deadline to get things done. If they say something isn’t possible but it was in the original spec, explain that it was promised and that you’d appreciate that coming off the final bill. Make sure you check that what you’re asking in this final list actually was in the original spec; if not, then you really shouldn’t be upset that it’s not done by the deadline. Of course, by not adding to the spec in the first place you can – hopefully – avoid this situation. Always remember: the functional spec is the most important document in the project and is the final word.

If the issue is just that they’re rubbish and don’t care, and it’s clear nothing is ever going to get finished, try not to be too angry. Explain carefully what’s missing; calmly tell them that you’ve decided that it’s better for both of you if you move on and find another supplier; get everything you can from the supplier in order that you can hand it over to someone else. If they’re not prepared to give you any of the code, assets or work they’ve done then (with legal advice if possible – try the Citizen’s Advice Bureau or Business Link) you probably shouldn’t pay them. If they do hand over what’s been done so far, then pay for what’s been done, but don’t feel you have to pay the full project cost if the full project isn’t done.

Then draw a line under it and move on. Small business is an emotional thing. We put our hearts into what we do; when others let us down it’s easy to feel very angry and upset and hurt, and while this is perfectly justified, it won’t help you. Bad suppliers won’t prosper in the long run. Warn people off them by all means, but don’t try to get revenge; life is too short. Find a good supplier, spec it all clearly, and get it done.

Next time we’ll wrap up by talking about launching a site and what you can expect; we’ll also go through the ideas of soft and hard launches and why publicising a website launch can be a bad, bad idea. And also a good idea.

One of the reasons is an awful lot of WordPress dev work, and I’m hoping to share some of the fancy stuff I’ve been doing soon (the one site I know I can shout about is utterly beautiful, and does brilliant things). To keep you tantalised, I came across an issue today which is probably reasonably common but for which Google didn’t seem to want to help.

If you’re doing a navigation menu and calling it with wp_nav_menu you may well want to separate each menu item with a character; I seem to remember many acccessibility guidelines suggesting menu items be separated by a non-linking, non-css “divider” (i.e. a character not a border-left or border-right). Now, one way to do this would be to use css, an :after pseudo-element, and the “content” property… but that’s not supported by early IE (bleurgh!) and is a bit silly, accessibility-wise, because although it is actually popping a character in, it’s reliant on a stylesheet being loaded, so it won’t work for screen readers, etc.

You could do it with Javascript, too; but again, accessibility-wise, this isn’t a great solution, and the less Javascript you can do the better; it’s less future-proof, more prone to bugs (if your Javascript is anything like mine, that is) and again can be turned off by the end user.

The solution: custom walkers.

A custom walker basically takes the normal menu walker class (the thing which reads through the menu items and decides how to display them) and adapts it to your own crazy whims. In this case, we want to get rid of the standard WordPress <li> elements and replace them with a pipe, but only between each nav item, not either side, so it looks like:

Home | Another | Third item | Final

So here’s how:

First: register your menu in the functions.php file for your theme (here I’m creating a footer menu):

register_nav_menu('footer_navigation', 'Footer navigation');

Second: add the menu items, calling your new walker class, to the place you want them:

$footer_args = array(
  'theme_location'  => 'footer_navigation',
  'container'       => 'nav',
  'container_id'    => 'footerNav',
  'depth' => '1',
  'walker' => new Footernav_Walker
 );

wp_nav_menu($footer_args);

Finally: extend the normal walker class to create your Footernav_Walker (or whatever you call it) – see http://wordpress.stackexchange.com/questions/14037/menu-items-description/14039#14039 for loads more info and the original code:

class Footernav_Walker extends Walker_Nav_Menu
{
 /**
 * Start the element output.
 *
 * @param  string $output Passed by reference. Used to append additional content.
 * @param  object $item   Menu item data object.
 * @param  int $depth     Depth of menu item. May be used for padding.
 * @param  array $args    Additional strings.
 * @return void
 */
 function start_el(&$output, $item, $depth, $args)
 {
  if ( ! empty ($item->title) ) {
   $classes     = empty ( $item->classes ) ? array () : (array) $item->classes;
   $class_names = join(
   ' '
   ,   apply_filters(
   'nav_menu_css_class'
   ,   array_filter( $classes ), $item
   )
  );
  ! empty ( $class_names )
  and $class_names = '';
  $attributes  = '';
  ! empty( $item->attr_title )
  and $attributes .= ' title="'  . esc_attr( $item->attr_title ) .'"';
  ! empty( $item->target )
  and $attributes .= ' target="' . esc_attr( $item->target     ) .'"';
  ! empty( $item->xfn )
  and $attributes .= ' rel="'    . esc_attr( $item->xfn        ) .'"';
  ! empty( $item->url )
  and $attributes .= ' href="'   . esc_attr( $item->url        ) .'"';
  $title =
  apply_filters( 'the_title', $item->title, $item->ID );
  $item_output = $args->before;
  // the following if... statement basically ignores the first menu item
  // (so we don't start the list with a pipe):
  if($item->menu_order>=2) {
    $item_output .= ' | '; }
    $item_output .= "<a $attributes>"
    . $args->link_before
    . $title
    . '</a>'
    . $args->link_after
    . $args->after;
    // Since $output is called by reference we don't need to return anything.
    $output .= apply_filters(
    'walker_nav_menu_start_el'
    ,   $item_output
    ,   $item
    ,   $depth
    ,   $args
    );
   }  
 }
}

Ta da! Job’s a goodun’.

So, you’ve found your team, they’ve got the briefs and are working on creating you the website you need. Brilliant! Time to sit back with a book and a biscuit and wait for it to be done, right?

Well, possibly – if you’re confident that you’ve got a decent project manager working for you. If, however, you’re working with a couple of freelancers – a freelance designer and a freelance developer – then maybe you’ll not be so confident. It’s very easy for projects without a strong lead to stretch on and on, so today we’ll discuss some of the things you can do to avoid that.

One of the other problems you might come across without good steer is that you feel out of control. This can happen with a project manager in place, too; you’re investing a lot of money into this website, so you want to know exactly what’s happening with it, and when you don’t get constant email updates you start to worry. The problem with this, of course, is that if you start bothering your project manager (or the people on your team) constantly, they’ll very rapidly get very annoyed and possibly stop talking to you. We’ll deal with that next time, I’m afraid.

This time, though, it’s a bit theoretical – how do you plan a project, making sure you know what steps should happen when? What does your project manager actually do?

What a project manager does

A project manager makes sure a project hits budget, deadlines, and expectations. Simple as that. Give a project manager the functional specification and your agreed deadline, and you should get your project when you expect it – or at least a damn good reason why not. Good project management is not something which is forced on the people doing the “actual” work (the developers and designers) – it’s not about setting them tasks and holding them to account if they’re not done. It’s about finding out the steps they need to take, and how you as project manager can make these happen. Find out what they need, and make them happen. A good project manager is more like a project concierge – removing obstacles for the people doing their jobs so they can concentrate on what they’re good at.

How do you do this? A variety of ways, of course – different project managers have different techniques – but here’s how I do it:

The Gantt Chart

Ah, the Gantt. The bane of a project manager’s life. Many swear by them; many swear at them. So what is it, and how is it actually useful?

Well, a Gantt – in simple terms – is a visual representation of stages in a project, how long they take, and what job depends on what. The simplest can be done with pen and paper or in Excel (or other spreadsheeting software) using coloured cells. Complex ones can be done in MS Project (not an out-of-the-box Office product, sadly), or (my favourite) OmniPlan for the Mac, or there are lots of open source possibilities.  I’ve not tried any of these, though. Let me know if you have.

Now, you can do long courses on getting the most out of this kind of project management, or you can do what I do and use it in a nice, simple way. It’s something wonderfully visual and putting together your Gantt is one of the most useful things you can do just to get your own head around what’s involved.

Start off by listing all the steps in the order you think they should be done. You can use your functional spec and just list the functions here; or work with your developer to break it into the logical steps they might take. For example, you may have a calendar, blog, and shop on your site, and list them like that. You could also break these down into common tasks, like set up database, code back-end, code front-end… think about who this project plan is for, whether it’s your technical team or you (or the client).

Next up, assign durations to each of the tasks. Remember – this project plan needs to be created with the people doing the work. You can’t tell a developer something will be done in a week if you don’t know, for certain, that it will take that long. Also be realistic – remember the difference between billed time and working time. A 3-hour job might need to be done over 3 days if – for example – we’re working with DNS or getting approval for some online service. At the moment we’re not, however, trying to be too accurate; roughly assign days and half-days to tasks, and set milestones (steps which don’t actually take any time, such as “release to client”).

Now you can think about the most important part – dependencies. If you’re a chemist or biochemist, you should be familiar with the idea of the “rate limiting step”: the bit of a reaction which slows all the other bits up. This is kind of what we mean by dependencies – which bits must be done before we can do the next bit. Let’s use making a cup of tea as an example.

If I’m making tea, I have the following steps: add milk, add sugar, add teabag, boil kettle, add hot water, stir, remove teabag, drink.

Of course, we can’t do all of these things at the same time. But we don’t have to do each in turn, and there might be a logical order we can do these things. So let’s start by thinking of the things which are dependent on each other:

• Before we can remove the teabag we must add the teabag. We should also have added hot water and stirred.
• Before we can add hot water we must boil the kettle.
• Before we stir we should have added the teabag, sugar and milk.
• Before we drink we must have done all the other tasks.

So you can see dependencies starting to form here. You’ll also notice that some things are “shoulds” and some are “musts” – they don’t teach you about this on project management courses, but it’s real life. You can make a cup of tea – a very weak, horrible one – by steeping the tea in the milk, stirring, removing the bag and then adding the hot water. Bleurgh! But it is possible. It’s the same with a web project. You shouldn’t – really – build a website before you have an idea of the content or structure. But it’s possible, if circumstances force it.

Anyway, what you do end up with after linking up all the dependencies is that nothing needs to come before putting the teabag, milk and sugar in the cup; also, nothing needs to come before turning the kettle on. You could wait until the kettle has boiled to put these things in the cup, or you could do these and then put the kettle on. But then you’re sitting idle while the kettle boils.

So the logical way to do it is to turn the kettle on, and then while it’s boiling, do all the other tasks which don’t yet have dependencies which are not yet complete. Turn the kettle on, put the stuff in the cup, and then do the rest.

It’s exactly the same with a website. You could – and, if one person is doing it all, might have to – do all the tasks one after another. But you could, while your designer is busy pushing pixels, have your developer start on the back-end while you start writing the copy (which should always start earlier than you think as it takes twice as long as you’ll ever imagine and will always be the thing which holds up a project…). Front-end development is always going to be dependent on design being finished to some extent. But could you have a certain sub-page designed after the build has started? Could your developer be putting together a bit of functionality without design? A good site keeps design and content separate anyway – so there’s often no reason why not.

After you’ve got your Gantt, it just remains to get your developer to agree a start date, add in any time they know they’ll not be available, and make sure they’re agreed (in writing) that certain milestones can and will be met at certain times.

That sort of stuff is pretty logical and you should have thought of most of it already. But here’s something else to think about: for how much time do you let your team go “fallow” on a project? What I mean is, let’s say your designer has said it’ll take three weeks to get his bit done, and your developer has said he can start doing back-end setup right away and it’ll take two days. Do you set them off together? Maybe, but bear this in mind: your developer works for two days on a project then doesn’t look at it for over two weeks. Then the designs arrive and he needs to quickly get back up to speed again (having been off doing another project). Would it be better for the developer to start in week three – when the designs are nearly done – so he can have a straight run through his work in one block? Knowing the developer mindset, and the best way to code, yes it would. Think carefully when putting together your Gantt about using solid blocks of time where possible, rather than have someone on-and-off a project over a protracted period.

Helping to do the do.

Finally, the project manager needs to clear the way for these tasks to be undertaken as efficiently as possible. This might be a case of arguing with other project managers about who gets what resource (developer), and when; it might be a case of doing some of the dull jobs like data entry, or finding someone else to do them. You may need to source holding servers, or chase API keys, or any number of any other little jobs which take time, distract from coding, and might rely on a bit of diplomacy, tact, or low boredom thresholds.

Put it all together…

…and here’s what you need to do, step by step:

• Check the functional specification for what’s required from the project.
• Talk to each supplier about what they’re producing – design, front-end, back-end, copy. See what they need to be done before they can start. Draw up a Gantt without any dates on it.
• Check your Gantt with suppliers in terms of dependencies to make sure you’ve got it right. Get an idea of start times and holidays they might be taking. Some freelancers will work weekends too. If you are a freelancer, never agree to do this, or it becomes expected of you. If you do and you get it done early, great… remember the Scotty Principle.
• Finalise your Gantt by adding dates. Get agreement from each of your suppliers that they can and will finish each stage at a particular date, and let them know you need to know if this isn’t going to happen before the date it’s due. Tell them you’ll be after a weekly update email – even if it’s just “all on time” – and that you’ll remind them of this each week. If you’re reporting to someone else, make sure you summarise these emails to that person so they know what’s happening as well.
• Don’t hide, or hide from, problems and delays. Remain transparent. Tackle issues early. Stuff goes wrong all the time with every project. A good project manager is not one whose projects all run smoothly (because that’s impossible), but is one who solves problems, faces responsibility, takes all the blame and none of the glory but who goes home knowing that without them the project would never have been finished. Project management is not a popularity contest, to use a terrible cliche.
• Find out what each supplier needs in order to finish their tasks, and make it happen as soon as you can. Never leave anything until the last minute. You should always aim to finish projects early, just so you never finish one late.

Next time I want to talk about enacting the plan, which should be a bit more useful to buyers, because we’ll be discussing things like keeping track of milestones and how best to chase. In the mean time, anyone used any open source project planning software? Leave me a comment!

Last time we talked about briefing your designer. Now, briefing your developer is similar, but there are a few important things to remember:

• Design is subjective, but the technical side of your site either does what you want or it doesn’t. There should be less room for interpretation in this brief.
• Changing design on an established platform should be (reasonably) simple. Adding bits of functionality here and there (plugins) to an established platform should be reasonably simple. Get the platform wrong at the start, though, and you’re in trouble.
• Without a brief, you get scope creep – where you keep thinking “ooo, it’d be great if the site did this too…” – and your developer starts adding it – and then you think of something else – and your site never gets finished.

With this in mind, we’re going to be a bit more formal this time round. As with last time, I’ll use the features of this site as an example – I’ve put edited highlights in this article, or you can download a full PDF version of the brief. Newer versions of Adobe Reader should show notations in this file.

Now, this is all stuff that a good project manager (PM) will be able to help you with, and this is where they should earn their money – taking your ideas and turning them into a good, strong brief for a developer. For the rest of the post, then, let’s assume you’re not working with an independent project manager. Even if you are, though, it’s a good idea to understand this process so you can articulate to the PM exactly what you’re after. And finally… if you’re building a site for yourself, scope creep is an even worse problem, so writing a brief for yourself can be a great help.

Before we start, there is an easier way. Go to your developer, tell them the sort of thing you want, and wait for a proposal. If you do this, they’ll just go through (pretty much) this process, or repeat it from a previous client, and send you a proposal, which is pretty much writing your brief for you to agree with. Nothing wrong with this at all – but you get what your developer thinks you want, not what you know you want.

Step 1: what’s the point?

Going back to our very first post in this series, summarise for the developer what the site is actually for. Where’s the money?

You might want a site which simply says what you do. You might be directly selling something on your site. You might be giving something away for free to build your reputation, and this might be videos or text or downloads. Your site might actually be the product. Keep this description brief but try to cover everything the site needs to do. If you can’t summarise what your site does in a couple of lines, it needs more thought. Maybe it needs breaking up into different sites or you need to re-examine why you need it.

“The Maltpress site will be a portfolio of past work. We will use blog posts to build our reputation by demonstrating our experience of web project management, development and content creation. We will also sell – and give away – downloads through the site, mainly WordPress plugins”.

Step 2: break it down.

Now think about each thing that you want the site to do (you should have these from your design brief last time, and from earlier steps) and think about how it needs to work.

This sounds pretty technical, but it’s not. Your developer will handle how it really works; just think of the intermediate steps as a bit of a black box. For example:

Fill in contact form -> click "submit" button -> [clever bits happen]
-> form contents emailed to me -> user sees thank you message.

If you’re working with a usability expert, they’ll be advising you at this stage.

Don’t just think about the front end (the bits your visitors see) – also think about the back end (the bit you use to manage the site). You don’t have to go so far in specifying how this works, because in most cases you’ll be best using an existing platform like WordPress, Drupal, or something your developer’s already made, unless it’s very special functionality. You can break this out into a separate section (helpful if there’s more than one user) or keep it all in one lot (see the example brief).

What you will need to specify is how much of the site needs to be content managed. Remember this, though: the more you content manage, the more complicated it gets to manage, or the more expensive the system gets. The slider on the home page of this site requires me to know CSS, HTML and a little javascript to edit; it’s in the CMS for convenience, not simplicity. As a general rule of thumb, if formatting is utterly fixed, management will be easy.

Taking things further still, you might have lots of editors on your site and want to have workflow – i.e. a way to approve their content, track changes, that kind of thing. You might want different editors to have different permissions. Once you get into this realm, a meeting with a project manager to talk through all these issues becomes almost vital. If not, take your time, grab a big bit of paper and some pens and draw a flow chart for each user and their content – see the photo for an example.

Now, on this site, there’s only one editor, and pretty much every word can be changed via WordPress, from the footer to the slider on the home page. Some of it comes from other places… so the latest blog title in the header is automatically pulled in from the blog. Look at your designs and your pages and think about what you’ll need to edit, and how often, and also which bits are shared.

Break it down into common elements (things which stay the same across the site like headers and footers) and then by page type (home page, content pages, news pages, jobs pages, and so on).

So let’s do that with this site (see the PDF for more):

“Headers: the blog title and date should be drawn automatically from the most recently added blog post. The shopping cart will be updated when a user adds a download they wish to buy”

“Each home page slider should be editable. The background image should be uploaded via the content management system, and the content within the slider should consist of HTML and CSS added directly to the CMS.”

“All page body text should be editable using a WYSIWYG editor”.

(WYSIWYG stands for “what you see is what you get” and bascially means a text box with formatting tools like bold, italic and so on).

Note: you’ll forget and miss stuff here. You won’t think of everything, and your developer will have ideas about how to do things better. This is the way it should work.

Step 3: phase it.

There are lots of reasons you might want to phase roll-out of your website:

• You want something – anything – up quick because you’ve had business cards printed with your web address on (believe me, I’ve seen panicked examples of people doing this before they even owned the domain name…)
• You don’t have the funding yet to get all the functionality running
• You want to build buzz
• You want it up for a particular event but full development will take too long
• You want to use phase I to canvass opinion on phase II
• Phase II will be selling/promoting a product which isn’t ready yet
• You want to spread the cost and the risk.

Think about what’s absolutely core to the site and must be in phase I and what can go in phase II. If you only have a general idea what phase II will be (i.e. “there will be a forum in phase II”), still include it now – it might have an impact on decisions made at the start of the build. Divvy things up now.

Step 4: sense check.

Read what you’ve created. Look for gaps. Look for places where what you’re asking for could be misinterpreted. Ask someone else to read it and then summarise back to you how the site will work.

Step 5: send it to your developer and get your final proposal.

You may get questions and clarifications at this point, and you’ll undoubtedly get more ideas from your developer. You may also get an email saying certain things aren’t possible… they probably are, but just not within the time/budget you’ve got available to you. You’re perfectly within your rights to say “but I’ve seen it done on xxxxx site”. But your developer is perfectly within their rights to come back and say “but they have a budget of £5m and a team of 20 developers working in-house”. Be realistic.

Your final proposal should outline all the costs and timescales for the project. A couple of things to note:

• The proposal should be like a menu – this bit will cost this much, that bit will cost that much – so if something looks too expensive you can drop it.
• If something is costed based on days (i.e. “5 days at £350 per day”) that doesn’t mean it’ll be done in 5 days’ time. 5 days work – with other projects on the go – could take 1 developer 2 weeks, or 5 developers 2 days.
• It’s not uncommon for there to be a payment schedule – 25% up front, 75% on completion, or based on milestones. Never pay 100% up front. The impetus to finish the project and get paid is removed. It’ll take months.

I’d love to say how much your site will cost but – as you can see from all of this – every site is different and costs different amounts. As a very, very rough guide (excluding design):

• A flat site could be from £100-500 depending on number of pages and if there’s any Javascript. You might look to pay around £300-600 for very simple content management (one editable page, for example).
• Dynamic, content managed sites range from around £500 up (tens or hundreds of thousands for the really massive ones with hundreds of editors!). Generally, the more you pay, the more suited to your company it will be. Cheaper content management systems may have lots of quirks or fall over if you have lots (100,000+) of visitors. Try before you buy with any CMS if you can. For a decent site for a small business, look to pay £750-3000, assuming you’re just editing pages and a blog. Medium businesses can pay £10-30,000 for a good site.
• A store using PayPal will add from £500-2000 to your costs. Less if it’s built in from the start, more if retro-fitted, and the more you pay the better integrated it will be and the closer it will be to your designs. Pay more and you may get stock control and so on. E-commerce can cost a lot as there are lots of steps in the process to consider – carts, checkouts, various failed sales, refunds, stock control, previews, colour and size variations…
• Custom e-commerce can cost from £750-10,000. You’ll also need secure certificates, probably dedicated hosting, a merchant account with your bank… more products, more customers, more complexity all means more cost.

Basically, you get (in most cases) what you pay for. Get comparative quotes, check reputation, make sure you’ll have a good relationship with your supplier, and if you pay peanuts to a teenager to build something in his bedroom, don’t be surprised if it doesn’t work.

Step 6: the functional spec.

A functional specification (“func spec”) is a much more formalised, more technical version of your brief. The brief is what you want. The func spec is what you get. It should be pretty close to your brief, agreed with your developer, contain all those extra bits you agree at step 5, and is protection for everyone concerned. Get a site which doesn’t do what the developer agreed it would in the func spec? You have grounds to complain. Add something to your wishlist half way through the project and don’t formally agree it in the func spec? No grounds to complain.

Make sure both parties are in agreement with the functional specification before – in writing (by email or post) formalising this. All you need to do is say “attached is the functional specification for this site, as agreed by [client] and [developer] on [date] – please confirm your receipt and agreement”. Maybe not legally binding in the same way as a contract, but  good protection if (god forbid) small claims courts get involved. Please note: I am not a lawyer of any kind, I could be wrong.

The final functional specification may well add technical details you don’t need to know about. The developer or project manager may add these. Here’s an example. Technically (excuse the pun) this makes it a technical specification (tech spec), but for most day-to-day projects there’s no need for both. Read more about functional specs here.

Step 7: “oh, can you just add….”

So – development of phase I has now started and you’ve had a brainwave. Every page should have an animated cat doing a dance! You email your developer…

…and they either say (quite rightly) “never”, or they say “OK, but it will push back delivery by x weeks and add £y to the cost” or they say “let’s add it to the phase II wish list”.

The second answer is good. You know what you’ll get and the impact it’ll have.

The third answer is better. You have time to think it through properly, and it doesn’t impact your timescales. The danger with a developer saying yes to all these suggestions is that each one adds cost and time, and you end up with a site which never gets finished. Either that or the developer gets in to a hole where they never feel they can start to say no to your increasing list of demands, and the relationship breaks down…

Remember: once phase I begins, unless it’s urgent and vital and will save money and time, and only if it’s agreed in writing between all parties, the func spec doesn’t change. Things just go into the phase II wishlist, and at phase II, this all starts again…

Next time, we’ll talk a bit more about project management and protecting yourself from getting something other than what you want. In the mean time… developers, any thoughts? Leave a comment!

Writing a decent brief is probably the most important part of the web build process. Designers and developers – free-thinkers though they are – need to know what it is you’re actually after. Leave too much room for interpretation and you’ll end up with something which only just skims the edges of what you’ve got in your head. It’s also how prices get estimated and agreed, so to get a realistic idea of what it’s going to cost, you need a good brief.

There are several ways to write a good brief. If you’ve got the time and/or money, a project manager with web experience is probably best. They’ll sit down with you and talk about what you want to achieve from your site, your budget, what ongoing resources (time, mostly) you can commit to the site and so on. The agency you use may have a project manager to work with, and they’ll also sit down with you and discuss the brief first. If you’re managing the project yourself, it can be a good idea to chat with a friend about what you think the site should do and how it should feel.

Whatever route you go down, here’s how the design brief is written. Next time we’ll look at briefing a developer and creating a functional specification.

Get the principles

Before meeting with your project manager or agency for the first time (or even if you’ll be writing the brief yourself) start by making a mood board. At its simplest, this is an email with a load of links to sites you like. You could go as far as using something like PowerPoint (I use OmniGraffle on the Mac) or a big sheet of card. The principle is the same: gather examples of websites, colours, magazines, pictures and words which represent the things your site should be and do. Stick them on your card, take screenshots and paste them into PowerPoint, or email the links. If you’re working with a web architect or usability expert, you should work with them at this point as well, and include wireframes on your moodboards.

Now write down what you want the site to do. Keep it top-level at the moment – don’t try to think about the technical details. So, for example, for this site:

• There will be several pages of content on the site which explain what we do. The content won’t change on these very often.
• There will be a blog on the site. We will write posts hopefully every week. There will only be one author on the blog for the foreseeable future.
• There will be a contact page with an email form (which sends to my email address), as well as a map of our office location, telephone number and other contact details.
• The site will display the latest tweet from our Twitter stream.
• The site will include a store for buying downloads.
• The site will also provide WordPress plugins. Each plugin requires an introductory page, frequently asked questions, installation instructions and a download. These may change regularly as new versions are released.

That’s it… there are, of course, extra features on the site, but these came after brainstorming with the designer I worked with. At this stage you’ll meet with your project manager, designer or developer and talk about what you want, and they’ll help you clarify some of the details of these points, and maybe suggest extra features – your designer, especially.

Write a full brief

So at this stage in building this site I met with Mario, the designer, and we had a lovely cup of coffee and chatted about what the site would do. Mario suggested that the home page would look good with a big, sliding feature panel, and I agreed – and thought that this should be something I should be able to change using WordPress, not by having to code it fresh each time. We also agreed that the blog – while an important part of the site – shouldn’t detract from the most important part, selling services (and plugins).

From here, we were able to go ahead with the design of the site – we didn’t do a full written brief in this instance, because I work with Mario a lot and I trusted him to do what we’d discussed, and also because I was building the site myself and therefore cost wasn’t really an issue – it was only my time. We also skipped mood boards as we were starting from an existing design with brand, colours and imagery.

For you, however, now is the time to create a design brief. Here’s what to include, and some examples of what I’d do for this site:

• Introduction – write this last. Summarise what you’re after.
  “This brief outlines the requirements for the www.maltpress.co.uk website. The site will be built in WordPress by Adam Maltpress [include your developer's details at this stage so the designer can check technical details] and will include x, y and z [give an overview of the features].”
• Look and feel – if you have an existing brand, include examples of your current logo, colours, and any brand guidelines you have. Otherwise, try to summarise your brand and how you see this being presented visually.
  “The Maltpress brand is about building content-rich websites which are easy to manage. Although we work in WordPress a lot, we’d rather the site show how much further we can go than just blog templates – WordPress can do anything, and we can do anything with it, so avoid obvious references to the WordPress brand. Writing is the root of what we do and how the business started, and we’d like this reflected as much as possible. We enjoy our work and have a real sense of fun in what we do, with a tongue-in-cheek approach reflected by the use of retro, geeky black and white imagery from Flickr’s Commons. We would like to avoid any overtly technical imagery on the site so as not to alienate non-technical customers. The existing colour pallette is based around hex #29241E for backgrounds, #D3D0A7 for text, and #ffffff for links.”
• What needs to be on each page? Check back against your list (above) of the things the site should do. List what needs to be on every page, and what will have its own page, and what needs to be on those.
  “Every page will include a footer with phone number, email address, and other contact details. Main navigation will be on every page, and some pages will also include sub navigation. The site will feature a search box on every page as well as a shopping cart showing number of products in it. The Twitter feed will be shown on every page. Blog pages will show comments, and each comment will show the commenter’s image. The blog listing page will show just title, date and excerpt. The contact page will include a form and a map.”
• Outputs – what are you expecting from the designer? You should already have discussed this to get an indicative quote, but reitterate it here – your brief may not be a legally binding document like a true contract, but if you don’t draw up a formal, signed contract then it is a big part of protecting what you’re getting and what you’re paying for it. You should also check with your developer what they’re expecting to get – most will want layered PSD files, but check any further formatting requirements (ungrouped layers is a common request). You’ll need to specify how many pages you want designed – a home and sub-page layout should be enough, but if there are particular pages with special functionality, layout or importance, like store pages or forms, you may want these designed – otherwise your developer will have to interpret and create these pages from your home page design. Look back at your basic “how the site works” for any details here. If the design comes in under budget, consider getting more page templates designed – your contact page, blog comments, that kind of thing.
  “We would expect to see an initial round of three concepts [these may be reasonably rough around the edges] from which one will be chosen for further development. After three rounds of amends on the chosen design, the final design will be presented as layered PSD files with fonts supplied as separate files. The final design will be delivered as a home page and one content page, showing rollover state of one button and one link. [rollover states are how things look when you mouse over them - most of the time it's obvious, but you may want to ask your designer to show these. Menus are especially important, in particular where they'll have drop-downs]“
• Restrictions – you may want to reiterate restrictions from your brand guidelines here, or you may have other restrictions to put in place… for example, your wireframes or guidance from your UI expert. Bear in mind costs of things like fonts, imagery and so on…
  “The design should not use any fonts which require licensing for web embedding [if you don't have any existing design, this is a good clause to include to save yourself a bit of time and money later...]. Imagery used should be royalty free and available for use commercially on the web without ongoing costs. The site should stick as closely as possible to provided wireframes. Button/icons for download, contact and shopping cart will also be required.”
• Inspiration – include a list of links to sites you like the look of, send your mood board, and chat to the designer about things you like, visually… they might not necessarily become part of the design, but they’ll give a good idea of your aesthetic ideals.
  “We like retro (50′s and 60′s) Americana – take a look at I am So Retro for more. Cold War era architecture, Roman statuary, William Blake and black and white portrait photography are also great. Beautiful sites we like include Verle’s design site, Campaign Monitor, and Xero.”

With all that, your designer will now confirm costs – you may need to sacrifice a round of changes or initial design variation to get the cost down, depending on your budget. You can look at anything from £300 to £1500 for website design depending on the number of iterations, what you’re starting from, payment schedule, how well you know the designer… as an example, this site’s design – from an existing design needing an update, including three possibilities, three rounds of amends, design supplied as home page only (but with 4 slider image iterations which added some time) and quite a bit of extra input on structuring the site and how the home page should work – would cost in the region of £5-600 ex VAT, but may come in cheaper with a good relationship with the designer or if it’s an agency who’ll also do the building of the site – because things get easier to manage in that situation.

Next time, briefing developers… in the mean time, if you’re a designer, I’d love your feedback – anything else you want to see in the brief? Any examples of the best and worst briefs you’ve ever had? What else do I need to mention?

So, by now you’ve annoyed everyone you know by grilling them all about potential web designers, developers, project managers and agencies, and you’ve got a shortlist of people who might be able to do it. It might be a long shortlist, or it might be a very very short shortlist.

If you’ve only got one name on the list, then you’re either home & dry (if it’s someone good!) or in trouble (if it’s someone you’d rather not work with). If you want to add to this list, now is the time to go beyond your circle of contacts and do some Googling. Start with a specific, local search and check out the websites you find – take time to look through portfolios, and make sure they’ve got some up-to-date examples. Go through more than just the first page of results. You could also check out design portfolio sites like CSSMania if you’re less worried about working with someone local.

Remember what we talked about before – trust your gut, and don’t assume anything about prices from the quality of work or past clients.

One more little caveat: if anyone on your reccomendation list is a friend or they have another job but offer to do your site on the side… be careful. It could mean a project which drags on for months, with no-one prepared to properly manage it. It might not even be as cheap as you think – a side project like this can mean someone working with a technology or technique they’ve not used before and taking a long time learning. Always check that portfolio. In future articles, I’ll talk about ways to protect all parties in the process using contracts and basic project management techniques.

And now… let’s get trimming

To trim your shortlist down, we’re going to pinch some techniques from public sector procurement.

“Oh no”, I hear you say. “Public sector procurement is always expensive and gets it wrong”. Well, sometimes that’s true, but we’re not going to be as dogmatic in our process. What we are going to do is take some of the best aspects of the process and apply them in a flexible way.

The best thing about the procurement process is that the principle is to protect both buyers and sellers. It gives suppliers a chance to get the work based on their merits and not their sales patter, and it gives buyers a way to compare like with like.

Step 1: the PQQ

In public sector procurement, the PQQ – pre-qualification questionnaire – is designed to rule out anyone who’s completely unsuited. They’re normally just checks that companies have the right insurance, policies and legal status to be able to tender for government work. You don’t have to send out forms to your shortlist, but you can do some quick checks yourself just by visiting their website and/or sending a quick email. You might want to use the below, or think of your own:

1. Do they have a website themselves, and is it any good?
2. Are there any obvious signs that this is someone’s side project not day job?
3. Are there lots of typos, errors and glitches on their website which suggest a lack of attention to detail?
4. Does a Google search of their name reveal any complaints or past legal issues?

Hopefully – because everyone on your list should be recommended – you’ll not rule anyone out yet, but we can’t be too careful.

Step 2: the tender

Now, in the public sector process, everyone is given a long list of questions about past experience, capabilities, size of company, response to a hypothetical brief, day rate, that kind of thing… and these each have a certain number of points awarded to them. The person with the most points gets the job. This, of course, can sometimes mean the wrong person gets appointed, because they’re cheap and tick all the boxes with regard size of company, even though someone else showed real spark in their response and just felt right.

For your site, though, you’ll not be getting any FOI requests about spending public money, so you can be a bit more flexible, but we’ll still use the same techniques.

1. Email your shortlisted companies and see if they’d be happy to answer a couple of questions and give a response to a brief. It might be that some companies are too busy. Explain a little about the sort of thing you’re after – big site build, little static site, a bit of design, etc.
2. Now, for the ones who are happy to do this (hopefully all of them!), put together one email you can re-use for them all. Remember: you’re trying to create the most level playing field you can so that you can compare like for like. In that email, ask things like the following:
   1. What their hourly rate is. If they give a day rate, divide by 7 unless told otherwise.
   2. If they’re VAT registered.
   3. Ask if they’ll show you their last web project, and to give a brief (two paragraph) overview of the process.
   4. Do they use an out of the box or bespoke content management system?
   5. Do they have ongoing licensing costs?
   6. If you need hosting, ask who they use and what the costs are.
   7. Do they have a support package? How much is it?
   8. How quickly can they respond to changes?
   9. How many rounds of changes are included in a design cost? How many initial concepts?
3. Also in your email, set an indicative brief. This means you give all the companies exactly the same brief and ask them how they’d do it and how much it would cost. Make it clear that this isn’t your final brief but try to get it as close to what you want as possible. Include things like:
   1. The features of the site – relate them to existing sites if possible (i.e. “I want an event booking system like example.com”).
   2. Whether you have a design, or will be working with another designer, or want design included.
   3. How many visitors you expect.
   4. When you’d like to launch.
   5. Ask for a project rate with each feature costed separately and a rough timescale.
4. Keep it short and fairly simple, and ask for responses of no longer than a couple of pages. This way, you’ll not be asking people to put in loads of work that they’re not getting paid for, and you won’t have to read through loads of pages in response.
5. Set a realistic timescale for this… two weeks, for example.
6. Send this off… make sure you BCC rather than CC all the companies you email… and wait for responses.
7. If someone asks a question, consider sending the question and response (anonymised) to everyone so you’re not giving anyone more info than anyone else. Give kudos for good questions, though.
8. You don’t have to say how much your budget is, but if you do it does help. Big agencies might decide it’s too small for them and pass you on to someone they know, or there could be an expensive enterprise solution OR a cheaper small business solution you could have, so a budget helps us suppliers understand how to pitch it to you. Be realistic. Too low and no-one will touch it. Too high and people might take advantage. Stick to your actual budget – what you really can afford, with a little contingency money.

Step 3: Score!

You could get the responses back and immediately know who you want to go for from the quality of what they send. Good – that’s ideal. If not, you’ll need a scoring system.

1. Write the scoring system before you look at any responses.
2. Weight things sensibly. Price might be the most important thing, in which case they could score a possible 10 points in that category, while you might not care how quickly they get back to you on issues, in which case they could score up to 3 points for that.
3. You might want to score them on how easy it is to understand the brief. If it’s full of jargon they’ve not thought about how technical you might be.
4. Look out for obviously templated responses. Look for direct references to the brief you gave.
5. Now read through and score all the responses you get, and maybe get someone else to do the same so you can take averages.
6. If you want, ignore the scores and go with your gut. Your gut might pick the people ranked second.
7. Don’t take too long over this. If an agency doesn’t hear anything for a while, things could change. Let people know when you think you’ll have  a decision and stick to it.
8. Don’t expect original design concepts in a response. No-one should be expected to do a load of the work without getting paid for it. Also, at this stage the client won’t know enough about you… if they send designs now, consider the fact that you might be stuck with them (or variations!).

Step 4: relationship issues

Now you can tell the winner that you’ll be working with them. Yay! But don’t forget the others who put in a brief. Us agencies put a lot of work in to winning work. We really care about it and it sucks not to get a job. What we’d really like after this process is some honest feedback – were we too expensive? Did we miss something? What did we do right?

Make sure you thank everyone who responded. You never know when you might need someone else so every supplier you talk to – whether you hire them or not – is a really useful person to keep sweet.

And a final thought… we’re not done yet. The person you choose is probably right. But what happens if you start working with them and they come back with a ridiculous new cost for the full brief, or suddenly say some work has come in and they can’t do your project for another month? It might be time to consider number 2, so be nice…

OK – now you’ve found your supplier. Yay! Drinks all round. Next time, we’ll get in to the nitty-gritty of getting some protection and project management in place, and writing your first brief.

There can be a surprising number of different people (well, roles) between the stage you’re at now – having a fairly good idea of what your website will do – and the final, working product. What complicates things is that these different roles could all be done by one person, they could be done by one agency, or they could be sub-contracted out by the first person you hire. You might not even need all these roles in your site build! With that in mind, let’s do a big list…

• Designers. You’ll probably need one of these. You might not think so, though. There are lots of people out there (check out Clients From Hell for examples…) who think that a little bit of art experience is all you need. “My 14-year-old cousin can do Photoshop”, they may think, “so it’s easy. He can do it”. But there’s a lot more to web design than just the visuals. Have you ever been to a site which at first glance looks amazing, but when you start trying to use it you get completely lost? Buttons aren’t where you expect them, pages don’t have any consistency, what you think is a link isn’t… and then you get bits which look like they were forgotten and tacked on at the end by the developer. Well, that’s what happens when you have someone designing for you who doesn’t have proper web design experience.
  A proper web designer knows what “user experience” is. They’ll understand the term “UI” (user interface). They’ll know what a wireframe is, and have a reasonable understanding of what is and isn’t possible within CSS, HTML and Javascript. They’ll also know about licensing restrictions for fonts, images and icons you might want to use. Finally, your front-end developer will need things in a certain format and put together by someone who knows what they’re doing.
  FUN FACT: 100% of designers polled on Twitter like dark chocolate Hob-Nobs.
• Front-end developers. You’ll almost certainly need one of these. Remember last time we talked about HTML and CSS? Well, a front-end developer takes the designer’s work (which is usually a layered PSD file – i.e. each of the elements within it is on a different layer so they can cut them out easily) and turns it in to HTML and CSS. A good front-end developer matches the designer’s work exactly. A bad one cuts corners (or rather, doesn’t) and you get things square when they should be round, images when they should be text, and so on.
  Good front-end developers have an understanding of content management, too, and realise that certain things will and won’t be possible in the CMS and code appropriately. If you’re just having a flat site, your list of people should end here. Many designers are front-end developers and vice-versa.
  FUN FACT: When I do front-end development, I like to listen to AC/DC. Loud.
• Back-end developers.If you’re having a dynamic site built, you’ll need at least one of these. In some cases your back-end developer will be adapting a content management system which already exists, or which they built before and use for multiple clients. In some you’ll get something custom-built. Back-end developers will favour a particular language (like PHP) and if your developer works within an agency, they may favour a language or have different developers for different things. The back-end developer takes the front-end HTML and CSS and joins it up with the content management system or other dynamic goodies… so the good ones will end up with something which, to the end user, looks exactly like the flat HTML.
  A decent back-end developer will also think about how easy the back-end is to use; it’s very easy for developers to make systems which use technical terms (like Drupal’s “nodes”) and which content editors with no technical background struggle with.
  FUN FACT: the biggest bits of back-end development usually take place outside office hours, because that’s the best time to develop undisturbed. Office hours are for fixing things.
• Information architects/UI experts. Big sites will probably need one of these, and they’ll be involved early on. An IA is someone who organises things. Little sites might only have five pages, so you don’t have to think so much about how they’re organised. Big sites might have hundreds or thousands. How do users find what they’re after? What pages are most important for the users, and which ones do you want to push them to? How will the site grow? These are the things an IA will think about. You’d be surprised how much difference good information architecture can make. Think of any big site you use… they’ve probably used one or more IAs at some point.
  Similarly, a UI (user interface) expert looks at how users work with websites, and makes sure that design helps them do that. Where on the page should a buy button go, for example? What colours and shapes stand out best? How should a shopping cart work to make sure that as few people as possible give up buying? Even little things like the words used for navigation items can make a big difference to users and mean people stay and browse your site rather than get frustrated. For smaller sites, these things might just need a little thought. A good agency will think about these things for your back-end as well; the people working on your site content can be just as important.
  FUN FACT: Read “Don’t Make Me Think” by Steve Krug – the bible of UI and IA – to find out how important these things are, and how to apply them.
• Copywriter/content manager. Anyone can write, right? No. Good, engaging, informative copy which works with search engines, gets your customers clicking the things you want them to, is brief and flows well is not easy to produce. Writing for the web is a specialist field; the way we read on screen is very different to the way we read print, and so the way it’s written is very different too. People don’t start at page one of a website and work through in sequence, so your writer (who may well be an information architect too) needs to know how to take advantage of this. If you’re blogging or updating your site regularly, a copywriter on a retainer can be a real boon. Web agencies rarely have copywriters; most web copywriters are freelance.
  FUN FACT: if your copywriter doesn’t own Strunk & White’s Elements of Style, they’re not a real copywriter.
• Project manager. A big project will need a project manager to keep everything together, especially if there’s any sub-contracting going on. A big web project can rapidly get out of control without management. I’m afraid some of this might be because of you, the client; it’s very easy to think of something extra you want the site to do, and ask for it, and for this scope-creep to make the timescales and costs balloon. Good project managers save more than they cost in back-and-forth and scope creep. It’s entirely possible that your designer will act as project manager.
  FUN FACT: project managers come into their own when more than one supplier is involved, but don’t start bypassing them and talking direct to developers and designers. Things will get lost.

Put it all together, pick what you need

So, you now know who might be involved in your site build… let’s find you someone to do it.

To do this, I’ve put together a flow-chart you might find handy. You can download it here. (PDF, 149kb)

But let’s summarise:

1. In all cases, a good agency or freelancer won’t be precious about working with a designer, developer or project manager you’ve already picked, so feel free to pick and choose, although this might cost a little more. If they won’t split out the work, don’t work with them.
2. See the note below about full-service agencies.
3. If you want a flat site, a freelance web designer is probably your best bet.
4. If you want a dynamic site, and it’s not very big (10-50 pages), and your budget is limited, then you’ll probably want a freelance developer who uses WordPress or other open-source content management system, and possibly a designer. Think about using a copywriter.
5. If you want a dynamic site which is small to medium-sized (up to about 50-100 pages) or you have very particular needs – a complicated events booking system, an online store, that kind of thing – and you have a really good idea what you want it to do and some experience managing projects – then either a freelance developer who works with ASP or PHP plus a designer, or a small agency, will be best. A copywriter with IA experience will help.
6. If you want a medium to big dynamic site (100+ pages) with particular needs, a small to medium agency might be best, or start with a project manager with good contacts. You’ll almost certainly need an information architect and maybe a copywriter.
7. If your website is transactional (i.e. people buy through it, submit things through it, need to fill in forms) then you should seriously consider consulting a UI expert in addition to the rest of your team.
8. If your website is your main source of income, you need a project manager, a small to medium agency, a UI expert, and a copywriter. Don’t rush things. Don’t scrimp. You wouldn’t rent the cheapest shop miles out of town and spend an hour painting it yourself if that was your only income, would you?
9. If you’ve got 50,000+ visitors a month, you’re running multiple sites across the world, you need to link your site to internal systems, or anything like that, start with a medium-sized agency and work your way up.

So now… search away

So, the important bit… let’s find you some people you might want to work with. Next time, we’ll talk about actually picking from your shortlist, but first, let’s make a shortlist to pick from.

Step 1: ask people you know for recommendations.

Step 2: there is no step 2.

Seriously. Use your networks. Use the people you look up to. Remember those sites you looked at that you loved back in part I? Ask those people who did their sites. Ask the people you follow on Twitter. If you belong to networking groups, ask there. Ask your chambers of commerce. Ask your Business Link advisor. Ask me. Give a rough idea what you’re looking for – “I want a 10 page dynamic site, and I already have a designer. Any good developers out there?” – that kind of thing. Look carefully at the people who are recommended to you, not the ones who reccomend themselves (although don’t write them off).

Start by looking for a designer or project manager, because they’ll be the first person you’ll work with. A project manager can help you write briefs and pick more suppliers, while designers will have good networks of developers they like working with. It’s also easier to look at a designer’s work and see off the bat if they’re good at what they do, while looking at a developer’s site might fry your brain a little bit. Remember what I said last time about not writing people off if they look too expensive? If they’ve got big clients that doesn’t mean they cost the earth. Big clients have clout and buy using their own reputation, so they don’t pay as well as you might think – a big client is no indicator of the amount someone will cost.

Look locally to start with, because it’s really important to get to meet your team so you can talk in person about what you want. When you meet in person, you also get to see what they’re really like. Follow your gut a bit, like you would in any working relationship.

Look at portfolios. How recent is the last bit of work? Check it in different browsers, like Firefox, and on an iPhone or iPad if you can. Find out who did the design, who did the code, and if there’s a content management system.

Don’t just rely on Googling, unless you’re after an SEO agency. High rankings in Google merely tell you who’s good at getting high rankings in Google, which might indicate a bit of credibility, but don’t always guarantee good quality work. Use Google in conjunction with other things.

From all that, put together a list of five or six possibilities. Next time, we’ll talk about how to narrow that list down, and stealing some techniques from the public sector to do so.

Full service agencies… a controversial little warning

You might have someone doing your press and PR, your brochures and newsletters, and they might offer you a website too. You might find an agency who claim to be full-service. Alternatively, of course, they could mainly be web and dabble in the other things… or they could use an associate model or sub-contract all their web development work, in which case I don’t really count them as full-service agencies. You can ignore this warning for these people.

Think very, very carefully about working with them. Look very, very carefully at their portfolio. Ask their clients about working with them. Be wary. If their portfolio is full of pretty sites built in Flash, don’t touch them.

Full-service agencies are good at lots of things, but it’s rare for web development to be one of them. In most cases, they’ll have one or two developers who are mostly designers, who also work in print, who are rushed of their feet doing all sorts. They’ll not have the time to keep up-to-date with the latest techniques (any decent developer spends 10% of his time playing with things and learning). They’ll mostly work in brochureware. They may have a CMS they built themselves 5 years ago.

If you’re not careful, you’ll be locked in to using this supplier forever, as they won’t give you any control over the code and who sees it. They’ll veto anyone else working on the web with you. They’ll be very expensive for web stuff.

By all means – because if they do your other design they’ll have an excellent grasp of your brand – get them to do your web design and copywriting, but think very very carefully about bringing in a developer yourself.

And now a note on design competitions

You may have seen sites like 99 Designs, where you can offer a small amount of money and let designers fight it out to provide you with a design. You might think they’re a good idea. But they’re not, for a lot of different reasons. Firstly, you’ll not be getting anything particularly good, or original. It’ll be something a designer’s got laying around, either something they’ve used before but with different colours or something rejected by someone else. It may have licensed images or fonts used in it (like this logo example or these examples). The decent designers won’t touch this kind of work because they’ve been messed around too much by people not willing to pay the right amount for decent work.

Second, you’ll not get the standard of service you’d get from a good designer you’re paying the right amount. You’ll never meet them, you’ll not get the follow up. Suddenly need a different format version of an element on the page for print? You’ll never get that from your 99 Designs “designer”.

Good design is something people study hard to learn, practice for years, and invest huge amounts of effort into (as this designer attests). It’s worth paying for, and – as with everything in this world – you do get what you pay for.

With thanks to @stevedesigner on Twitter