briefs

in Blog

A better website brief

As someone who runs an agency offering WordPress website development, I get quite a lot of website development briefs in my inbox. Some are excellent: they give me and the team a clear sense of what’s required. Typically, they’re documents under 20 pages long which talk quite a lot about users and goals and priorities, about what’s good and bad about the current site, what’s known and unknown, what needs to change and why. They ask for our ideas and suggestions about how the digital platform and they way we develop it together can help solve strategic questions for the organisation.

Other briefs are less helpful. They’re invariably longer, start with the procurement process, talk little about users or content but in great detail about must-have features (which frequently aren’t really features). They ask us to explain – and these are genuine examples, I promise – how we’ll foster improved race relations through the CMS build process or the margin we apply to subcontractors’ day rates or to confirm we’ll run Gateway meetings at the end of each ‘AGILE’ sprint. I’m not sure what kind of suppliers happily fill in those templates and earnestly tailor their response to the weighted percentage scoring system described, but I suspect they aren’t the ones who build the best websites. If you require those things as a client, you’re just asking to be lied to.

I understand that it’s hard to go shopping for a new website, especially if you’ve not worked in that field. Procurement colleagues frequently don’t help, with their convoluted templates and inhuman portals. I don’t blame the clients who issue bad briefs, but I would like to help them write better ones, based on 15 years’ experience both dishing out briefs and trying to respond to them.

So here’s a template – a set of questions we look for answers to as suppliers of this kind of thing, to help us cost a job. Briefs that give us this information will get a more useful, precise proposal from us, and almost certainly a more competitive price since there’s so much less risk involved for us to cost in.

I’d really appreciate thoughts and comments from others on the Google Doc.

Direct link: https://docs.google.com/document/d/1tlNuVhw44-5MVj48iewhNHGAYp_7r8iqNUc3r8xNjiE/edit

The bottom line is that you don’t have to know exactly what you need, but you should be able to talk about what’s important to you and why. The best briefs are up-front about this: they say what’s known and what isn’t, and give us the opportunity to recommend a proper discovery phase to scope out the user needs, content, constraints and technology so that together we can focus the budget on what’s most likely to work.

Photo Credit: Hegemony77 clothes for dolls and 1/6 figures via Compfight cc

  1. This is an excellent idea, I was considering writing a similar template myself.

    My two suggestions would be;

    1. Remove functionality entirely – if you have goals, then the research and design process should have flexibility to define how you achieve them.

    2. Add a section for research; has any research been done on whether this thing needs to exist at all, and the audience groups/users it’s intended for?

    It might also be worth adding something specific about measurable outcomes? A lot of clients may not have them pre-research, but I think it’s an important thing to think about early in a project.

    • Yes, I wondered about explicitly referencing research – I suppose that’s what I’m trying to get to with asking about the understanding of users and what *isn’t* known too. Functionality is a tricky one – in the day to day of a web business (as you know!) functionality is what eats up a lot of time so I guess we want to know if there are specific things, but the best scenario would be to scope it very loosely and pin it down during a discovery phase.

      Good point about measurable outcomes – what success looks like for a client is a really interesting question and yields surprising answers if they’re able to talk about it honestly.

Comments are closed.