I have used Design Brief as a guide document for the past 10 years. When I was first introduced to the Design brief I was working as a business analyst/designer in the field of e-commerce. During that time the Design Brief was a very concise one page statement that worked as a guide for the designer to understand the project goals, objectives and mood.
Today I’m seeing design briefs becoming a much more robust document, however it still serves the same basic purpose, to represent the business needs of the design.
A design brief should include in summary form:
I have also seen them contain Reference Documentation, Product Overview, Problem Statement, Features, and Competitive Product information, and it can also contain information about what the design is ‘not’. Needless to say this has veered away from the one page format of yesteryear.
From an Usability perspective the design brief can be an effective tool of communicating a design hypothesis for an initial iteration to be leveraged during the Research Phase of the User Centered Design process. This can be an artifact that supports the scientific approach to collecting requirements. Make your hypothesis, and then validate it with users.
The important thing is that the Design Brief is used to guide the designer as to the business needs of the project, and to give some direction as to what needs to be achieved. Whatever format you choose, the design brief should be an effective tool of communication. If everyone working on the project and the end customer agrees with the content of the the Design Brief and has consensus as to the design criteria then it can prevent conflicts later in the design process.