As a web front-end practitioner with a few ideas and as a practitioner, it is inevitable that you will have to deal with different roles in a project. Some make you feel good, some make you feel bad; Some make others feel good, and some make others feel bad, of course. We certainly hope that the best outcome is that everyone feels comfortable getting things done. This is where this article will discuss.

Roles in the project

According to my own experience of the project, I roughly divided into the following roles. Then make fun of “anecdotes” with other characters from a web perspective. Also describe what I think is a better way to deal with it.

The product manager

I understand the product manager as a wet nurse for all the other roles. You can go to him for all your questions. But in the first place, he was the reason the project started. I think the responsibility of the product manager is:

  1. Competitive product analysis. This is important. Know your enemy and you can win a hundred battles.
  2. Requirements management. Collect requirements from various sources, then summarize, organize, review, combine, and delete. Finally, successful energy is transformed. The requirements management process can involve other people. It is best to have a demand management system for demand management, convenient for everyone to synchronize information. As long as you can achieve demand input, demand comment.
  3. Statistical analysis of user behavior. This is the only objective data a product manager can use to convince other roles. Our product is for the end user. The frequency of use, the use of feedback is the best argument. For example: the product manager asked the Web front end to change the icon navigation on the left to icon and text navigation, under normal circumstances, the Web front end will certainly think that the product manager is messing around again. If the product manager points to user feedback that “70% of users have no idea what this navigation means”, his claim becomes even more convincing.
  4. Smart design. Sometimes NB features don’t have to be technical. If we can skillfully use some of the existing features that are ignored by ordinary people, and then design a dazzling function, it will make the product more dynamic. For example, I saw an APP before, which can save a large number of contacts and phones by using the mobile phone address book, and make local identification of some nuisance calls that have been identified, so as to subtly realize the blacklist prompt function of unjailbroken IPHONE.
  5. Product design. That’s a big generalization. It actually contains many functions, such as:
    1. Product process design;
    2. Product specific function design;
    3. Product role design;
    4. Prototype design;

The designer

There is nothing to be said for designers, but to embellish the product manager archetype based on their understanding of it. B: Yes, it is.

  1. User experience design;
  2. Product style design;
  3. Visual style design;
  4. Navigation design;
  5. Brand packaging design; Here, and front-end related, mainly is the interface of the product (we are still talking about the Web project, although the Internet project still has to have an APP, skip here, later have a chance to talk about).

The front end

Here refers to the Web front end, if there is APP, also mainly refers to H5. The output of the front end will eventually be directly to the user. You may think that the designer’s design draft is ultimately for the user ah? But who’s ever seen a page go wrong, whether it’s the user, whether it’s the product manager, whether it’s the backend, whether it’s the tester, whether it’s the boss, who’s ever gone to the designer? It’s always the first reaction look for the front, look for the front. As a front dog, I know.

The background

Developers who provide data to the front end and implement the core business of the product. All the data on the front end comes from the back.

test

There are several kinds of tests,

  1. Functional testing. Write functional test cases based on PRD and prototype of product manager, test item by item;
  2. Interface testing. I have assumed here that the architecture of the project is in a back-to-front separation pattern, and therefore, the general tests will separately test the interfaces proposed in the background.
  3. Interface testing. Very few projects require this test, and if you do, congratulations, your product is already mature. Interface automation testing, the most time-consuming, laborious, and not necessarily effective. There are a few solutions currently available at various companies that use nothing more than an interface less browser scripting framework like PhantomJS, along with test cases written with test scripts. If the interface changes frequently, testing can be exhausting. A previous project (or product?) THAT I worked on. In order to solve the impact of frequent interface changes on the test script. I proposed a solution that would make it easier to write automated test scripts with simple commands and logic like a Domain Specific Language (DSL), instead of human text statements like Excel or test case management systems. Working with testers, it was only used for smoke testing after the release.

The boss

Needless to say, the boss is the biggest, and the boss is the biggest user. 【 Cover one’s mouth not to laugh 】

How to communicate with product manager?

  1. Prototyping is the basis for communication between the front end and the product manager.
  2. There will always be situations where the rules for data entry are not clear. Remember, at this point, after speaking with the product manager, it is important to ask the product manager to update the prototype. Otherwise, after a while, the testers take the prototype design and find a bunch of bugs in your interface, and you can cry.
  3. Be sure to check with your product manager before you start with what won’t change and what may be expanded in future releases. Of course, the product manager to you hit the guarantee you had better not believe, or to combine their understanding of the business, do a rainy day, otherwise when the time comes, the product manager said to you to change a completely unexpected function, you say the change will affect the overall situation, is useless, bitter or your own.

