The original text comes from: http://blog.renren.com/share/121149331/4037035746, it seems that it has been turned many times. Follow the blind coax.
What this article is trying to say is that the guy called the PRD document is just a name. The problem with PRD is not how to write it but how it is delivered and executed. Here is a brief introduction to my new PRD writing method based on axure rp. (Friendly reminder: never use axure, please pass by if you think he is cumbersome.)
From the day I stepped into the door of product manager with half a foot, I was deeply entangled by the names of 2 documents, they are Market Requirements Document (MRD) and Product Requirements Document (PRD). No matter what direction you are PM, these two things will always accompany your Title to follow you. These two documents are called and written differently in different teams. I have also seen that the MRDs of some teams are actually PRDs, which do not involve the slightest commercial market analysis. Of course, these are not the content discussed in this article.
For a long time, there has been a very interesting phenomenon: "Is there a PRD template, and how should PRD be written?" This question has become one of the classic must-have questions for beginners; if this guy is still in this industry a year later, he will definitely Complain, mother, our QA doesn't read my documents at all, our interactions (if there is this position) will still ask me some questions that I clearly write, our tests hold the documents and ask me how to test ,
The relationship between Web pages is meshed, while Word documents can only be expressed in a tree form, which is undoubtedly contradictory; PRD documents cannot be updated and released in real time. I reviewed the PRD documents I wrote in the first year, many of which are as follows The modification column is empty, I am ashamed...; The so-called picture is worth a thousand words, and ten thousand words are just enough for the document standard. Every PRD is smelly, let alone interaction designers. Many PMs I don't even want to read it when I'm done writing it. Therefore, I arbitrarily believe that writing some PRD documents is really a time-consuming, laborious and inflexible thing (many PRDs are one-night stands, they will not be modified after they are written, and no one will be willing to read documents with more than 100P), It is letting product managers achieve chronic suicide!
Personally, a PRD document needs to include the following content:
1. Overview
1.1. Description of terms: terms involved in the document
1.2, product overview and objectives
1.3, product risk estimation
1.4, product development progress: product development stage and responsible person Time node
2, user requirements
2.1, user requirement description: define who the user is
2.2, administrator requirement description: background management part (many people will ignore this part)
2.3, task flow chart: from business logic flow to product logic Process transformation
3. Functional requirements
3.1, Functional overview
3.2 Functional requirements decomposition: interface decomposition and interaction description and use cases
4. Non-functional requirements: auxiliary products associated with the product
5. Online and offline requirements: product life cycle
6. Operation Planning: Feedback and improvement after product launch
In the whole document, the biggest part is actually the decomposition of functional requirements, but the core part is the user requirements and functional requirements. After using Axure, I found that Axure can well carry the entire content of the product requirement document I usually write. The main problem is that Axure can be displayed in a mesh. Here is an example:
In the site navigation of Axure, the default Home page assumes the first part of the PRD document; the user requirement description and task flow chart can also be completed by the flow chart function that comes with Axure; the decomposition of the task flow page is originally in Axure Completed; the final non-product functional part can also be completed by axure (text block component). At the same time, Axure supports output in multiple formats. Generally, I send it to the team Html file package, or it can be a file in .chm format (Team collaboration has not been tried yet). After the package is opened, the left side is the navigation menu of the whole system, and the right side is the corresponding description. The main thing is that the pages in the prototype can jump to each other (thanks to the powerful interaction function of axure), and the pages have the annotation function. Therefore, the entire product requirements document truly realizes product-based simulation and web-like propagation, rather than Word-like tree-like reading.
1) I have seen many novice prototypes generated by Axure have blank pages. I asked why, and he said that this page did not know what to put, but he had to name it, otherwise the logic would be unreasonable. In fact, this blank page can be used to put the flow chart and overall description of the page.
2) It is not recommended to do too complicated Axure actions, such as using multiple layers, dynamic panels, etc. Because in the eyes of engineers, etc., the prototype diagram cannot be clicked (based on the inertial thinking of viso, etc.), so in order to avoid taking a long time to realize a dazzling axure interaction and finally being buried, it is recommended to decompose the task to draw . For example, an input box needs to be drawn: the default state, the focus state, the input character determination state, the focus loss state, etc., which are displayed in logical steps. (I will show it step-by-step when I'm particularly sick, and then make a more dazzling interaction on it to play by myself or for demonstration)
3) At the bottom or side of each page (determined by the size of the page), a text block with detailed functions should be placed to describe the functions of this page in detail. You can also directly use Axure's own annotation function (component annotation, page annotation). Why is it not recommended to use Axure's component annotation function? Because this function is hidden in the generated prototype, it may be ignored by others.
4) Using axure's component library function (can be self-made) and module function can not only ensure the unity of design (design specification), but also improve the efficiency of prototyping. In the picture I used the registration module.
Below, QA time (this QA is a question and answer, the QA in the text is a technology, uh, pay attention to the distinction)
Q: Why do I see that some books say to write more than N documents, and those with RD include: BRD, MRD, PRD, ....
A: Yes, there is such a definition. BRD (Business Requirements Document), MRD (Market Requirements Document), PRD (Product Requirements Document). Each company's style is different, I personally tend to integrate BRD with MRD, and PRD alone. But there will be overlapping content in MRD and PRD, that is, who is the user will be mentioned at the same time? Why do it? What is the product goal? wait a few questions
Q: Axure has a function that can be imported into Word format. After importing the prototypes, they are classified and include use case documents. Why not play like this?
A: No one said you can't play like this. Again, that's a personal habit.
Q: In addition to the page prototype, you have stuffed so many things into Axure, will it cause the source file and the generated file to be huge?
A: In fact, the stuff inserted is all text. It is done with the text component of axure, and the volume is not large. At the same time, please don't use too many pictures when prototyping with axure, try to use components and modules to complete. One of the largest prototypes I've done in my current position is the 4.7M, which is a complete system prototype.
Q: According to your way of writing, Axure seems to be omnipotent?
A: There are no tools that are not easy to use, only people who are not comfortable using them. People are alive, tools are dead, and Axure is currently not very powerful on the mac platform, and many people think that axure is cumbersome and prefer lightweight prototype functions. However, these are not the core issues, the core issue is getting your team to work together at maximum efficiency. People who use Axure don't have to despise Viso, people who use Excel don't have to envy OmniGraffle, and people who use Word don't have to miss firework.
Since I mentioned MRD, I also want to talk about my habit of writing this document. In general, this document is for the boss to see, mainly for the analysis of the market, the analysis of competing products of similar products, the profit forecast of our products, and so on. Therefore, it is generally done by PPT. The longer your document is, the more disgusted your boss will be, and the more text you have, the less interested your boss will be. Therefore, PPT is the best way.
The document is similar to the process, and large companies will attach great importance to this matter, because it is necessary to avoid risks. The core point of processes and documents is how to efficiently transfer and how to execute quickly, not how to write them in what form. Compared to small teams, process woes can be avoided. Of course, if a big company can make a big product with a small team mentality, it will do more with less! I believe more in the power of a small team, a big product, rather than a big team and a big product.