Product Requirement document (PRD) Writing

I. Summary

No matter what we do, we pay attention to methods and writing.Product Requirement document(Hereinafter referred toPRD document) That is also true. I used to share my own articles in four articles.PRD documentThis article mainly provides an overview of the previous four articles to help you quickly understand the writing process.

1. preparation before writing (information structure ):

Before writing the PRD document, we need to first list the information about product functions. This step is the first step to gradually clarify our ideas and help us plan the auxiliary information about the functions, it can also help Server technicians create databases. Because this is the first step, we do not need to list it in detail. In the subsequent steps, we will gradually improve and improve the information content.

For example, the content of an article includes the title, body, author, release time, and category. The initial functional requirements only include the information. However, when more detailed considerations are made in subsequent functional planning, the information may be added or deleted, therefore, we do not need to deliberately pursue comprehensive information.

There are many ways to list information, such as text and mind-directed graphics. The most important thing is to be clear and easy to understand. My most common method is mind-Directed Graphs, therefore, I call this step an information structure chart.

2. Sort out the requirements (Product Structure Diagram and user flowchart ):

When we understand the product information structure, we need to sort out the product requirements in our minds to make the ideas more structured. Therefore, this step is to sort out the product requirements. First, we need to list the channels and pages (product structure diagram) of the product, and then sort out the functions of the channels and pages based on the product structure diagram, and build a user's operation flow (User flow chart ).

The above two steps allow us to have a comprehensive understanding of the product before writing the product requirements documentation, similar to a bird's eye view, it is also easy to adjust and improve.

3. Prototype Design (hand-drawn prototype, gray-mode prototype, and Interactive Prototype ):

After gradually clarifying the product requirements and organizing the various channels and pages of the product, we need to verify the specific interface performance of these ideas and the feasibility of the solution.

First, we recommend that you quickly draw a prototype of the product on the grass paper, deduct and discuss the feasibility of the solution through hand-painting. When there is some progress, we can use software tools for more in-depth design. For mobile products, the gray-mode prototype can be considered. For website products, the interactive prototype can be used for both mobile products and website products, specific to your personal habits and Team requirements.

For product managers, prototype design is designed to help us carefully consider the solution and demonstrate the feasibility of the solution. It is also designed to avoid product presentation, abstract Language descriptions lead to difficulties in understanding and misunderstanding.

4. Write a document (PRD document ):

After the above three steps are completed, we have clearly understood the product requirements. Generally, the purpose of the PRD document has been completed by adding a description through the prototype (many product managers directly use axure to make the PRD ).

Of course, some individuals or teams may have different requirements and have specific standards for PRD documents, which may be archived and categorized. Regardless of the standard, the purpose of the PRD document is similar, so the function description is similar, so here I share three ways to write the PRD document.

5. Use Case document (UML use case diagram and flowchart ):

This document is a supplement to the PRD writing method.Case document".

2. preparation before writing (information structure)

When we first contactProduct Requirement documentFirst, we will lookProduct Requirement Document TemplateTo understand and learn specific writing requirements, but in fact, most ofPRD documentIt is not consistent with the actual work, or it is complicated.

A friend who was engaged in product work a few days ago sent a list of Product Requirement documents he wrote to me (). At that time, I was depressed. These categories were more likeMRD documentInsteadPRD documentSo I decided to write several articles about the PRD document and share some of my insights and writing methods on the PRD document.

PRDEnglishProduct Requirement documentChinese stands for the product requirement document. For specific terms, you can askGoogle.PRD documentIs based onBRD,MRDThis document is mainly used for product design and development. Therefore, most people who read this document are design and technical personnel. In such groups, designers rely more on prototype interaction or visual design. Therefore, those who read this document tend to be technical personnel. Compared with the technical staff, they do not pay much attention to the commercial needs and market vision of the product, because the product definition has been presented to the personnel involved in design and R & D during product discussions, therefore, technicians focus more on interfaces, functions, interactions, elements, and so on. Therefore, the PRD document is a detailed description of product functional requirements, is the most basic and meticulous document in product documentation.

