I’m no Sherlock Holmes, but I can deduce that if we get a sh*t brief in, the outcome isn’t going to be pretty.

Why is it that when a brief with holes all over it comes in, the sender assumes that we’ll join up all the dots and magically turn the turd into gold?

Web development is no different from any other project, the bit that’s often seen as dull, i.e. the details, is the most important. Get that bit right and things are much more likely to go to plan and schedule. Get it wrong and, well…you get the gist.

Ok, so what makes up a decent brief?

  1. Clear goals and objectives – Clearly outline what you (or your client) want to achieve from the project. Knowing expectations from the start makes it a lot easier. If it’s a website, what is the main purpose, is it to capture leads, sell your stuff or maybe it’s just an online brochure. If it’s custom software for the business, what problems will it solve? How does it align with business goals? This context helps guide decisions.

2. A defined scope and set of requirements – Detail what features, functions, and pages need to be built and how they should work. Prioritise by importance. Also document any technical, integration, or compatibility requirements.

3. Know your audience and create personas – Describe who will use the site/software. Develop buyer and user personas that outline their anticipated behaviours, motivations, pain points, and preferences.

4. Content Strategy – Explain the role of each content piece and what types of content will help achieve your goals for the website or software. Also provide guidelines on tone of voice and how to incorporate branding elements.

5. Design guidelines – Share design standards and style guidelines like colour palettes, font usage, element spacing, imagery direction, etc. If you have a branding guidelines document, they should all be in here.

6. Sitemap or diagrams – Visual representations of required functionality, flows and linkages outline how you expect everything to connect.

7. Specific deliverables – Clearly define what tangible final deliverables we should provide upon completion, such as technical documentation, online knowledgebase etc.

8. Timeline expectations – Share milestone dates or project phasing so expectations around timelines and schedules are set and agreed upfront.

9 Budget ranges – Provide general budget parameters for the work to keep things inline with expectations and what you have available. Pretty much anything is possible, but it has a time and monetary cost attached to it.

Outlining these key details, objectives and requirements in one document provides us with direction and reduces the chances of miscommunication and wrong assumptions. The clearer the brief, the better the outcome. It might feel like a bit of a chore doing it, but think about what comes out of the other end if you don’t!