sumber: http://productdesignmanagement.com/how-to-write-a-product-brief/
A product-brief is one of the most important elements in a product design project. The product-brief is a plan and a compass – it defines the product’s goals and attributes, and shows you where to go. The product-brief has a great impact on the product’s quality and character, and the project’s efficiency. The product-brief writing is perhaps the activity with the highest ROI, as it costs very little and brings great value, as well as saves a lot of time and money while preventing wrong directions and unexpected outcomes.
Here is a list of eleven guidelines and insights about how to manage your product-brief.
1. The product-brief is a map.
Never run a product design project without a significant product-brief, even if it seems as if “it’s all clear”. A few working hours on a good brief writing at the beginning of the project can save you a great deal of time and money. A design project without a brief is like an outdoor trip without a map. It is much faster and safer to reach your destination when you have a map with a planned route.
2. The product-brief is an agreement
The product-brief is also a professional agreement about the product’s definition between all project’s members – managers, marketing people, engineers, designers, suppliers, clients and so forth. All should be involved in writing and approving the brief, and of course, acting according to it
The product-brief is also a professional agreement about the product’s definition between all project’s members – managers, marketing people, engineers, designers, suppliers, clients and so forth. All should be involved in writing and approving the brief, and of course, acting according to it
3. The product-brief is under the design manager responsibility
Writing and managing the product-brief is a crucial part of a design process. It’s the product design manager’s responsibility to manage the brief, while keeping all projects’ members involved.
Writing and managing the product-brief is a crucial part of a design process. It’s the product design manager’s responsibility to manage the brief, while keeping all projects’ members involved.
4. Keep it short and simple
The product-brief should define the product in a simple and short way. Avoid complicated and long text with too much background details. A typical product-brief should be between 1 to 3 pages long.
The product-brief should define the product in a simple and short way. Avoid complicated and long text with too much background details. A typical product-brief should be between 1 to 3 pages long.
5. Define “what” not “how”
The product-brief should focus on the expected goals (what). It is the design work’s responsibility to find the best solutions to achieve these goals (how). Normally, it’s much easier to define and describe a solution rather than a goal. (e.g. “The part will be made of aluminum” vs. “The part should be lightweight, resist to high temperature, and cost less than $3.00″). Defining “how” in the brief might narrow the designer’s options and curtain other solutions.
The product-brief should focus on the expected goals (what). It is the design work’s responsibility to find the best solutions to achieve these goals (how). Normally, it’s much easier to define and describe a solution rather than a goal. (e.g. “The part will be made of aluminum” vs. “The part should be lightweight, resist to high temperature, and cost less than $3.00″). Defining “how” in the brief might narrow the designer’s options and curtain other solutions.
6. The product-brief is a live document
The product-brief is written at the beginning of the project, yet it is necessary to keep updating it all project long. You never know everything in advance; new information, insights, and decisions are usually raised during the project and affect the product-brief. It is important to keep your brief (and all project members) up-to-date. The brief (when it’s up-to-date) is the best reference for the product’s testing stage.
The product-brief is written at the beginning of the project, yet it is necessary to keep updating it all project long. You never know everything in advance; new information, insights, and decisions are usually raised during the project and affect the product-brief. It is important to keep your brief (and all project members) up-to-date. The brief (when it’s up-to-date) is the best reference for the product’s testing stage.
7. Product-brief can (and should) include questions
Of course it is better to have all the answers in the product-brief, but it is absolutely normal to have open questions as part of the brief at the beginning of the project. In such cases, you should add notes to the brief about the actions and timetable needed to answer these questions.
Of course it is better to have all the answers in the product-brief, but it is absolutely normal to have open questions as part of the brief at the beginning of the project. In such cases, you should add notes to the brief about the actions and timetable needed to answer these questions.
8. Product-brief should also include the excluded
It is much easier to illustrate and define a product when describing both the included and the excluded parts and aspects. If there are certain capabilities, features, or any others “naturally expected” aspects, it should be defined as not being part of the product. This might save some misunderstanding and mistakes.
It is much easier to illustrate and define a product when describing both the included and the excluded parts and aspects. If there are certain capabilities, features, or any others “naturally expected” aspects, it should be defined as not being part of the product. This might save some misunderstanding and mistakes.
9. Product-brief should include the product’s hard- and soft-attributes
Most product-briefs tend to focus on the product’s hard-attributes. Make sure to pay the needed attention and time in understanding and properly defining the product’s soft-attributes as well. The soft-attributes are more elusive and complicated to define, but not less important.
Most product-briefs tend to focus on the product’s hard-attributes. Make sure to pay the needed attention and time in understanding and properly defining the product’s soft-attributes as well. The soft-attributes are more elusive and complicated to define, but not less important.
10. Don’t mix product-brief and project-management
It is very easy to mix product-brief and project-management, as they are different sides of the same coin. Here is a simple way to distinguish between the two – a product-brief should focus on the long-term aspects of the product – the ones that last forever. Whereas the project-management aspects should focus on the short terms aspects – the ones connected to the R&D process, such as to-dos, responsibilities, milestones, budget and so forth.
It is very easy to mix product-brief and project-management, as they are different sides of the same coin. Here is a simple way to distinguish between the two – a product-brief should focus on the long-term aspects of the product – the ones that last forever. Whereas the project-management aspects should focus on the short terms aspects – the ones connected to the R&D process, such as to-dos, responsibilities, milestones, budget and so forth.
11. Don’t use (closed) brief templates
Every product has it own unique environment and requirements. This is why there is no such thing as “general product-brief template”. Templates are good for cases when you have all the “questions” ready in advance, which is not the case of a new product development. I prefer to use a Product-Brief Checklist just to remind me the main titles (it never covers the whole points) that I have to consider. You can try using my Product-Brief Checklist
Every product has it own unique environment and requirements. This is why there is no such thing as “general product-brief template”. Templates are good for cases when you have all the “questions” ready in advance, which is not the case of a new product development. I prefer to use a Product-Brief Checklist just to remind me the main titles (it never covers the whole points) that I have to consider. You can try using my Product-Brief Checklist
Tidak ada komentar:
Posting Komentar