We work with a large number of digital agencies, usually building websites based on designs that they’ve produced.

Almost all of these agencies are staffed by talented, creative people, and are a pleasure to work with. However, most of them also make the same mistakes time and time again, especially in the context of outsourcing work.

Here, in no particular order and broken into the three key areas of Visual Design, Project Management and Technical Tools, are our top ten.

Visual Design

1. Failing to produce working website designs

This has been possibly the greatest failing of digital agencies ever since I started building websites professionally in 2001. Just because someone is a great print designer, that does not make them a great web designer. It doesn’t even make them “a web designer”. Building a website requires an understanding of UI, of user journeys, of how a website works. It’s actually surprisingly rare that we receive designs from an agency that demonstrate this understanding.

To take some examples at random, we frequently sit down with a new batch of designs and immediately ask questions like:

What does that link/button do?

Don’t add any kind of link or button to a template unless you know where it goes, and what the next page looks like. I’m forever asking clients, “Where does that ‘Read more…’ link go?”, and even they have no idea.

Why is there a search box in the top corner?

Has search been agreed as part of the functionality? If not, don’t add a search box to the designs. (If it has, have you produced a design for the search results page?).

What happens when this form fails validation, or submits successfully?

Do add error states to your forms. Do make sure you include a “Submit” button. Do think about how the “Thank you” page will look. Don’t redesign form elements so they look pretty. Honestly, just don’t.

2. Failing to understand the difference between templates, and page designs

Most websites — especially CMS-driven sites — will be powered by a relatively small number of templates. For example, we may have:

  • The homepage
  • A “section” page
  • A “content” page
  • A “form” page (e.g., “Contact us”)

… plus templates for FAQs, news articles, galleries and so on.

When producing the designs for the site, you just need to produce one design per template. No more, and definitely no fewer. There’s no point producing several near-identical versions of the “content” template, unless each clearly illustrates how the layout will handle varying amounts of content.

Speaking of which, each layout must be able to handle varying amounts of content where required; don’t line everything up nicely with single lines of text, if the client is likely to use the CMS to add three or four lines of text to each panel.

3. Producing website designs in vector formats

A website is fundamentally made up of bitmap graphics. This may change in the future, if Canvas becomes more widely used, but for the time being, websites are rendered using pixels. This means that in order to reproduce designs faithfully on screen, the originals should also be bitmap images.

It therefore follows that the following file formats are not, in our opinion, entirely suitable for website design:

  • Illustrator
  • InDesign
  • Fireworks
  • PDF

It is just about possible to work from vector files like these. However, the resulting HTML pages will be an interpretation, rather than an exact reproduction. The design will have determined roughly where the elements should go, but the front-end developer will have to implement this layout as best they can, using (bitmap) images and CSS and so on. There is no point producing vector graphics and then complaining that a layout isn’t pixel-perfect *; this makes no sense whatsoever.

* Whether or not we should ever strive for “pixel-perfect” reproduction is another issue, but the overall point is still valid.

Yes, Illustrator might be “easier” or “quicker” than Photoshop, if you’re more familiar with the former than the latter. This is besides the point. If a front-end developer explained that he was going to use tables for layout, because hey, it’s quicker and easier as he hasn’t really used CSS that much, that probably wouldn’t go down well.

If you’re producing website templates, use a bitmap editor; Photoshop, Pixelmator, Acorn, Gimp, as you choose. Just not Illustrator. Or Fireworks. Or InDesign. Especially not InDesign.

Project Management

4. Failing to understand the concept of “signing off”

I have had the following conversation with agency clients about 100 times.

Me: So, are these designs the final versions? They’re definitely signed off?
Client: Yes! Pretty much!

Look closely; the answer the client has given above is, in fact, “No”. See also:

  • Yes! We just need to make a few changes.
  • Yes! All apart from pages A, B and C.
  • Yes! Their MD just needs to take a quick look.
  • Yes! Any changes from now on will be very minor.

The starting point of any front-end (and sometimes back-end) development will ideally be a set of complete, final, approved visuals. If this isn’t possible for any reason, that’s OK. However, everyone needs to be very clear that this is the case, and not cheerfully pretend that the design phase is complete, when evidently it is not.

