First, reading needs

The first thing to do when you get a feature is to read the requirements in their entirety. In reading requirements, try to do the following as much as possible:

• Don’t understand requirements from a developer’s perspective, but from a user’s perspective. When reading the requirements for the first time, do not think about how to achieve them, but based on the requirements themselves, sort out the logic of the requirements, and timely communicate with the product if there is any unreasonable place;
• For complex business, if the process is not clear, you can draw a flow chart to help understand. (Good at using tools to solve complex problems)

Tips:

1. In order to verify whether you have really fulfilled the above points, you can make a hard and fast rule for yourself: after reading the requirements of each function point, you should organize at least 5 questions and discuss with the product.
2. At this stage, you need to be diligent in communicating with the product to prevent rework problems caused by a poor understanding of the previous requirements. In addition to understanding some of the heart of the product’s requirements design, you can also help the product think in more ways and improve the product by putting your ideas together.

Split requirements

Now, assume that you have gone through the requirements process thoroughly and have a good understanding of the requirements. Next, think about the implementation, but don’t worry about the implementation. Instead, break down the requirements and tease out the implementation process. At this stage, you need to think about these questions:

• Which feature points are important and which are secondary? In general, function points on the process line tend to be important, because the absence of these function points causes the process to fail and therefore needs to be implemented first. Other function points that are not on the flow line are called detachable and can be installed or removed at any time.
• Which feature points are easy and which are difficult? In addition to breaking down function points by importance dimension, it is also necessary to break down function points by difficulty dimension and implement them according to the principle of easy first, then difficult.

, for example, we want to achieve the function of a blog add/post, for readers, there is nothing more than to see the title and content, so for the articles are placed at the top, what belongs to the classification, is there a thumbnail, in the first version, is not important, and in the subsequent versions of these functions can be installed at any time.

After splitting the requirements, we can break down the functional points and implement them in the following order:

Understand data structures

On the surface we’re using software, operating functions, but ultimately we’re operating on data, or information, and it’s important to understand data structures. There’s a guy named Eric Raymond, who wrote a book called The Cathedral and the Bazaar, which sums up the success of Linux, and he says:

Smart data structures with clunky code are better than smart code with clunky structure.

At this stage, you need to do the following:

• Tease out the data structures of functionality and correlate them. If the relationship is too complex, you can use diagrams to help understand it.
• Think of the rationality of data structures as designers, not implementers. If you were to design, how would you organize your data structure?

Tips:

1. For the back end, the data structure is a table structure; For the front end, the data structure is the return value of the front and back end interface convention;
2. At this stage, you need to communicate with the designer of the data structure. In addition to feeling the subtleties of various structural designs, you can also offer your ideas and solutions to help designers improve their designs.

4. Functional design

Next, we need to design the whole feature globally. At this stage, you need to consider these questions:

• What function points are common (or reusable)? Find the common parts and prioritize them in preparation for specific functionality later;
• What is the style and interaction of the interface? If you don’t know, communicate clearly with the product and artist in advance;
• Determine the order in which each function point is implemented. In general, try to design the order of implementation of function points in the order of flow, for example, implement the add article function first, then implement the article list function, because the latter depends on the former.

Tips: Common parts can be styles, utility functions, common components, or even common pages.

Five, the key points of function realization

Everyone has different ways and techniques to implement features, and while you can do whatever you want, don’t forget the rules of functionality:

• Load state. Information is presented to the user before a long waiting process, during this period, must not present blank content to the user, design a good loading effect, clearly inform the user: please rest assured, I am trying to load;
• Submit state. Users submit information to the remote server is a long waiting process, during this period, we should pay attention to clearly inform the user is submitting, but also pay attention to close the submission entry, to prevent users from submitting multiple times during this period, so that the server produces redundant data;
• Empty state. The server may not always have information to present to the user. If not, be careful to explicitly tell the user: sorry, I don’t have data to present yet;
• Error state. The server may not always be able to give feedback to the user’s operations. If the operation fails, the server must clearly inform the user of the failure. It is better to inform the user of the failure cause and the recovery method at the same time.
• Interactive mode. The liveliness of functionality lies in the interaction, and each interactive element needs to be given appropriate feedback (color change, size change, dynamic effect, etc.) as the user operates.

Tips: Getting the user experience right requires a lot of thinking, and the truth is that not all developers know the rules of user experience. Don’t worry, there isn’t a solution. You need to really put yourself in your shoes and think about things as a real user. In short, do what the user wants, not what is easy to do.

conclusion

1. Communicate with the product in the collation stage of requirements, ask questions about problems you do not understand, or put forward constructive suggestions;
2. In the data structure of the collation stage to communicate with the backend, do not understand the design questions, or put forward constructive comments;
3. Communicate with the artist during the feature design phase to validate the UI and interaction, or make constructive comments;
4. In the process of function implementation, meet any problems, communicate with others, put forward problems and summarize solutions, form documents;
5. At each stage, you need to think of yourself as a user, and how “dumb” that user is, your feature implementation will be.