Some people say that there is no conclusion in the web front-end during product development, only constant modification as required, but the project must have phased conclusions. As a front-end development, how to avoid the dilemma of repeated changes for a certain requirement? Don't push all the responsibility to the constant demand changes of the product or the constant visual adjustment of the design, you can actually do better. It is also important to broaden one's knowledge and find the correct working posture when constantly pursuing new technology and polishing technology for excellence.
First of all, mentality is very important.
If you expect your work status to be like this: product managers consider every aspect of a functional requirement, comprehensive coverage of every detail, and perfect expression of every idea (of course, this is what a good product manager should pursue And achieved), interaction and vision can perfectly interpret the product demand points from the perspective of user experience and aesthetics, and then prepare all the pre-communication requirements for the needs, and give it to the development to start production, and then you as a front-end development, with Work together in the background to restore the functions and details described in the product requirements document one by one. Occasionally, as a development, but also as a user, put forward some logically unreasonable points to the product, communicate and finalize, and finally complete the development, and the product visual experience feels OK, you can go online.
In the first few years of work, you must have been very troubled, because you may always be struggling with these problems:
1. After implementing the function points according to the product requirement list, the product manager experienced that the overall process logic was too cumbersome to run, so change it!
2. The visual walkthrough found that the page is inconsistent with different screen sizes according to the size given by the visual draft. Change it!
3. The interaction found that after the logic of the product was changed, the entire interaction became unfriendly, and the interaction plan needs to be re-adjusted, unhappy, change!
So you find that as a front-end development, you have to make a big change after completing your development volume on this demand! And you have to tell yourself that everything depends on the perfection of the product, and when you find a problem, you have to do your best to cooperate with the change.
But you must still have a small complaint in your heart. The product manager started to design and develop before he thought about the needs. The designer of the imperfect interaction design did not find it in the design process. It was their unprofessionalism that affected the development progress.
If you always think about the problem from this perspective, as a code porter that can be replaced, and expect your partner to solve all the problems perfectly, you can only do nothing while complaining, and don’t forget that you are in a team. , How to help the team accomplish goals more efficiently, and how to control the rhythm autonomously is very important.
The product manager's ideas when facing a vivid page are much richer than when facing the function points described in the brain or in the document, and the front-end development includes the most comprehensive product details. So, as a front-end development, you can do more.
In the early stage of product presentation, based on previous development experience, you can put forward more details about the product, and the supplement of these details can make the interactive vision more comprehensive in the design. In the development process, you will have a comprehensive and in-depth dialogue with the product you are developing. Every button, every piece of information, and feedback corresponding to every user operation must be covered by your program, so it’s timely The product vision communicates the expression of these feedbacks together and whether it needs to be adjusted to avoid secondary changes after the development is completed. In the component design stage of development, how to reasonably encapsulate component logic and appropriately reserve flexible entrances is also extremely important. My opinion is that componentization is not only for code reuse by developers, but also for rapid adjustment and modification of page modules.
These points of attention, as a slightly experienced front-end development, may have their own set of implementation methods, but how to implement them better and more efficiently in teamwork. Some people say that there is an advantage for developers to switch to product managers because they have more rigorous product logic thinking, but I think product managers, designers, and developers should be interoperable. Of course, product managers pay more attention to product thinking and understanding of the market. But it also needs to have good logical thinking and understand basic visual norms. Designers, especially interaction design, need to understand the rules of user experience and have a good aesthetic, but they also need to understand the basic elements of the product and understand the complexity of development. Therefore, developers should constantly enhance their product thinking while constantly pursuing the most refined technology. Only by understanding the real product requirements can they discover potential problems before or during development. Only by understanding the basic principles of design can they be reasonably Throw out possible risks and unreasonable, adjust the plan in advance.
Product thinking
When the product manager lists no less than five or six corresponding response modes for a user’s click behavior, he talks to you about user behavior guidance and user conversion. Please understand its rationality, and even give more details to confirm that it will make later Development is more efficient. There are many books and researches on product thinking on the Internet, and extensive research is more helpful to cultivate your own insights.
3000 front-end promotion learning group: 296212562 sharing technology, technical exchanges, learning tools, the latest technology videos, troubleshooting.
Basic principles of design
Stop struggling with the 1px problem, complaining about why the design eyes are so venomous, why you seem to be indistinguishable from the implementation of the design draft, so many questions can be singled out. At the same time, from the size of the mobile terminal iphone4 to the google nexus6, from the 12-inch to the 29-inch display, a static design draft can not cover all the display sizes in most cases, as the development closest to the output of the product. Personnel, you need to communicate with the design to give the most reasonable compatible solution.
The collected online reviews are more suitable for entry-level design books:
《The Design of Everyday Things 》
"Broken Cocoon and Become a Butterfly-User Experience Designer"
"The Door of All Wonders-The Way of Website UI Design"
"Design Book for Everyone"
Component thinking
The two points mentioned above need to slowly accumulate understanding in daily life. Now we are going to talk about the familiar point of our front-end development, component thinking. This is not to talk about the front-end componentization scheme, but the starting point of component design.
1. Develop the habit of code componentization, it will make the addition, deletion, and modification of your page modules more elegant, and management and reading will be more comfortable.
2. Collect parameter entries and maintain scalability. When designing components, it is impossible to design and implement all possible changes. However, if components are to be reused, future changes or additions of new functions are inevitable, so keep them well. Scalability is very important. If every modification takes a lot of experience in forward compatibility confirmation, it will lose the meaning of componentization.
3. Code documentation, component maintenance is not an easy task. After the code forms a documented style, it is a self-regulation in itself. When different people modify or use the code, they can reasonably follow the component specification without additional specification documents. .
4. Reasonably control the granularity of components, and measure the cost-effectiveness of component complexity and modification reuse degree according to business requirements.