How to communicate with designers?

  1. The best way for the front end to communicate with designers is through style specifications. The style specification doesn’t have to be CSS, just a descriptive notation that the designer can understand. For example: can be agreed with the designer, there are 3 kinds of buttons, respectively: BTN1, BTN2, BTN3. The designer labels the buttons bTN1, BTN2, bTN3 each time he produces a design draft. And then we go to the front here, maybe some corresponding class: bTN-main, bTN-sub, bTN-third. In order to facilitate the designer design, after the designer completed some basic control style, you can organize a set of template control library, convenient for the designer to follow the page.
  2. With the aforementioned convention. Skin, that’s the natural thing to do.
  3. For some designers’ unconstrained design, remember to weigh in from the technology. If the difficulty of realizing a certain effect is greater than the final experience effect, it is best to communicate and downgrade. If there is clear evidence (in this case from the aforementioned user statistics) that a requirement must be met, the Web front end simply has to go ahead.
  4. When designing an interface, designers often like to find the best state of the interface and then draw the effect. For example, if the data fills a screen, a sidebar is just wide enough for a pop-up layer. At this point, when the design is handed to you, be sure to ask the designer: What if there is no data? What if you don’t have enough width? What about too much data? This is because the design can only show one interface state. And the actual product interface, there are too many states, the combination of various conditions, and ultimately have to be responsible for sorting out the front end.

How to communicate with the background?

  1. The communication between the front end and the back end must be based on interface design documents. Used to be the use of documents, now the best way, is the background interface design time, directly input interface management system, clearly indicate an interface input parameter, input parameter type, out of the parameter, return error code. As long as the problem is found, the interface design document shall prevail, there is no need to fight with the background.
  2. In addition, with the interface management system, the background is also very convenient to modify the interface. Test can also be based on the background interface design definition, connected to the interface automation test program. For example, when the background modifies an input parameter type, the interface management system issues a change event, and the tester decides whether to modify the test case or supplement the test case according to the type to achieve efficient automatic testing.
  3. Sometimes the front end and back end often bicker over who should do some data processing. For example, if the front end wants data in FORMAT A, the back end outputs A different format B for uniformity, so that the front end has to go through it again every time. Here’s what I think:
    1. If it is data formatting, there is a background to a data, by the front-end is responsible for formatting and display. For example: time, the background unified to a millisecond value, the front end to determine how to display;
    2. If it is to a variety of data, the best backend unified processing, encapsulation of a new interface to provide. This is mainly concerned with the performance impact of too many front-end requests. I have a solution to this problem before, not necessarily the best, but also a kind of discussion. Github.com/houyhea/blo…
    3. If there are some data processing, logical processing is in addition to the Web front-end, APP will also need time, then it is best to be unified by the background processing. The front end is always just a visual terminal. So, it’s best not to put a lot of core logic and business to the front end. The way to check whether the core business is actually very simple, is to imagine, if the front end is removed (for example, I switch to a console as the terminal), the whole product or system can still operate stably?

How to communicate with the test?

  1. It is best to participate in the test use case review (if any) in advance to avoid the test raising invalid bugs;
  2. In the actual in-depth development of a feature, all changes should eventually be required by the product manager to be updated into the PRD and prototype design, otherwise, the test will consider it a bug if it is not known;
  3. It is best not to be afraid of the test of difficulties, think more, if the test water, and so on the line, the user to create difficulties in the middle of the night, you will only be honest to shoot up to change the bug;
  4. It’s best to laugh at some of the less-than-reliable bugs raised by your tests. I once encountered a test mm with a bug, because she input a large number of repeated characters, and there are alternate repetitions, the whole produces the illusion of a certain line tilt. She thought it was a bug. I was speechless.

How to communicate with the boss?

  1. And so on everything is done, is ready to go online, the boss personally looked at: this layout is wrong, must change! At this time of your correct approach is: yes boss, I also always feel where is wrong, you said I understand, immediately change!
  2. Your boss is your bread and butter, and his word is your edict. Don’t laugh, because when you get the boss’s job, you’ll be in the front and the back of it.

Write in the last

The above are some of their own thinking and ideas, if you think there is a wrong or better idea, can discuss together. After all, people are good, is really good.