Archives For Code

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.

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…