Requirements documents, as the basic skills and key outputs of product managers, are actually unsatisfactory for many students. You can refer to the author's practice to check your own practices and documentation to see what can be learned.
This article focuses on the scheme design and process management stage in the project implementation, and the main content revolves around [product scheme design], which is divided into:
- The overall description of the product design: what it is, the core goal, the tool, and the overall process
- Pre-analysis and action dismantling of requirements documents: how to determine the main process, refine key nodes, functional design and interaction
- Requirements document template: which modules are included, what each module outputs, and what is the purpose and role
- How the requirements document page is annotated
- Product Design Considerations
First, the overall description of the product design
Second, the preliminary analysis and dismantling of the requirements document
1. Determine the main business process and functional modules first
1. Purpose: Understand the background, refine the roles and systems, and pave the way for the logical dismantling of the system
2. Output content: user stories, business processes, and functional modules
2. Then sort out the key nodes according to the functional modules
1. Purpose: Dismantle in order to design specific functions
(1) The role of a single system
(2) Logical flow between multiple systems and multiple roles
2. Output content: system flow chart, timing diagram, key nodes and states of core modules (and even page flow charts)
3. How to output key nodes
(1) Disassemble a role function module of [Function Module 4 - Refined Version] in the table in the previous step
(2) Select the modules that need to be dismantled for refinement, and the actions are as follows:
- Exhaustive actions for the character, that is, a collection of actions
- Pick out the key nodes in the action and connect them in the form of a timeline (there are required and non-required nodes)
- Abstract the stages
- Consider the state of critical nodes
3. Functional design and interaction
1. Purpose: Design what actions or operations the character will take on which pages and achieve what purpose.
Therefore, when designing the system logic, you can draw a page flow chart according to the timeline and key nodes, and use a sketch to mark the actions that require core operations.
2. Output content
- Function list (role, system or tool, level 1, level 2, level 3 function menu)
- Prototype page
- Page interactions and rules
3. What elements should be included in the requirements document?
Fourth, the way to annotate the page of the demand document
1. Method: Split by page module
For example, the personal center page is divided into overview, basic information, and operation modules
2. Form header:
data
Type: Image/Text/Number
Actions: Click to jump to
Note: Data caliber/source
3. Examples:
5. Precautions for product design
1. Completeness of the program
1. Do a good job of adding, deleting, modifying, checking and dealing with all abnormal situations
2. Evaluate whether there is any omission or a better solution
3. Pay attention to the impact on the stock data
4. Each node of the current process should be considered, and after sorting it out, see which nodes the current function can solve
2. Versatility, lightweight and effectiveness
1. Business is always changing, and it should be flexible enough to adapt to a variety of scenarios
2. Adaptation method:
(1) List as many scenarios as possible
(2) Pull a constant factor to find the essence
3. Avoid manual review and other heavy operation content, and reduce the uncontrollable factors caused by manual operation. If manual operation is required, the system must be traced
4. Try to solve the full problem at one time, or solve the full aspect of a problem. Don't patch previous versions
6. Summary
This article is the author's careful combing of how to write a product proposal/requirements document, and the content information is condensed from my own experience in various types of products and projects.
The product proposal is the key output of every product, and I would like to call it one of the guys who eat. A good requirements document can improve the readability of development and testing, development efficiency, reduce errors and omissions in product design, and reduce the embarrassment of being judged during product plan review.
This article was originally published by @刘一手 on Everyone is a Product Manager. Reproduction without the permission of the author is prohibited.
The title image is from Unsplash and is licensed under CC0.
The views in this article only represent the author's own, everyone is a product manager, and the platform only provides information storage space services.