How do I get developers to restore the design in accordance with UI annotations?

When a development engineer asks repeatedly, "What's the point of letting me move 1px here, why should I waste my time doing this" and when I refuse to change, how can I let this development understand and realize the importance of the change? As accustomed to the game company planning, procedures, art staged in the kingdoms of the people, let the @ Carefree old Lee to end the topic bar.

First answer the question, the programmer does not cooperate, 90% above the situation is the demand personnel work not in place.

Directory

is pixel such a detail important?

Why aren't programmers willing to change?

How to solve the product personnel?

What should the program manager do?

　　Is it important to detail the pixel?

Product personnel, be sure to understand 1 pixels in different situations, the importance is different, this is whether you want to find the programmer to modify the premise. Like what

　　1, does the product strategic level value the experience?

Is the company a technology driven, design driven or market driven? What kind of user is this product intended for? This directly determines the importance of detail in the product. Do not know the main company situation, directly to the main "experience for the King" or "designer work is optional", so really good?

The importance of uiue, in the vast majority of cases, enterprise software < professional tools < mass products.

For example, my old club Jinshan background management system, rotten simply let people heinous, not to mention the ease of use, even can not be used to achieve, do not let you undo refill even thank goodness, can be used for many years have not changed. Do you say 1 pixel is important? For many enterprise users, the most important thing about enterprise software is security, ease of deployment, maintenance, and expansion, not whether the UI looks good or/ue perfect. So if you're a UI designer for this product, it's common to have a long tangle of 1 pixels being despised.

For mass products such as Zaker, the user experience becomes an extremely important part in the situation where the underlying technology can be put into place. Any UI can not be aligned, the icon is 4 pixels large, the "iphone" text, color some rotten vulgar situation, will let users think "this product comparison cottage", "with a bit awkward" feeling, directly will cause loss/evaluation of the fall. I think someone who knows the iphone and Android clients must have a deep understanding.

　　2, how important is the detail in the application level?

The same is 1 pixels, in different places are different effects, can not directly say that important or unimportant. As an example

The icon in front of my favorites, what do you think if you move 1 pixels to the left?

This picture and name of my avatar, what do you think if the whole is 1 pixels to the left?

I think most people will agree that the first one is more unacceptable. In other words, the same details, whether it is important to see its environment, the specific problems must be specific analysis. For anyone who wants to make a demand, they have to figure it out for themselves, and then instill it in the people who are making it.

　　3, is the project schedule and priority allowed?

A tendon, is the most new planning product designers most common problems. They don't know the priorities, they always hold the idea of "I'm good for the product" to do the wrong thing.

For example, a game with a serious bug to brush money, operating requirements 1 hours must be resolved. In your eyes, by the way 1 pixel, that is, adjust the coordinates of the matter, nothing difficult. But in the programmer's eyes, this represents the need to recompile, package upload, will greatly increase the risk of the problem. Even if the front-end programmer doesn't have a job, you can't go and get him to change the 1 pixel. At this time, 1 pixel is absolutely insignificant.

And when you write down this demand, after the release, the program will have time to develop and then submit, this 1 pixel may be important.

　　Why are programmers unwilling to revise?

On this point, I'm going to petitioners for programmers. In most cases, the demand providers themselves do not have the bits themselves (most of the cases are extremely poor). including but not limited to the following:

1. There are obvious problems in the unclear requirements

2, the demand personnel usually did not show sufficient product ability, causes cannot let the person be convinced

3, the demand personnel very few to instill the detail importance to the procedure personnel

4, overtime did not give the program to buy Cola

5 、......

Programmers, most of them are very simple people, not so many Huahuachangzi, few deliberately give you face, Shing situation. Just sometimes they will be a muscle, as long as you are professional enough to communicate, generally there is no problem. So is it because the designer doesn't understand the code? Is it the aesthetic consciousness of some technical people or a big factory mentality or something? How can this situation be solved?

This complaint less mention, and people convenient for their own convenience, since it is to mention the needs of the people, will be more for each other to consider.

　　Third, the product personnel how to solve?

Assuming that there is a problem, how should we face it? First of all, to find out why, is not done in place, or the other party did not understand your ideas, or simply look at you not pleasing to the eye? Suppose to be 1 and 2, then we have to do:

1, first understand the product strategy.

Find out for yourself whether these 1 pixel details are of sufficient importance to the product. If it's not important, move the work center to something important.

2, absolutely do the things you should do first.

Here, including their own first to understand the meaning of the changes, draw a color value, pixel map and documents, do a good product prototype and so on any other can let the other party does not need to tangle, directly can get started work. Their professional, efforts are to win the respect of the programmer premise, to win their respect you can successfully carry out the work.

