5 Golden Rules

Having been working in the interactive industry for over ten years, I have produced countless projects and learnt many lessons. Over the years, I’ve formulated five key rules that I always stick to – they help me and my team plan, implement and deliver projects successfully and avoid unnecessary problems. They’re not just relevant to Producers – they’re useful for anybody involved in the web development process so I always make a point of sharing them with new Fi recruits.

Avoid assumptions

This is my number one rule. People naturally make perfectly honest assumptions throughout projects, but in the interactive world, this can be very dangerous: “I assumed this site would work in IE6 as well as it does in IE8”;  “I assumed we wouldn’t need to include any functionality from the previous site”; “I assumed that you would be doing all the content input”…

Sometimes even the smallest details can make a huge difference. In most cases, your client is not an expert on interactive development (that’s why they hired you!), so they won’t understand the impact of incorrect assumptions as clearly as you do. So it’s utterly vital that you proactively catch assumptions before they cause disappointment or misunderstanding further down the line. In fact, when discussing project requirements, I find it’s often helpful to specify what the project doesn’t include as well as what it does.

Work for the project, not for yourself

As an interactive agency, you build websites and applications for your client and their target audience. You’ve also got a timescale and budget to meet. So it’s super-important never to lose sight of these primary factors.

As passionate designers and developers who are constantly striving to excel, it’s always tempting to design in a style you’ve recently been inspired by, or to try that new technology, or build that ultra-reusable dropdown you’ve been planning for months. But always, always, ALWAYS think about the goals of the project first. If you’ve got two weeks to build 10 components, is it really wise to spend the first week over-engineering the first one? If you’re designing a site for a law firm, is it really appropriate to practice your grungy Photoshop brushwork?

Never launch on a Friday!

This is an obvious and well-worn rule – don’t put a site live when nobody’s going to be around to fix post-launch glitches the next day. But there’s a bigger topic to consider here, and it’s that websites are complex, changing things that require constant nurture. It’s not like a printed brochure or a broadcast TV ad, where you can finalize your end product, “freeze” it and then know it will be the same for everyone who experiences it.

You have to expect bugs and unexpected issues, no matter how stringent your QA process – simply because the web is such a non-standard environment, your users will be viewing your site via a huge range of devices, connections and browsers. So plan for this – if you are going to make a big fanfare about your new site, quietly put it live a few weeks beforehand, and let it bed in before you make a “big bang”.

Don’t underestimate content

Whenever I hold a kick-off meeting with one of our clients and we discuss timelines, I always say “we’ll meet our deadlines, are you sure you’ll meet yours?”. I say this because the thing that delays web projects is nearly always the content itself.

People often get excited about a new site’s design, or technical implementation and forget about content until the last moment. One of the key problems with this is that by the time content is properly considered, you realize that it has implications for the design and the implementation. “Content is king” might be a cliché, but it’s true; it’s the essence of the website and should be considered from the outset.

A classic example of how things can go awry is when features are designed and built around “placeholder” content, but can’t accommodate the actual content when it’s finally produced, and hence there’s an ensuing period of frantic changes to both code and design.  Content also takes a long time to get right – it needs to be written, approved, put in place and then often revised again once it’s in situ. At Fi, we also routinely build sites that offer content in many languages, and this offers a whole new level of complexity (what happens when your iPhone app needs to be translated into Russian and Mandarin?).

Make sure that content doesn’t ever get pushed to the back of the project queue.

Things change

This is one of my personal favorites and something I bang on about time and time again. No matter how well you think you’ve planned a site, no matter how tightly you’ve specified the requirements, or how much pressure you’ve applied to get sign-off, never make the mistake of thinking things can’t or won’t change. Websites change. That’s what they do. Requirements shift, decisions get un-made, people change their minds. The previous rules in this article are all designed to help ensure that changes aren’t unexpected, stressful or unnecessarily complex. But nobody has a crystal ball – sooner or later you or another member of your team is going to need to revisit that design or that code and make some changes. Get used to it, get over it, and design/build your sites with change in mind. 

What do you think of these golden rules? I’d love to hear your thoughts and maybe some suggestions of rules you swear by. If you’re a Producer and know these rules like the back of your hand, why not come and work with us?

Regards,

Tom 

Fi is a multi award winning global interactive firm and production studio. With offices in Europe and the US, Fi caters for brand leaders such as Google, FOX, HTC, BBC, MTV, Nintendo, Porsche, Burton and more.