Traditionally, the practice of writing product requirements documents (PRD) is to put use cases, flowcharts, and Web page prototypes into a Word document. Generally a product contains dozens of or even hundreds of use cases, each use case has its own flowchart, each flow chart contains a few more than a few more than dozens of of the Web page prototype, the result is the product requirements of the document become huge, write the person fees, read people more miserable.
Since I've been tortured by documents like this, I've been thinking about how to make the document simpler so that the reader-usually the designer and the programmer-can understand the product design in the shortest amount of time.
When I was a UI designer, I created a way of using a flowchart to represent product interaction, a method that was popular with many people, and this article also caused a certain response. In fact, at the time of actual use, I not only produce such a flowchart, but also use the hot area of the web, the interface elements in the flowchart (blue Element) and the prototype page (HTML file) to combine, so that designers and programmers looking at the flowchart, as long as the mouse click interface elements, Can be connected to the prototype Web page, very convenient! I have been using this method, but it was not written in the article.
Later, as the nature of the work changed, I needed to think more and more about the whole and the function of the product, instead of just focusing on the interface in the specific requirements as it was, I began to look for the possibility of integrating the use case into the approach. After a period of exploration and practice, I gradually formed their own unique set of product requirements of the document, in order to express the difference, I call it "product design documents", referred to as PDD.
This article is the introduction of PDD.
Part of the PDD
The PDD has three components, which are use cases, flowcharts, and prototype diagrams respectively.
Case
The use case defines the functionality of the product from the overall context. For example, for a messaging system, the "Write Mail", "Send Mail" and "Delete Mail" features are use cases.
Use cases are more prevalent in the writing, in each use case to indicate its pre-and post conditions and anomalies and other attributes. In PDD, however, I completely discarded the above attributes, retaining only the name and brief description of the use case. Because the starting point of a "use case" is "user," if you're looking at a product's functionality from a user's perspective, you'll find those attributes that you don't even think about. And, all kinds of back and forth conditions and anomalies, can be placed in the flowchart, so more clearly.
Flow chart
A flowchart is a refinement of a use case that clearly shows all the relevant predecessors, backend, and branching conditions for a use case. The drawing of the flowchart I have made it very clear in the article "a little bit of experience in painting a Web flowchart", and I will not dwell on that. The only thing to note is that I didn't realize that the flowchart itself was ISO standard, so the flowchart elements used in "painting" do not conform to ISO standards, and are not the same as some of the already formed systems (such as the "description of information structure and the graphical glossary of Interaction Design"), Therefore, there are some problems in the use of elements. In the daily work I have made changes to the use of elements, I will later have time to update the "painting" the content of the article, it is possible to directly release the template.
Prototype diagram
The prototype diagram is an expression of the "interface element" in the flowchart. There is nothing to say about this thing.
PDD's Way of behaving
Use cases, flowcharts, and prototypes are generally the things that are already in the production demand document (PRD), and PDD is no different from PRD at this point. And the following to say the way of expression, is the essence of PDD. I am more ignorant, and have not seen anyone like me to organize these three pieces of content, so I think this is my initiative.
Use Cases and flowcharts
First, combine use cases and flowcharts. The method is simple, using the frame label of the Web page to create a few frames:
- index.html-another two frames container, no need to explain.
- navigation.html-navigation frames for use with a list of used cases
- main.html-default main frame for document introduction, author, version, and update log things
Then create a bunch of web pages, put all the flowcharts in these pages, and each flowchart (i.e., each use case) is placed on a Web page, and then modified navigation.html to link the use case name to its corresponding page. After the completion, the page should be the following:
PDD Document Home
Use case on the left, flowchart on the right
OK, the left side is the use case, the right-hand side is the flowchart, so the use case and flowchart are integrated, and the structure is clear and easy to view.
Flowchart and prototype diagram
The key to consolidating flowcharts and prototypes is to provide a convenient way for readers to see the prototype diagrams included in the flowchart. In order to achieve this goal, my approach is:
- When you use OmniGraffle to draw a flowchart, select the interface element (the blue one), then select "Open File" in "Inspector"-"Properties: Action" and press "Select File" to locate your prototype and press "OK" so that you can link the element to the prototype diagram. As shown in the following illustration:
- When you output this flowchart document in OmniGraffle, instead of selecting the image, instead of selecting the "HTML image map," The Blue interface element can be clicked on the generated Web page, and then linked to the prototype map. It's convenient, right? But that's not enough;
- With Lightbox, all the picture links are changed to pop layer, this time and then click on those links to see if the effect is more wonderful?
Well, in this way, the product design document (PDD) effectively integrates the three pieces of the use case, flowchart, and prototype diagram.