I used to plan the trial document, a 3-page doc I called back 7 times, changed a few days, and finally to the programmer to start execution. Although there are still some problems, but at least the program has seen the planning efforts. Would you like to think about it, if you do not audit the issue of the program, the program will not take a knife to chop people?

3, figure out the progress and priorities, and figure out what the other person is doing

In the process of understanding the product progress, priority, in particular, should pay attention to a point: "Absolutely do not think of a need to run past the request to change!"

A program is also a person who is likely to be puzzling over an important issue when you run over to interrupt his thinking, or to use what he sees as worthless, and, worse, you directly ask him to put down his job and change it immediately, a programmer will explode. Don't be a programmer, you can't stand it.

A good way to do this is to keep track of all the requirements, to mark priorities, to communicate with programmers on a regular basis, and to work out solutions and time with him. Remember not to make the decision for him! He is not your subordinate! He is a partner to help you!

4, the importance of instilling user experience in private to bosses and programmers

This is a lot of people often overlooked place. Each person's mode of thinking is different, you can not ask others to follow your thinking mode to look at the problem. To make people agree with you, it is necessary to exert a subtle influence on others in normal times. For example, nothing more with the company other people chat products, chat experience, talk about feelings, and slowly give them the importance of instilling experience. As long as your topic is interesting and people are interesting, no one will refuse to talk to you for a long time and the whole team will have a change of mindset.

Say a little trick. Most programmers are more pride, if you want to let him change what, you can intentionally or unintentionally to say to him, you think a similar product with you a very good experience to do, you do not know how to achieve, must be a look of envy, said they are too cool. You programmers will look at you with contempt, saying that this piece of junk what is difficult? I am a half a day, definitely better than his strong hundredfold. So much hype, your goal is achieved, you both have a good, isn't that nice?

5, good colleague relations

Programmers work overtime, occasionally in their overtime to buy a bottle of Coke, pretending that a face calmly put on his desk, he even said not to say, the heart will be grateful to you. This is not a crooked, but a human. Where do you go to find a bottle of cola can buy a friend to go?

If it's not working, please curse him with this picture.

If you do the above 5 points, the other side has no reason to refuse, the problem is not on your side, and you can not be a person to solve. Please ask your common supervisor (such as Project manager), three people to communicate face-to-face, why there is a similar situation, if there is no solution I will pull you live in the conference room determination. In most cases, you can hear the programmer tell you why he's not cooperating.

Do not look for each other's superiors in private. At any time in the workplace, I will do what I say to you, dare to say to others, do not do behind the discussion, complain, stab the knife.

If you are already in place, still unable to solve, it is not the programmer's problem, is your supervisor's question, please consider changing jobs.

　　Iv. What should the program supervisor do?

This one is I saw the ranking of the first CTO students, feeling and hair. As a manager, I firmly believe that none of the jobs are "optional". The vast majority of products, can not rely on a certain category of people to achieve the ultimate 100%, and then a good product has improved space. But this improvement space, cannot rely on the designer to solve by oneself, need to draw on the external force. So I don't think the product personnel will be able to marginalize them without giving them power.

I am a planning person, if I am the CTO of this company, I think I will make the program and product personnel to cooperate better from the following angles.

1, continuously instill the product for the team first.

Every one of us is striving for the success of this product. In this area, everyone's work is responsible for the success of the product, not who is doing what, who professional is not professional. As long as the product quality can be improved, any proposed plan, modification can be discussed, even if the progress is not allowed, can be recorded.

It's my job to let everyone in the team stop focusing on their roles (planning, procedures, art), jobs, and focus on the product itself.

2, do a good job training. Provide tools.

Do a good job training: for the program personnel training products awareness. Process and experience of training and development for product personnel. Do not seek to replace each other, as long as the two people can understand each other, can be considered from the other side of the problem is enough.

Provide tools: for product personnel to provide better development, design tools, to enable the requirements from designers to developers, as little as possible due to communication ambiguity.

3, the development of norms and procedures

Including requirements production specifications, document specifications, development processes, requirements change specifications, etc., to reduce the project caused by human factors in the uncontrollable.

4, do a good job in team building and interpersonal relationships, solve problems as soon as possible.

Break the circle of work, go out to eat a meal, play a ball, enjoyable how good.

To sum up, the programmer does not cooperate, do not look for so many reasons, most of the situation is the demand for personnel did not do in place, please continue to cultivate their professional ability and interpersonal relationships.