PRD documentIt is a functional instruction document without gossip and goes straight into the topic. Therefore, when writing, we thought about the logical line diagram of the interface function of the finished product. Before writing this document, we need to make some preparations to digest the requirements of BRD and MrD and integrate the product structure diagram. Because these preparations belong to the thinking class, we recommend that you useMind Map Software(Mindmanager.

The first step in product planning is to sort out the productInformation Structure,Information StructureWe can continue to plan the product structure, and the information structure is the basis for Server technicians to create databases.Data Structure. No one knows more about new products or new features than the product manager. Therefore, we need to list the information first to form a structure. (For example)

This figure uses my blog as an example. When listing the information structure, we are more concerned with information data. Therefore, in this step, we do not need to thoroughly consider the product interface and features. The information structure can be either forward or backward, depending on the product type.

For example, programs such as CMS adopt framework-based development and have independent functions from templates. Therefore, the front-end is changeable and such products are platform-based products. For such products, when planning the information structure, we only need to simply consider some front-end functional requirements, more is for the back-end administrator to consider the operation, plan and list the required information content structure from the backend.

No matter what type of product, no matter where we start from, the first step is to list the information structure first, because the information structure diagram is not only a chart that helps technicians create databases, it is also a reference for supporting product personnel to conduct product function planning. Only by understanding the structure of information or data can we play with data and products.

When the information structure is converted to the data structure, if it is a new function added to an existing product, the technical staff needs to compare the database according to the information structure, the existing data is called directly. If the existing data does not exist, you need to discuss it in detail to determine the usage of new information and the future extension direction, so that you can determine whether to create a data table or create a data field. (Although the product manager does not need technical development, it is very helpful for product planning and technical communication if he understands technical principles and database principles .)

Information Structure Diagram is a product-level understanding. If you want to store the information in the database, you need to discuss the data structure. The storage of a piece of information has many additional attributes, including whether it is stored as a field or a data table, or an intermediate table or an associated table. These attributes need to be discussed with database technicians after the PRD document is completed. In addition to displaying the information structure diagram, we also need to explain the product prototype and functional requirements so that database technicians can understand the product intent and take future extensions into account during Database Planning.

The information structure diagram is the first step for us to structure our concepts and ideas. It is also an auxiliary document for our next step. At the same time, we will continue to improve the information structure in the next step.

In the next article, I will explain how to sort out product requirements and plan the product structure and user flowchart based on the information structure.

3. Sort out requirements (Product Structure Diagram and user flowchart)

In the previous article, we formed concepts and ideas.Information Structure, Luo lists all the information about the product. Now we need to followInformation Structure, Start planning the functional requirements of the product, and draw outProduct Structure DiagramAndUser Flowchart. First, we need to plan the Product Channel and sub-channel, sub-module or sub-page. (For example)

Illustration Note: I want to explain my understanding of the glossary of this mind map.
1. Channel: a common carrier of functions or content of the same nature, also known as the category of functions or content.
2. sub-channel: Another sub-channel category
3. Page: interface of a single or affiliated channel or category
4. Module: the content of a region composed of multiple elements on the page. One or more content can be displayed cyclically (for example, the article list)
5. Module element: the element content in the module. Taking the article list as an example: The article title, article summary, and Article release time are all elements that constitute the content of the module, they can also appear cyclically. Element types can be text, images, links, etc.

If you have learned about web design or the template mechanism of Web products, you can understand these terms. As shown in, this is the homepage structure of my blog.

After planning the channel, we need to perform step-by-step simulation from the user's perspective to gradually improve the product structure guide. I call itUser FlowchartIt is used to show the abstract product logic in the minds of product managers. It is also a process for product managers to sort out the product ideas in their minds. (For example)

The purpose of this operation is to sort out the product logic so that we can clearly know how many channels the product has, whether there are subchannels or pages under the channel, and what functional modules are available on these pages, what are the elements in these functional modules. In this way, we simulate the user's entire operation process and perform operations on all functional interfaces of the product one by one.Product Structure DiagramAndUser Flowchart.

With this structure map, we can take a bird's eye view of the product for consideration and improvement. When there is a problem, it is much easier to modify it than the prototype and documentation. This method is also suitable for mobile Internet product planning and easier to sort out the product structure than Web products.

All of the above are browser-oriented user processes. However, if you plan a platform-level popular product, you cannot sort it out from the front-end, such as CMS and BBS programs, they adopt framework-based development and separate functions from templates. The front-end interface layout is only called through the tag of the template mechanism. Therefore, the front-end is not involved in product planning, we should not start with the front-end. This method is also used in the planning of CMS platform products, except that the Administrator process is simulated in the background.

Before writing the PRD document, let's sort out the ideas through the mind map, understand how many channels there are, how many pages there are, how many functional modules there are on the page, and how many elements the function module has, and gradually sort out the ideas in your mind into a structure. Although the product structure has been clarified, such mind maps are still abstract for design and technical personnel, and they still do not understand them. For the product manager himself, such a structure diagram has not been deduced. We have never thought deeply about whether the structure conforms to the product logic or the user experience. Therefore, we need to design a prototype, consider the feasibility of the Structure Scheme.

Next I will explain several prototype design methods and explain why prototype design is earlierProduct Requirement document.

4. Prototype Design (hand-drawn prototype, gray-mode prototype, and Interactive Prototype)

In the previous article, we passedMind MapAfter the ideas are structured, We need to deduct the feasibility of the scheme to verify whether the product functions are feasible and estimate the amount of manpower and material resources required for the project. Therefore, we need to passPrototype DesignTo demonstrate relevant requirements. Written from the very beginningPRD documentIt is difficult for us to evaluate products in various aspects, nor to learn about the feasibility of the solution, and to consider products in an intuitive and meticulous manner.

Prototype DesignIt helps us to think more carefully and evaluate various requirements. At the same time, we also output the ideas in our minds. After prototype design, we can present products. Compared with the abstract text description, the prototype is more clear about the product requirements, and the design and technical staff or the boss can intuitively understand the product intent.

A prototype is a framework of structured requirements. Therefore, a prototype is also calledLine diagramThere are many specific performance methods and many related auxiliary software, such:Axure RP,Balsamiq mockups,UidesignerAnd so on.

At this step of prototype design, we need to have a deeper understanding of the elements on each page and the attributes of these elements. For example, for button elements, we need to consider the button function, and this function operation will give feedback to the backend and front-end. For example, this button is the registered member button. After the user operates, the first step is to verify whether the information entered by the user is valid. If this button does not comply with the rules, the front-end feedback is provided; if it is valid, the system verifies whether the same information already exists with the backend communication. if it already exists, the system provides a front-end feedback. If it does not exist, it goes to the next step and the registration is successful. After successful registration, the feedback is redirected to the page, or the pop-up layer prompts you to improve the information, which requires more details. Of course, these more detailed ideas are left at the time of requirement document writing, and what we need to do at this time is to express these elements through prototype.

There are three main types of prototype design techniques: hand-drawn prototype, gray-mode prototype, and interactive prototype.

1. hand-drawn prototype

Because the prototype is also called a line chart, hand-painting is the simplest and most direct method and the fastest way to express the product outline (for example ).

Hand-drawn prototype is highly efficient in initial verification, which facilitates discussion and reconstruction. It is also suitable for quick prototyping during agile development.

2. Gray-mode prototype

The gray mold prototype is made up of graphic design software. My most commonly used software isPhotoshopAndFireworksCompared with hand-drawn prototypes, the gray model is clearer and more clean, and can also be used for presentations. However, product personnel must be familiar with the use of graphic design software (such ).

The gray-mode prototype is often used in the design of mobile Internet products. Due to the complex interaction requirements of mobile products, the prototype design software is difficult to express the demand efficiently. Therefore, the design of mobile Internet products is usuallyGray-mode prototypeAddInteraction documentCombinedPRD document. (In a few days, I will discuss more about the mobile Internet product design)

3. Interaction prototype

An Interactive Prototype is a prototype completed using the prototype design software.Axure RP, UsuallyInteraction prototypeThe design is only earlierPRD documentIs the last step for product managers to deduce their ideas. PassAxure PRAnd so on.Interactive Prototype SoftwareThe product prototype is similar to the formal product in terms of functional requirements and interaction requirements.Demo Version.

GenerallyInteraction prototypeYesProduct ManagerAndInteraction DesignerA joint discussion is made by an interactive designer, but most companies do not have an interactive designer. Therefore, this kind of work is ultimately undertaken by the product manager. (Many companies give visual designers the title of interaction designer, but the essence is visual design)

I will not introduce more about creating an interaction prototype for axure PR. There are many such tutorials on the Internet. I personally suggest learning the structure of the website template when learning axure PR, this will help you use axure PR in a more structured way. (I recommend a prototype that I drew earlier. The website has been closed. The prototype was also poorly designed at that time. There are many missing pages for your reference only .)

Share the micro world prototype demo (source file): http://tangjie.me/blog/11.html

The above three methods are not progressive processes, but three prototype design methods, depending on your product requirements and Team requirements.

The product manager designed the prototype to help them think more carefully about the feasibility of the solution, and to give explanations to others so that the audience can clearly and intuitively understand the product, it is also designed to ensure that the product is implemented according to the requirements and expectations originally imagined by the product manager. Therefore, the product manager's prototype has no high requirements. As long as the other party can understand it, using hand-drawn prototype is the most efficient method.

In the next article, I will describe the writing requirements and template formats of Product Requirement documents, and share some of my case documents.

5. Document Writing (PRD document)

In the first three articles, we sorted outInformation Structure,Framework Structure,Interface Structure(Prototype). In this step, we will start to formally write Based on the previous work.Product Requirement documentNow (PRD document).

Through the preparation work, we have made our product requirements clearer and carefully considered the feasibility of the solution, thus reducing and avoiding the details that are easily ignored during document writing.

PRD documentThere is no standard specification and no unified template. Every company is different and everyone is different. It depends on personal habits and Team requirements. Although there are no standard standards in the PRD documentation, there are two essential items:File IDAndModify record. During the document writing process, we can constantly modify and improve the document. However, if the document is officially released or handed over to other team members, once the document is modified, we need to mark the modified content of the document and the modification record of the remarks. The format of file identifiers and modification records is similar (for example ).

There are three common PRD documents:Word,Image,Interaction prototype

I. Word

This is in the traditional sense.PRD documentIt consists of four parts (according to your product requirements:Structure chart,Global description,Channel Function,. (As I have mentioned in the first article, the readers of the PRD document are more inclined to be technical personnel. Therefore, the PRD document is clearly intended to describe the functional requirements of the product, all PRD documents do not contain market descriptions. At the same time, I suggest you minimize unnecessary texts so that readers can understand and understand the product intent, the fewer words, the better. This is mainly because the vast majority of people do not have enough patience to carefully read the PRD document, so we should try to reduce the document content .)

1. structure diagram:
1.1. Information Structure Diagram: It mainly serves as a reference document to assist Server technicians in creating or adjusting data structures.
1.2. Product Structure Diagram: It mainly helps design and technical developers understand the global structure of the product. It is different from the user flowchart. The product structure diagram only lists the product channels and pages.

2. Global description:This section describes the overall functions of a product, such as page code, user roles, cache and download mechanisms of a mobile product. Here is an example of "status maintenance and recovery" for mobile products.

Status maintenance and recovery
When a user exits the product (misoperation, Home Key, lock screen, automatic shutdown), the product must maintain the status before the user's operation. When the user returns the product, the status can still be restored to the previous status, and continue to use.
The maintenance status includes process operations, information browsing, text input, and file download.
When the screen lock status is enabled, if you have a download task in the product, the download continues.

Product Requirement document example:

3. Channel functions:The page is a subitem that describes the functional requirements of the channel, page, and page module elements of the product, in the following format ).

Sample format
1. channel name: Channel introduction and Requirement Description
2. Page 1: page introduction and requirements
2.1 page Module 1: module functional requirements
2.1.1. Page Module 1-element 1: Function Description
2.1.2. Page Module 1-element 2: Function Description
2.2 page Module 2: module functional requirements

When writing functional requirements, we need to consider the user's process. For example, after a "finish" button, we need to describe it, do the system give feedback (what type of feedback is prompted, what the content is displayed, whether the content needs to be retrieved from the database), or do you want to jump to the page (which page to jump, this page is another channel page or a sub-page of this function. If it is a sub-page, you need to describe the module and element content of this Sub-page ).

4 ,:It is a product diagram completed by the designer, consistent with the actual developed product fidelity.

Ii. Images

The PRD document in the image form is based on the description file, which marks the functional requirements of the traditional word form. This method is often used in the mobile Internet field and is actually an interactive requirement file in the form of text and text, on this basis, the functional requirements are described in more detail.

For PRD documents in the form of images, we only need to describe the global description. The requirements for pages on other channels are displayed in the form of images, this method is more vivid and intuitive than the plain text in Word documents. Therefore, some product managers prefer this method to replace the PRD document in Word format.

Iii. Interaction prototype

The interaction prototype refers to the prototype design mentioned in the previous article. The product prototype created by using the interaction prototype design software such as axure PR is very real and intuitive, the prototype software also supports element tagging and Word document export. Therefore, many product managers prefer to use axure PR instead of word to complete the PRD document.

After the product prototype is created through axure PR, it is actually a perfect product demo. Therefore, we only need to add the annotation of elements to describe the functional requirements, the exported HTML file is more intuitive and easy to understand than Word documents, and is a very efficient description of product requirements.

---

No matter which method you use to generate the requirement document, the ultimate goal is to help team members understand the intention of the product. Therefore, which method can avoid the details black hole and efficiently complete product design and R & D, this method is the most effective method.

Well, the introduction to "Writing product demand document (PRD)" has been completed. There are four articles in total to help you. If you think there are any errors or questions in the article, comments are welcome.

Vi. Use Case document (UML use case diagram and flowchart)

In both product and technology fieldsUMLBut for product personnel, UML is moreUse case diagramThat is what I callUser Flowchart. LecturePRD documentIn the second article, I mentionedUser FlowchartIn fact, the user flowchart isUse case diagramIs a structured expression, because it is described in a structured wayUse CasesThis article is too abstract and lacks logical expression. It is more focused on functional user processes and is not a practical case.UML use case diagramAndCase document.

Case documentIt is a document composed of multiple use cases. It is mainly used for technical development and testing. It is an important auxiliary document in PRD and is used to explain the functional logic of a link, for example, user registration, event registration, and other functions require use cases to help explain. The writing time of case documents is usually synchronized with PRD documents after prototype design.

Case documentThere are two associated files:Use case diagramAndFlowchart.Use case diagramIt is a type of UML diagram. It describes the product functions from the user's perspective and specifies the operation permissions of the user in various features of the product.FlowchartIt describes the processing process of product functions by means of wiredrawing. It mainly describes the execution sequence, branch and loop logic of the functions.

The common software used to write user documents isWordWhich of the following is the commonly used software for creating Use Case charts and flowcharts?Visio, Of course, also usefulAxure RPSoftware production. For example, the third-step flowchart below is created using axure Rp.

A complete Use Case document consists of the following three parts: the 3rd-point "Use Case" describes the functional logic and determines the number of use cases based on the number of functions.

The basic components of the use case document are as follows:
1. Modification record: the record of each modification, which is the same as the PRD document.
2. Role Description: describes the roles involved in the system.
3. Use Case: Same as step 1 in the following step, the flowchart in step 2 is directly inserted into the flowchart table entry in step 2.

The template format of the case document is similar to the preceding three items. You can use a Word document to draw a table and write a case description in the table. The format and style of the table can be found in the following example.

1. The first step in writing the case document is to indicate the roles (participants) and Role descriptions (Role descriptions) of the products used ). (For example)