Incidentally, when the design is signed off, and when the end client decides to actually bother looking at it properly two weeks later, and requests some changes, that’s no problem. However, if you’re outsourcing the build, these changes will take time, cost money, and impact on the overall schedule. Don’t just say to the client, “Yes, of course, easily done, no charge, we’ll do it today!” and expect your external developers to say the same to you.

5. Failing to produce a working schedule

It’s staggering how many companies are unable to schedule web projects. This usually begins with a failure to get the designs completed and signed off within any sensible period (see “signing off”, above). Once the designs slip, the entire project starts to fall apart.

Agencies also fail to get the actual content (text and image) from their client in time, leaving it until the last minute, and then realising that the content won’t fit in the templates produced. This is usually due to giving the end client far too much leeway; or, compounding their failure to get the designs signed off, and accepting content that is also “95% complete… it’s mostly there, just a few pages missing” and so on.

This rapidly descends into “beer-and-pizza” scheduling, whereby any sensible planning is replaced with a wide-eyed optimism, and the idea that an entire week’s work can be done in one evening if the Project Manager orders beer and pizza for the designs and developers. This may wash with internal staff (even if it still won’t actually get the work done), but when outsourcing work, your hopeful offers of food and drink are unlikely to be accepted. You just need a formal, realistic schedule that everyone sticks to.

I had the following conversation with a sizeable Manchester agency recently:

Client: We need the website live within ten days.
Me: But you haven’t produced a spec, or a site map, or any designs.
Client: Yes, X will be doing all that by the end of the week
Me: Well, it’s Thursday afternoon now. Will X really be able to produce all this, and get everything signed off by the client, for Monday morning?
Client: Yes, yes, but he’s just very busy at the moment.
Me: OK. In my professional opinion, based on where you are now, you will not launch this site within ten days. It cannot be done.
Client: Yes, haha! It is very tight! Haha!
Me: No. I don’t think you’re really listening to what I’m saying…

Again, beer-and-pizza scheduling. I contacted the client on the Monday to see how they were getting on. I never received a reply, and I suspect the project died a death.

Clear, realistic milestones are very easy to put in place, once you stop telling the end client what they want to hear, and instead telling them what can actually be achieved. In our experience, this leads to a much smoother project and ultimately a much happier client.

7. Forwarding client emails verbatim

An easy one, this. As an agency, if you’re outsourcing development work, then you earn your money by managing the client, and making sense of what they want — converting their wish lists into a clear, formal brief. If you’re just going to forward emails from your client, with the line “Please see email from client below!!” then you may as well not be involved; we’d certainly make a lot more profit if you weren’t.

This also often goes hand in hand with a failure to understand how outsourcing works. An outside agency, or a freelancer, is not just another member of your development team. Neither are they still responsible for maintaining the website years after the launch. Unless they’re charging a day rate, and have been booked to work on that specific day, you can’t just send them an email saying, “Please make this change to the site today!”. The question you need to ask is, “We’d like to make this change to the site; how long will it take, what will it cost, and when can it be done by?”.

Technical Tools

8. Using Excel as an issue tracker

The following is a list of people who need to use Excel:

  1. Accountants

You will note that “Project Managers” does not appear on this list. This is because Excel is a spreadsheet tool; it is not an alternative to Word when you want to use fancy table-based layouts, and it is distinctly not an issue tracker.

It always starts out fine, with one column for “Issue” and one comment for “Actioned yes/no”. Then you add another column for “Developer comments”. And another one for “Agency/client comments”. Then you need another column for “Developer response”. Then you decide it’s all getting a bit messy, so you add your comments to the “follow-up” cells, but in green. Then you highlight “completed” rows in yellow, and “urgent” ones in red. Then you add some more rows. Ignore the first three rows, though, the client has changed their mind. I think.

Excel hasn’t been an acceptable way of tracking issues since about 2002, and it was pretty crap then. Use Codebase. Use Basecamp. use BitBucket, GitHub, Campfire, Sifter. Anything but Excel.

9. Using Dropbox as the main file repository

Dropbox is great. It has many benefits, when used internally. However, when sending files to external developers, it is not (in our opinion) entirely appropriate.

