The path to a great website or interactive tool can often be a rocky one. Rachel Collinson shares some insights from the agency perspective on how to get the result you need, on time and on budget, AND have a happy relationship with your suppliers.
You probably already know this: web projects are tricky beasts.
Why they are tricky beasts is more difficult to ascertain. I’ll take a stab at it, though.
Let’s see… collaborating on a half-decent web project usually requires skills in psychology, design, engineering, linguistics, marketing, management, detective work, copy-writing, statistics, programming, negotiation, planning and, frankly, plenty of patience and positivity.
In real terms that means a team of super-polymaths, and a need for mutual understanding between client and web agency. Oh, and did I mention a versatile sense of humour?
Before you panic and begin to think about changing jobs, let me make you a nice cup of tea, sit you down on our comfy sofa and explain how you can make life a lot easier for yourself and your web agency.
One way to guarantee your shiny new web project goes gliding merrily down the sheer slope of missed deadlines (and usually right into a ditch of disappointment) is to start with an unclear brief. Allow me to demonstrate this fact by imagining that you’ve paid £100 to enter a painting competition. (Bear with me here… this will make sense eventually.)
The rules of the competition, announces the organiser proudly, are that you have to produce the best painting in the world.
“How will the competition be judged?” you quite sensibly ask, while enjoying thinking about what you might paint.
“We’re not really sure yet.”
“Well, can you tell me who will be judging the painting?” you say.
“Hmmm, well, I think there will be some people picking the best one.”
“Are there any restrictions on size or type of painting?” is your next question.
“I’ll find out and get back to you on that one.”
You begin to wonder why the competition is actually running, and after a bit of a pause, ask:
“Uh, so, what’s the deadline for entry?”
“In 3 days’ time.”
At this point, you start to panic a little.
“And, am I allowed to ask what the prize is?”
“Oh, I can’t tell you that,” responds the organiser. “You might want to win it all.”
You now regret stumping up the £100, question your own sanity, and if you’re honest with yourself, feel like plotting to involve the organiser a little too closely in some action painting.
Maybe I’m being a little unfair here, but this is what it feels like at times as we try desperately to craft a thoughtful response to the vague or incomplete briefs that regularly arrive in our inboxes. We wind up playing a frantic and risky guessing game about the project aims, constraints and size, among other things.
If we guess wrong, we’ve lost out on the chance to work with you, as well as wasting a great deal of time which could have been spent on other worthy projects.
If we guess right, it’s possible that our initial elation may turn to regret as the constraints of the project gradually become clear, and realisation dawns that the aims are unachievable. In some cases, it can become a sad scramble to rescue something of worth from a tangle of conflict.
Let me tell you a little secret: most people who run web agencies in the third sector aren’t doing it for the money. We’re doing it to make you successful and happy, because that’s what makes us happy. If we wanted to prop up our monitors with wads of crisp £50 notes, there are plenty of markets out there who would gladly pay us six-figure salaries to waste our lives for no good reason. Charity web development offers us something different; the chance to produce worthwhile things with our own hands and see them have an effect.
When projects are successful, it’s an extraordinary feeling. That feeling is what we strive for and we can only produce it by helping you achieve your aims.
One of the main questions that will be playing over and over in the back of our minds when we decide to respond to a brief is: “How likely is it that this project will achieve its aims?” and “Will there be any restrictions on our contribution to its success?” If we can see some definite criteria for success, and there are reasonable (or even somewhat demanding) expectations for the project, immediately we’ll start imagining how we can make that happen.
The dream brief
So, how can you craft a brief that will attract the good guys and create a solid foundation for success? There are 3 basic subjects that you need to think about:
1. Aims
2. Constraints
3. Response required
Any brief should cover these things as simply as possible. If you want a sort of mantra to repeat to yourself about writing a brief, “aims, constraints, response,” would be it.
So, let’s flesh that out a bit. Here’s a pretty-much-complete-as-I-can-make-it list of the components of each subject. The result would be our dream brief. (Here at Rechord, anyway. Other agencies are also available.)
Aims of the brief and the project
It’s quite confusing to us that so few web briefs mention the aims of the project, or mention them only in the vaguest terms. This is the most important part of the whole brief. Without it, we’re lost.
All you need to do is tell us in a few sentences what success would look like for this project. How will you measure it? Do you need something cool to impress your boss (go on, admit it) or will you be judged by the number of people taking action through the site or application? There are lots of other success factors that we have come across, by the way. Not all of them are obvious.
We did have one memorable project where we gradually realised that success depended on one director’s husband saying that he liked the design. If only we’d known that, we’d have saved a lot of fuss.
So, think carefully about your aims and tell us what they are.
Here are some related things we need to know about:
Why are you sending out this brief?
This may be better explained in a covering email rather than the brief itself, but it’s worth discussing here. Why does this brief exist? Is it so you can make an informed choice of web agency? (If so, how many agencies are participating?) Do you need to verify your budget? Have you already chosen your web agency and you need some proposals in order to sell the idea internally? There are different reasons for web briefs and sometimes the process of getting from initial idea to pressing the ‘go’ button is uncertain. Explain what you’re expecting.
Target audience
There’s one way to make your web agency’s heart sink, and that is to say “our target audience is everybody”. Design projects will generally collapse in ruins if they have the broadest audience possible. (If you don’t believe me, observe the head-shaking that goes on over the design of pretty much any Olympic mascot.)
A project that wants to please everybody will likely be so bland as to be virtually invisible. So, the closer you can get to narrowing down your target audience, the better.
How will people find out about the site / application?
This is the most often neglected aspect of briefs we have seen. There is an unspoken assumption that websites will generate traffic just by existing. Your web project is not a baseball pitch in a corn field with ghosts of famous dead players. You cannot “build it and they will come”. (Apologies to the director of Field of Dreams.)
Unless some sort of attention is paid to functionality which draws in more traffic, or there is a promotion plan, your website’s visitors might just be limited to people in your organisation (which might be alright, if that’s your aim).
If you’re expecting your web agency to be responsible for generating traffic to the website by promotion or design, please make that explicit.
Wish list of features and the reason for each one…
…preferably in order of priority. This is the most common component of any brief, and it’s honestly ok to have a wish list rather than a full specification.
However, we often receive wishlists like this: “The website must include: video, podcasts, blogs, integration with social networking websites, a Twitter application and a shop.”
A lot of these features could mean virtually anything, and could range in cost by tens of thousands of pounds, if not hundreds. (Your neighbour’s Ebay store is a shop, but so is Amazon.co.uk. One cost nothing to set up and took about half an hour, the other cost several million pounds and an entire decade. Just writing the word shop will not create a reliable guide to cost.)
We understand how it is with web projects; often it’s difficult to know exactly how you want each feature to work at the outset. That’s where we love to help out, and we have a process in place to help you discover that as the project moves along. BUT without knowing why each feature is needed, we’re at a loss to understand how big the project is and therefore how much risk we would be taking on.
How will your staff use the website?
This overlaps with the wish list of features to a certain extent. However, I’m including it because there’s one crucial aspect of web applications that often gets left out of briefs, which is site administration. In the rush to focus on visitor experience, many organisations forget to think about themselves and their internal needs. For example: how will you edit and maintain the website or application? What data will you need to get from it? Will you need moderation? How will you interact with your visitors? These sorts of questions can add time and cost to the project, and your web agency needs to know about them.
What’s the background to the project; why has it been deemed necessary?
We sometimes discover during the process of development that a web brief has been written in order to solve some kind of organisational problem which should have been addressed in a different way. For example, a project to build an online discussion area could instead be a cheaper and less risky series of face-to-face meetings with distributed notes.
Knowing why you think a web application is needed will help us to understand whether other, more cost effective things could be substituted.
What is the lifetime of your web project?
This allows us to plan for either:
- maintenance and ongoing development if the project is expected to be around a long time;
- or if it’s a transient thing, a neat close-down which sends users away feeling happy and fulfilled.
If you plan to close down the project, but reuse the code later on, we need to know about that too.
Constraints
Budget
Ah yes. The budget.
We understand the fear of laying your cards on the table. We’ll suck up all the budget no matter what happens, right?
Do I need to prove that we’re not all money-grubbing monsters who like to waste supporters’ donations on cigars and caviar?
That might be get a little too personal for my liking, so let me talk you through what happens when no budget is supplied for a web brief:
Scenario A: The brief is vague, and we don’t know it yet, but your budget is lower than it should be for the expected project. You may get a disturbingly wide range of costs back from web agencies, each for vastly different functionality. It’s impossible to make a reliable decision based on such different responses.
Scenario B: The brief has a detailed specification, and your budget is lower than it should be. In this scenario, unsurprisingly, the responses you get back will be way over your budget and you have to close the project due to lack of feasibility. This is the fastest route to annoying your potential suppliers, who will collectively have wasted thousands of pounds creating a proposal for something which was never possible.
Scenario C: The brief is either vague or detailed, and the budget is higher than it should be. In ten years of running a web agency, I have never seen this happen.
To avoid the fear over making the wrong decision, and prevent frustrating your suppliers, you do need to supply a budget. And if there does happen to be a money-grubbing monster in among your chosen web agencies, they’ll be easy to spot by a discrepancy in features or a hesitation over references.
Any deadlines (and why)
Of course, we need to know about any deadlines you have, but it does help to know why those dates in particular have been chosen. Do you have a launch party booked? Are you expecting thousands of visitors from a particular ad campaign or TV spot? Do you have budget to spend in a fixed timeframe?
Any applicable legislation
In the UK, this usually means the Data Protection Act and the Disability Discrimination Act, but there may be others which apply to your situation. Other countries have their own equivalents which have different guidelines. If you can, take legal advice and tell us how you would like us to fulfil the requirements. We are able to make suggestions, but we are not permitted to give legal advice.
I know, I know; nobody likes talking to lawyers, but it’s better than being fined. Sorry; I wish I had better news for you.
Accessibility requirements
What kind of devices and software do you expect people will use to browse the website or use your application? Consider mobile phones, netbooks, kiosks, gaming devices, set-top-boxes, screen reader software and different input devices such as speech recognition. Which of these things are your target audience likely to be using? Don’t go mad here, folks. Some accessibility requirements can be very expensive and can even have a negative impact on other parts of the project. However, if you’re in the UK, we do suggest that you read PAS78 and seriously consider commissioning your web agency to carry out disability testing on real people.
Browsers
While many people agonise about which browsers to optimise their work for, there is one simple thing you need to do to find out. Have a look at the web statistics for your existing website and list the browsers, screen resolutions and operating systems which are used by 95% of your browsing audience.
Now, wasn’t that easy?
If you don’t have an existing website, you might need to bribe the webmaster of a website or application which is similar to the one that you’re thinking about building (in an ethical way of course). Free lunches work particularly well here. So I’ve heard.
Design requirements
Do you have an in-house design team supplying designs that we’ll use to deliver the project, or can we take on the design work? Do we need to build in rebranding with this work? Are there any specific design constraints we’ll need to work with? For example, if your funders are all clamouring for you to feature a bunch of random logos on every page of your site, we’ll sigh heavily and say yes, but that’s not an easy design problem to solve. Likewise, if there are any fonts, colours or graphic styles that you’re wedded to, letting us know about those will help a lot. What works best here is a link to a page, or an attached document, containing your brand guidelines.
Technical considerations
Are there any technologies that you think would cause outbreaks of measles amongst your users or organisation? Are you a Microsoft or a Linux kind of place? Can your users cope with Flash? Do you need us to arrange hosting for your website, or is that all sorted already? (If so, we need to know the specification for your hosting, specifically which platform it is, what programming languages it supports and whether we’re allowed total control over it.) What security measures need to be in place? Is the website likely to be hacked or spammed? And finally, what address will the web application have, and is the domain name already registered? If this paragraph made no sense at all, then we’re happy to guide you or help you to find out.
How many people will be making final decisions about features and design and what are their job titles?
I’ve never actually seen this mentioned in a brief, but I would love to.
Perhaps you’re wondering if I’m some kind of stalker. Let me explain…
One factor which has a massive effect on the likelihood of a project’s success is the number of people who must agree when it is finished. (Imagine how differently things might have gone if Genesis 1 read “In the beginning a committee was formed to decide on plans for the heavens and the earth.” The rest of it might gloss over how it took 2 billion years to… oh, um, hang on a minute…)
Beginning with two people, for every person who is added to the decision-making process, the project timescale will expand exponentially.
Third parties involved
It’s a similar tale with third parties. If your project’s success depends on other firms, an API we haven’t used before, or even your IT department, we also need to know about that. We are always willing to work with other firms delivering different parts of the project, or whose technology is untested, but we can’t guarantee that they’ll deliver as reliably as we expect them to. So there are inherent risks there that we’ll need to take account of when considering whether the project will be a success.
Technical skills of staff involved
We want to build a project that is easy for you to maintain. Sometimes it’s difficult to balance that need against tight budgets. If we know what the skills and experience are of the people who will be updating the website from its construction to its end, that helps us a lot with making recommendations to you about what sort of platform it should be built in, and how much attention we should pay to the expensive process of making complex administration systems easy to use. It will also guide our recommendations on the amount of time we should budget for training.
Response required
Timetable for response
When do you need to hear from us by, in order to get things moving in time to hit your deadline?
Do give web agencies a reasonable amount of time to respond. Two weeks is a minimum, unless you’re really up against it and don’t mind receiving a limited response.
In addition, remember to give yourself a reasonable amount of time to make a decision. In our experience, most organisations overestimate their ability to choose the right web agency by about 10 working days. So, allow plenty of wiggle room in your timeline for deliberating about web agencies. Having said that, it’s poorly-written briefs that create headaches for decision makers as they struggle to compare apples and oranges. A good brief will make your choice easier.
What kind of response is expected and what should it contain?
Be clear and direct about what you want agencies to tell you. We’re happy to provide descriptions, links and screenshots of relevant portfolio projects, references, ideas, recommendations, timescales, demos, interviews and presentations. What we will not do is provide speculative design work (not even wireframes). Spec work devalues design, and provides you with poor value for money in the long run as agencies’ costs rise to accommodate the risks involved. We’d rather eat an iPhone.
Do you expect your chosen web agency to contribute ideas / suggestions to the project?
Here’s a hint: our most successful projects have, on the whole, been a 50/50 collaboration between us and our clients, especially when it comes to design concepts and functionality.
We have 11 years of experience of what works on the web, and what to avoid. We’re champing at the bit to share it with you. We want to be able to recommend things that will delight your users. Give us that chance and see how it works. You don’t have to accept all our ideas, but you may be excited by what we suggest.
If you must, you can tell us exactly what we should build and how, but we might not be quite as excited about working with you. Not to mention that the project might lose out on something extra special.
So, bearing that in mind, tell us how much freedom we have in interpreting or questioning the brief, and whether we’ll have the chance to contribute our own suggestions.
There it is. I know, it’s a lot of stuff to compile. If it makes you feel any better, it’s probably half the work that your agency will do in responding thoughtfully to your brief.
If you’re still quaking a bit, consider hiring a consultant to help you construct a solid brief. This will give you somebody else to blame if it all goes wrong (ok, I’m joking about that). Seriously, doing so will give you more confidence in what you send out, and save hours or even days of head-scratching.
Comments? Questions? Flames? Cries for help?
Rachel Collinson is known as the Donor Whisperer. Learn more in my book, “The Giving Code”