2. Step 2 shows the use case relationship of the role in the frontend and backend by using the use case diagram. (For example)

3. Step 3 shows the activities of a role in each function step in a flowchart. (For example, event registration is used as an example)

4. Step 4 is to integrate the above three steps into a case document and write the case description for each function step. (For example)

Table description:
4.1. Use Case name: name of this function stage
4.2. Use Case No.: ID of the use case in this product
4.3. Action Role: role that participates in or operates (executes) The Function
4.4. Brief Description: Describe the needs of this case in the least amount of text
4.5 prerequisites: prerequisites for participating in or performing this function
4.6 Post condition: Result condition after execution
4.7 flowchart: Role activity process (processing process) diagram of this function (diagram in step 3)

The example described above is relatively simple, and is also the most common and basic use case description content. Of course, there is also a slightly more complex use case document, the usage scenarios, event streams, and information fields are described in detail in this document. Some use case documents are also inserted into the product interface.

Use Cases mainly describe the behavior role to provide system feedback based on the situation or problem when using the product under different circumstances. Event streams are similar to flowcharts, But they describe the activity process of a role in text. The information field describes the data fields used in the use case.

These more descriptions depend on my habits. The ultimate goal is to clearly describe the product logic. Therefore, my principle is to describe more clear requirements with less words. (After all, these documents are executed in product development. If there are not many texts, you can clearly express them .)

 

From: http://tangjie.me/blog/56.html