External companies almost always need a final, definitive version of a file to work from, whether that’s a spec, a design, a content document or whatever. When this file can change at a moment’s notice, the concept of “signing anything off” (above) is lost.

If a front-end developer starts to build a design as HTML, you shouldn’t then update your Dropbox version with a new logo, and assume that the developer will monitor the folder, pick up the new version and change course. That is a process with no controls whatsoever.

Similarly, if you’re providing content documents, these should be supplied in (ideally) one single, signed-off batch. You can’t just create a folder called “Content”, and drop documents into it as and when you receive them, unless this way of working has been clearly defined in advance.

10. Using entirely inappropriate hosting

It’s amazing how often a client will give us details for the kind of hosting account that you might find in a Christmas cracker; a Crapspace Home User Plus account that costs £3.99 a month and doesn’t come with a database. If a website is worth building, it’s worth putting on a decent server. And for God’s sake, if you’re an agency, don’t let your client arrange hosting themselves, or we’ll be back to Crapspace — or worse, using IIS because Tim, their obstructive in-house IT guy, will only use Windows. Specify your hosting requirements and spend sensible money on it. Incidentally, Melbourne (based here in Manchester) are excellent.

As an aside, I’m forever being told that a client’s email is down, or that their emails are being incorrectly flagged as spam — or, I’ll receive an out-of-office reply every single time I email a client over the course of a week. Email is important. Find a reliable provider, and pay for it if necessary.

Since rebranding as an agency, we’ve had a general rule that we (almost always) ask a client what their budget is, before we provide them with a proposal or even costs.

This article aims to explain why, and the benefits that we feel that this approach offers.

A little history

When I first started freelancing, I’d reply to pretty much any enquiry, without any quality control. I’d put a lot of effort into these responses, practically writing a full technical specification for each one.

I eventually learned – and this took me far longer than it should have done – that there are some leads that will never lead to any paid work. Some “clients” literally have no money to spend. Others are under the impression that websites are cheap to build, and that they can somehow build a booming online business in their spare time, for an outlay of £500. Asking for a client’s budget immediately filters these people out; indeed, you’ll almost certainly never hear from them again.

Other clients do have some money to spend, but simply can’t afford the website they want. In such cases, asking them to define their financial limits immediately makes it clear if the project will be viable.

Some common examples

Over the past few years, two types of enquiry have been very common (and always without a defined budget in place):

“I need a website building, and it must have a CMS”

As a freelancer, I’d spend a long time compiling a list of questions in response. How big is the site? How much of it needs to be under the control of the CMS? Do you need to add pages, or just edit existing ones? How many users will the CMS have?”, and so on.

Now, by establishing the budget up-front, we can instead just advise the client on exactly how comprehensive the CMS can be, or whether a CMS is even a viable/cost-effective option.

“I’ve had a great idea for a project — it’s a bit like [insert name of large, successful website here]”

This was very common. I’ve previously been approached for websites that were “Facebook… for brands!” and (even better) “Facebook… for dogs!“.

In both cases, I’ve explained that these projects would need huge amount of planning and R&D, and that they’d be expensive. Facebook… for brands! didn’t even bother to reply, despite the fact that I’d taken the time to include some helpful pointers in my email.

Facebook…for dogs! explained testily that their budget was only £3k, but that they had now found an alternative developer, who had “the right attitude” and who could deliver the project within budget. One year on, I’m still waiting to see the finished website.

The client’s concern

Of course, the client’s concern is always that by stating a budget (say, £10k), they’ll receive a quote from their agency of exactly (or perhaps just under) £10k. My view is that this is exactly what will happen — and, exactly what should happen.

By setting out a budget, the client is asking “What can you offer me at this price?”. The onus is then on the agency to come back with the best possible solution, for that cost. If the solution meets all the client’s requirements, then any concerns about costs have already been addressed, because the solution already fits the budget.

The inverse approach, which is more common, is for the client to effectively say, “Here’s a summary of what I want; please go away and guess what I want to spend, and then give me a specification that meets that budget”. This is often counterproductive, as per the next example.

A better case-study

More recently, a project came along that illustrated exactly why a predefined budget is important.

