I've worked with many clients and managers for well over a decade now and I've seen my fair share of client briefs. What follows is a brief description of what works and what doesn't - and why (for me). Also what you can expect in my response, and why.

Dear future client and partner - this is for you so that I can do my very best to work with you.

Describing what you want

The first step to creating a working relationship is communicating the problem you want my company to solve.

The first rule is avoid any technical language. Red flag words include: HTML5, Ajax, dynamic, iframe, script, database, SQL, code and so on. This leaves the decision of technical solution very much in my court - which is why you're looking to hire my company in the first place. Technical language also implies some existing problem or technical constraint - which may lead me to barking up the wrong tree: a waste all round.

The reason for this is because I'm trying to solve the problem from scratch. I don't want to be pushed in a specific direction (say if you suggest solving using Ajax and SQL databases) because the service I'm offering you is experience, and that experience should offer you the right solution which may not particularly be the one you're suggesting.

If describing how the page might change to due some interaction from the user, try to keep it simple and abstract. Context is everything - the more of the picture you can describe, the easier for me to understand how a solution will fit your problem.

The bigger picture you can offer, the better. Having an understanding of why this is a problem for your users and what they'll achieve by using this tool or product is key. This also allows me to think outside the box as it were, and possibly come up with alternative solutions that you may never have thought of. It will also allow me to raise questions that could clarify the user interaction.

What I want to give back to you

My job is to process your requirements, digest them and return an outline of my understanding and plan of development (though this last, if it's a simple project, will likely just be a date and communication plan).

Think about when you read your phone number out to someone. They repeat it back in a way that's not familiar to you. That's exactly what I'll be doing. I'll send back my understanding of your problem, so you see it in another light - this will help both of us spot whether something has been omitted. It should also help you see that I understand the complete problem.

If appropriate you'll also get a quote from me. Most importantly you'll receive a series of questions or assumptions about the project and where necessary I'll highlight the risk areas. I've never had a project where there weren't questions or assumptions - this is completely normal.

Risk also doesn't mean the project is at risk. Only that these items identified may have the potential to be more complex than originally expected or may have the potential to impact on the deadline. For me, it's important to get these items solved early in the project.

To conclude

This is my personal preference when it comes to working and may not fit all developers (or designers). If this is useful, please feel free to reuse it. Equally dearest client - I don't mean to patronise you with this article. It's important to me that we're working off the page, and plain English is a language both you and I can easily communicate in.

Drafts may be incomplete or entirely abandoned, so please forgive me. If you find an issue with a draft, or would like to see me write about something specifically, please try raising an issue.