How to write product Requirements Document (PRD) based on five elements of user experience

Who are the users of PRD?

First of all, I would like to share a word with you: manage the requirements document as an “Internet product”, understand its users, pay attention to its experience, and keep iterating to maximize its value. (reference)

Since it is regarded as an Internet product, we need to think about who the users of PRD are and what they want to know through PRD.

According to users and what they want.

I divide PRD into several stages:

1) MRD stage

At this time, we mainly need to convince our boss, or internal team review, there will be demand side, let everyone agree with your plan, know what you want to do and how to do.

So this is kind of like MRD, where you just make the whole route clear, and you can make a really bold DEMO.

Do not do detailed design draft, not to write detailed function description, because at this time is very likely to be shot.

2) the PRD V1.0

If you pass the first step of the review, then you can do detailed content, do a relatively detailed DEMO diagram, this step for development, interaction, development of technical evaluation.

Interaction is the real next step, and will pay attention to some of the details of the page, so at this time can make a detailed DEMO, with some instructions on the right side of the DEMO to facilitate interaction and UI work.

Don’t write detailed interface instructions, but do write some business logic while you’re designing the interface.

3) the PRD V2.0

This is the full version, so detailed content, only the real development of the function of the students will look, write fine write all have no to say.

Now that we know what different users want, let’s talk more specifically about what PRD writes.

2. PRD compilation centering on user experience elements

Why should WE write PRD around user experience elements? Because product design is based on this classic framework, the task of writing PRD is of course to make this content clear to everyone.

User Experience Elements

Here’s how the PRD is written around this.

Part ONE: Requirements overview

In fact, it is not only about making products, but also about anything. The first step is to clearly figure out what to do and why to do it, that is, to clearly describe the strategic layer. The first part of PRD is to make this content clear and answer the following questions.

1) What does the user want? — Users’ pain points and demands

Suggest the content, make clear the overall problem pain points, but also specific case, enumerate numbers, such as the user’s use frequency, the current cost and so on.

2) Who is the user? — User segmentation, number of users, portrait

Who the user is is not a broad description such as “business users”. It is necessary to make clear that there is a relatively specific portrait of the current function, what kind of users are required in what scenarios, and how the user level is.

3) What does the user get from this? — User revenue

Yu jun there added content, the teacher once said, user net income = new experience – old experience – replacement cost, replacement cost may be obtain costs, cognitive cost, capital, etc., while the content is not measurable, but being a new product to assess its value from the Angle to think.

4) What do we get? — What benefits will it bring to the company

This is very important, to make any product, to empower users, to bring value to users, its main purpose is the enterprise itself can profit, this point to convince the boss to provide resources.

Part TWO: Product planning

The next step is to outline what needs to be done step by step to achieve the various ideas and goals listed above. That is, to clarify the scope of the content.

1) Function & information structure diagram

The scope layer is to clarify what is being done, what is being done, and what is being provided in order to achieve the strategy. This is usually represented by a brain map or block diagram, which explains what data we need, what functions we need to do, and the relationship between functions.

Note that this part requires thinking along the whole route to solving the problem in the long run. For example, you might want to create a review feature to let users know more about the product and drive more sales. The first step is to add the comment function, and then we can analyze the comments, recommend high-quality products for users, find out the problem products to ensure the quality of products on the platform and so on. Something like that, a big picture.

2) Route planning

Blueprints are out, but they still have to be implemented. Therefore, in this step, the blueprint should be cut into pieces. What should be done in each step, how long it will take, what kind of problems should be solved in this stage, and what paving will be provided for the future. Some content, also can give a simple DEMO diagram, can describe clearly.

Part THREE: Function overview

This section is a detailed description of what we are going to do in the current episode. The main users of this part are UI, interaction, development and testing. Specifically, when it comes to doing things, it is to bring everyone’s cognition together.

1) Product flow chart

Each user of PRD can be quickly and conveniently informed of the thought flow of this function through the way of graph. It starts with a bold flow chart, such as a buyer buying an item, adding it to the cart -> paying -> merchant shipping -> confirming receipt of the item. And some details, such as the buyer overdue payment, or the seller to modify the price and so on, can be written to the specific point of this function and then a detailed flow chart.

2) DEMO, prototyping, no need to say more.

3) UI draft, this is UI after students finish, put up, unified access to relevant materials.

4) Product function points will be discussed in detail later.

Add two pieces, flow chart and product function points:

Product Flowchart — UML (Unified Modeling Language)

