If the product requirements document (PRD) is a product, how to make a PRD with a good user experience?
Let's take a look at PRD's user Persona: primarily developers , who want to see the "easy-to- understand" product requirements documentation Most in a busy development task.
Comb the function of PRD: Communicate the product demand, manage the record product iteration process, share product information with each department to promote communication;
So a good PRD principle is: The structure is clear, the language is simple and easy to understand, real-time sharing.
How exactly do we make it?
A PRD document can
Now, more and more product managers are adopting a way to combine textual descriptions and prototypes into a single PRD document, because the way the previous word+ prototypes are managed is cumbersome and prone to information omissions.
Unify the prototype and text description, share a link directly, the developer can see all the information, is the ideal state.
Multilevel navigation structure display PRD information
Generally speaking, a product requirements document contains "Product Overview", "Flowchart", "feature details and Prototypes", "Global description", "Non-functional Requirements".
How do we present this content in a document in a clear and organized manner? You can use a web-like multi-level navigation structure.
1 , product Overview
The Product Overview section is used to show document revision history, release notes, development cycles, and product introductions.
"Document revision history" is used to record the product manager's changes to the PRD document, and also to facilitate members ' timely understanding of PRD changes;
"Release Notes" shows the core functions of each version of the product on line;
The development cycle is used to comb the expected start and end dates for development, testing, and on-line.
"Product Introduction" is used to record product name, Introduction, User portrait, usage scene, product positioning and so on.
("Version info" module in "PRD Template A", by Dragons)
2 , Flowchart
Flow chart is a product manager to comb the product logic and function of a thinking map, generally there will be "functional structure diagram", "Information structure diagram", "Task flow chart".
The functional structure diagram shows the functional modules of the product, generally expanding the smallest unit visible to the user.
The information structure diagram is a information-based dimension that describes what data fields are present, and displays user information/behavior information.
"Flowchart" records the user's use of the product path, is also a product line map, display all the product pages and corresponding relations, to help product understanding.
("Structure diagram" module in "PRD Template A", by Dragons)
3 , feature details, and prototypes
This module is the most frequently viewed module by the developer. At present, a quick and efficient way of rendering is "prototype" + "annotation".
Graphics and text complementary, the picture can not pass the information to be added clearly, such as some of the use of logic products, to facilitate the understanding of colleagues.
With the ink knife, you can create a large canvas, then paste the prototype page of the ink knife into the canvas, add text annotations, and have some description of the boundary conditions in the key position.
Alternatively, add comments directly to the product prototype project through annotations.
("Interactive prototype" module in "PRD template a", directly embedded in the Ink Knife Prototype, by Dragons)
4 , Global description
This page is used to show the design specifications of the entire product, and some common rules can be attached here.
For this reason, the convenience of using ink knife is: You can directly to the design specifications of the prototype project through the web link to the way, but also click on the "callout" to see the details of the elements.
("Global description" module in ink Knife "PRD template A", by Dragons)
5. Non-functional requirements
For different types of products, non-functional requirements will have a variety of differences, will generally involve:
......
This part will be adjusted as needed.
Summarize
PRD as an important document for intra-company communication, the ability to bring the necessary information together in a logically clear structure is an advantage in improving productivity. language to be simple and easy to understand, combined with visual structure and prototype , are to enhance legibility, to make communication more efficient.
PRD as a small product to polish, not a waste of time, a good PRD document can be followed for a long time.
Therefore, we are very grateful to the two knife friends @ Big Lotus seeds and @ Dragons, for everyone to contribute two product requirements document template.
The content, navigation and interaction of the pages in these two PRD are designed for everyone.
Now you can click " Create Project", choose " product requirement document A" or "Product requirement document B"from the Ink Knife template, click "Use template", Then make some changes according to your own product okay!
Through the ink knife sharing link can also directly let the company's internal personnel online real-time synchronization PRD update, no longer worry about information lag or document incompatibility issues.
Let's start by creating or optimizing your product requirements Documentation ~
Article cover Photo: Photo by helloquence on Unsplash
The picture is from "Operation and maintenance school" and ink Knife official website.
Programmers love to read the product requirements document to your product Manager