We were approached by an organisation who asked us to pitch for the rebuild of their website. The project was going to tender, but they knew of us via an existing client and thought we might be a good fit.

I went down for an initial meeting, and the project (a large CMS job) sounded ideal for us. However, when I asked them about budget, I was told that there was no fixed budget, and the client was “looking for best value but doesn’t want to limit the project at this stage”.

It then transpired that another of our clients, a much larger agency, were also pitching for the work. After consultation, we decided to present a joint tender document. This made a lot of sense — they had a lot of resource, not to mention an existing relationship with the client, but were short on the specific technical know-how. We had exactly the right skills, but less resource.

In fact, the unofficial feedback I received from the client after our first meeting, was that that they had reservations about using such a small company. A joint proposition with a larger partner agency therefore seemed ideal.

However, after submitting a joint tender document, the eventual response from the client was that the cost we’d quoted was above budget — and what’s more, that most of the proposals they’d received were also too expensive.

Clearly, the client had in fact been allocated a budget for the job, but were reluctant to share this with us. This was a mistake for three reasons:

1. It wasted their time.

The client will have spent considerable time meeting agencies and reviewing proposals, only to find that they were too expensive. If they’d given a fixed budget, either the proposals would have been under budget, or some agencies may have chosen not to pursue the work.

2. It wasted our time

To an extent, this is the nature of pitching for work; we frequently discuss projects with potential clients (or, existing clients) that come to nothing. That’s part of the job.

However, in this specific instance, we spent a good amount of time with our partner agency, producing a proposal that was always going to be too expensive. The client sabotaged their own process by aiming to bring in a large company, but then balking at the associated costs. Defining their (limited) budget in advance would have made it clear that the project was too small for the larger agency. We could then have potentially pitched a more cost-effective solution ourselves, giving the client another option (see below).

3. It ultimately limited their options.

For our proposal, we pitched a comprehensive CMS that would have been very powerful and flexible, but one which came at a price. Had we known that they had a smaller budget, we could have proposed a CMS that was more limited, but which would still have served their purpose and have been affordable.

If the lower-cost solution had been insufficient, or weaker than the competition’s offering, then the client would (and should) also have rejected our proposal. However, they would at least have had a range of options to look at. Instead, most of the tender documents they received were out of budget, and therefore had to be ruled out — leaving them with presumably only around two or three suppliers to choose from.

If the client had been up-front about the fact that they did have a budget to work within, this would have all been avoided, to the direct benefit of the client.


In our experience, asking for a client’s budget up-front is very beneficial, for three main reasons:

  1. It filters out clients who claim to want a website, but who actually have no money to spend. (They actually just want to know what the site would cost, if they ever did have any money; the equivalent to having your house valued when you have no desire to move).
  2. It encourages other, genuine clients to think about their budget, and what they can afford, as opposed to what they want.
  3. It allows you to define a website that is the very best that a client can afford.

Most clients have been very willing to discuss budgets once asked, and all of our most successful recent projects have started in this way.

Fundamentally, pitching for work can all too often involve guessing what the client has to spend, and then proposing a site that you hope will be affordable. Asking for budgets up front inverts the process; rather than allowing the specification to dictate the cost, you allow the cost to dictate the specification.

… what a way to make a living.

I’ve been struck recently by the number of people in our Twitter stream who appear to be working ludicrous hours — up at six, still working at ten, and carrying on throughout weekends and holidays. For example…

Continue Reading…

When the BBC recently redesigned the BBC Sport website, a screen-scraping script that I wrote a year or so ago suddenly stopped working. While I was rewriting it, I thought I’d take the opportunity to improve it a little, release the code via GitHub, and write a blog about it.

Continue Reading…

A new blog

Chris Gibson  —  April 4, 2012 — Leave a comment

Despite being fairly late to the party, our recent adoption of Twitter has proven to be an effective new business tool. It’s led to at least one substantial project that would otherwise have passed us by, and generated several more decent leads.

In that spirit, I’ve decided to launch a blog. This will become either a useful output for articles and code samples that are too substantial for Twitter — or, another drain on our time that we will quickly start to resent. Time will tell!