Unified Modeling Language (UML), also known as the Unified Modeling Language (UML), provides Modeling and visualization support for all phases of software development. In short, it describes things graphically. There are two concepts here, classes and objects. A class is an abstraction of a class of things, and an object is an instance of a class. For example, if a car is a class, a car is an object. For product managers, the two terms are essentially the same.

Next, I will take the case of the employee submitting permission approval as an example. The corresponding class (or object) is the employee, boss or approval sheet, and I will introduce four diagrams to you.

1) Activity chart

We often call it a flow chart, which describes the flow of work between roles.

The rectangular box describes the current activity, and the diamond block lists the bifurcation route. If there are multiple roles, as shown in the following example, each role is assigned a swimlane, and the activities corresponding to the role are placed under the swimlane.

2) Sequence diagram

This diagram is a description of objects, somewhat similar to the activity diagram, as shown in the following example. In our daily work, we can choose one of them to make things clear.

Each object has a lifeline here, I’m single out the system itself, made a lifeline, employees and the boss after for some operation, require the system to the surface to save or change state, the right is corresponding with the database interactions, the back-end students on the basis of this, when roughly understand myself to do something.

3) State diagram

Although the style of the state diagram is similar to that of the activity diagram, the content is actually quite different. The state diagram is to describe the different state transitions of an object. For example, in the case of permission approval, there are three states of “approval”, “not approved” and “approved” in the approval list. The transformation mode of each state can be clearly understood through this figure.

4) class diagrams

Describe the internal structure of a class and the relationships between classes.

Again, we have three classes, employee, approval order and boss, and they have some attributes, and some operations for employee and boss, which can be represented by this class diagram. There is a +- sign, the + sign is public, which means other classes are visible, and the – sign is private, which means other classes are not visible. For example, the name of an employee is not known by other classes, but can be obtained by some object operation. This is some partial development of the content, not special need to develop students know the information, can not mark this part.

Detailed description of product functions

This one is to make the features detailed enough, but there are some tricks.

1) Update instructions

First of all, I usually have a list of updates at the top of the list of features, usually recording: change of time, change of feature blocks, and details.

2) Global description

Each function may have multiple pages and multiple function blocks, but there are some reasonable places, such as for data products, the display form of numbers, retain 2 decimal places, increase the three-digit symbol, etc.; For mobile products, some operation methods, etc. This applies to each block and does not need to be specified separately in each block, and other functions can be reused later, which can be listed first.

3) Specific function description of each block

And finally, the rules for writing this

Part FOUR: Data requirements

As I am the product manager of data products, this part is very important for us to clearly record the dimensions and indicators needed, the source database table fields of indicators, and the calculation caliber.

After that, there is a content that may often be neglected, is the collation of data. Take a treasure search results page as an example, generally will show pictures, title, price, sales volume, seller name, package will be marked out, these RD through the UI draft may be viewed, but some such as mouse into the display information, click operation, whether to buy, are reflected in the display of goods.

These contents, we can not expect RD students from the UI draft a little bit of discovery. So list such a table, you think the class and its attributes list clearly, similar to our above class diagram object attributes to describe the content, the purpose is to let the development students compare this to carry out the library table design, do not miss some points.

Part five: Data burial point

Including button burying point & content burying point, can be through screenshots + table description, screenshots indicate which controls need burying point, table description of the corresponding control information, such as PV, UV, input content, etc..

Part vi: Effect evaluation scheme and on-line arrangement

For C-end products, this content will be more important. Generally, there will be a gray release process, so it is necessary to clarify the way of gray release, volume arrangement, rhythm, indicators that need to be concerned, how to evaluate this indicator, and to what extent can all be online.

Part seven: Personnel scheduling

OK, we’re done.

Iii. Carrying capacity of PRD

One last point: PRD storage.

I’ve tried several ways to do this, including doing it in Axure, which is explained on the right side of the DEMO, but the downside is that it’s not the best way to do it: after you update it, you have to send it to everyone, and it’s hard to store each version and download and decompress it in Axure itself.

Now I usually use wiki to complete, as long as a link, update as long as inform everyone to synchronize the information is good, is when writing the function, need to put the DEMO corresponding picture on, RD can be more convenient to know which piece of content description.

For the above content, I usually split it into two wiki pages, one for requirements overview and product planning. One that records product features and what comes next, and this is the current issue. The structure of an overall score.

The above is my personal PRD writing experience summary, I hope to help you. However, the preparation of this PRD is not suitable for all companies. A perfect PRD takes a lot of time. For large companies, there are many receivers, so it is necessary for such a document to unify the cognition of all parties. For startups, it is more important to launch products quickly for verification, so do not spend time on PRD at this time.