Communication with development is not the core work of our design team, but poor communication will directly affect work efficiency and results.

Communication is not an easy thing. Because from the perspective of development, we can see that we may be like the God of misery with its own ominous shadow, every time we come to change the page to change the requirements or push the schedule. A developer with poor communication and a temper tantrum risks being beaten up.

Effective communication is more powerful than muscles. Communication, like any other skill, can be improved with study and practice.

How to communicate most effectively with developers?

Let developers understand the vision of the requirements

In many previous designs, we paid much attention to the comprehensive and specific interaction, and often ignored the communication of background and product goals. Accordingly, some developers focus only on the development task they are responsible for, like blind men touching an elephant without a clear and complete view of the project as a whole.

The background of the requirements and the product goals, which I refer to collectively as the vision. Vision may seem ethereal and dispensable, but it is very important. Enabling development to fully understand the requirements vision has the following benefits:

  1. To achieve the same goal, the development of a more intelligent solution is possible.

Developers have long been on the front lines of writing code and know more about cutting-edge technology than we do. There may be more mature, more advanced, or lower cost solutions to the same functionality. We should listen to the development advice and choose the best solution.

  1. In anticipation of future changes, developers design architectures with a greater focus on compatibility and extensibility.

Due to various reasons, such as changes in the market or requirements of leaders, changes or increases in demand occur from time to time. By understanding the vision of the requirements ahead of time and taking into account possible changes in the future, you can reduce the difficulty of making changes later, in case you do have to reinvent yourself.

  1. The common goal makes the team more cohesive.

Vision is the purpose and meaning of work. Every developer has a desire to “make the world a better place” and hopes that their results will change the world. Meaningful work is an invisible incentive to development.

Having a common goal will also increase the sense of belonging of the whole project team, so that everyone united front, become mutual support and common struggle of comrade-in-arms. In this way, you can get emotional support from your development partner.

Two, small things nail down, big things face to face.

Developers do a lot of logical and complex thinking while they’re working, and if they’re suddenly interrupted, hours of work can be lost. It also takes startup time to re-enter flow. General minor questions, such as special minor changes, additional reminders, and inquiries that are not urgent, can be asked online, and will be reviewed when the development is finished.

Important matters, such as major, urgent needs changes, must be addressed in person. Don’t communicate online for fear of conflict.

Studies have found that only a small percentage of information is transmitted by words. Nonverbal communication such as tone of voice, eye contact, facial expressions and body movements can convey richer information. Text communication can reduce the psychological pressure of product managers, but it has a bigger hidden danger for conflicts.

It is easy to imagine stiff tones and stony faces from the dry writing on the Internet. I believe many people have had such experience. It was normal work communication, but the more I talked on wechat, the more angry I became. I felt that the person on the other side of the screen was impolite and annoying. But when chatting face to face, I feel that the other person is not bad, at least can maintain the politeness and politeness.

When faced with potential conflicts, proactive face-to-face communication, coupled with a sincere, polite and problem-solving attitude, is a good start to avoid the resulting fierce conflict.

Three, review every bad communication.

Do your homework before you communicate, sort out the content and logic of the communication in advance, and prepare the points that the technology may question. Preview is a good way to improve the effect of communication, but most people tend to ignore the review after communication. In fact, it is more effective to improve communication.

What situation calls for a review? Review every conversation that triggers bad emotions on both sides. Be aware of your own and your partner’s emotions. This is just like the wrong question book when we were young. We will record every failed communication, find the reason and make continuous improvement.

If you keep track of it, you’ll find that many of the disagreements aren’t really at odds, and the two sides aren’t focused on the same level. The knowledge background, project experience and position of design and development are naturally different. In many cases, people have different perspectives on the same problem.

Differences are not to be feared. What is feared is that the two sides are unaware of the existence of misunderstandings. Every time there is a misunderstanding, it is a good opportunity for us to fill our mental blind spots. Understanding development ideas deeply and learning to look at things from a development perspective can get you infinitely closer to “technical thinking.”

Some students may say, most of the time, it is not differences of understanding, but purely technical. That person is not easy to communicate with wow! In this case, the counteroffer is still valid. What sentence sets off the emotional machine gun? And what line did the other person like? The second review can give us a lot of feedback and let us find the best way to communicate with the person.

Three skills to communicate with development

The three most common ultimate questions in communication with development:

Can this be changed?

This XX problem is to change the demand, change the demand for thousands of reasons you can say that the boss wants to change, the user wants, but all seem very low. Make development feel like “~%? … # * ‘& being painted ℃ $︿? , all you know is making excuses!”

Moderate acceptance can soothe the hurt heart of development, but to achieve long-term, sustainable and stable cooperation, we need the first skill — professionalism of product thinking.

For any change in requirements, the product should be the first to speak out, and the word here should not be evasive. What is needed is your professionalism, for example: why should the shopping cart button be changed to red or yellow? Why do the words for shopping carts say “add to cart” and not “buy now”? A more convincing way is that the red and yellow buttons have more visual impact, and the copy placed in the shopping cart is easier to put down like a supermarket shopping, without the psychological stress of instant purchase. Slowly your tall and fierce image can be set up!

PS: I recommend a book, “Professionalism” by Kenichi Ohmae. We are expected to solve problems in a professional way of thinking to achieve our goals.

This can be achieved?

A look is the beginning of rich imagination, think of a bizarre play to find development to achieve. I think there are thousands of ways to solve this problem, and the best way is certainly to have a technical background. But I think there is another method and skill to solve this kind of problem — the breadth of product knowledge.

Whether or not our design team should understand technology has always been a controversial topic, and I personally think it should. For a lot of common sense can learn more at ordinary times. But what about designs without a technical background? Can’t development just say it can’t be done? At this time, I would suggest using the breadth of my product knowledge to make up for it. As the saying goes, “I have never eaten pork but I have also seen pigs run”. Show your developers what you want with a case study.”

I remember reading a lot of articles about whether we should understand technology or not. Some people think that do not understand technology, so that will not be limited by technology, can better play their creativity; Some people find it easier to communicate with developers if they know the technology. At present, our design team is also in the transition stage, gradually understanding the development knowledge, daily communication with technical personnel has always been no big obstacle. At the same time, I also like to study some new tools and discuss some simple problems with technical colleagues. However, this does not mean that there is no problem in communicating with the r&d staff. We still need to continue learning. The developers we have met so far are of all ages, and most of them are modest and easy to communicate. Every time a developer is presented with a tough problem or a problem they don’t know how to solve, the response is often “I’ll look into it later and see if I can solve it.” So whether we know the technology or not, as long as the demand is reasonable, the average developer will try to cooperate. In the process of communicating requirements with development, do not say: “XXXX function is very simple ah, you see, XXX products have been achieved.” This doesn’t give the developer confidence, it doesn’t make the problem any less complex in his mind, and it doesn’t do anything but spark an argument.

How long does this development cycle take?

This is one of the most difficult problems to solve, especially for those of us with no technical background. Design and development are two different business divisions with different interest demands. Sometimes a development cycle estimate of a requirement is completely unacceptable, but you don’t know how to refute it. This is the ultimate way to get along with developers, and that is to be gay!

There really is no more efficient way to communicate than to be gay. Have dinner with developers, accompany developers LOL after work, and introduce some girlfriends to single app apes.

The final result is that the development delay a little online cycle feel worthy of our brotherly love!

Understanding it with emotion and moving it with reason, I hope that our design team’s younger brothers can use their own personality charm to enter the world of programming apes and harvest full gay love (.゚ * ゚).

How can developers be motivated?

One, know what this developer cares about

Is he a recent graduate with a lot of enthusiasm for a quick promotion and a raise? Or is it someone who wants to solve the most difficult technical problems and is happy if the problem is difficult enough, even if the product is not used? Or is he an idea-monger who is full of ideas and hates being told what to do by a product manager? Or is it someone who is shy and keeps a lot of thoughts to herself, but really wants to be relevant? Knowing what matters to him will help you figure out how to motivate him and who to put on what projects.

  • Developers who want to move up will love to work on projects that the boss can see, even if they are not too difficult. Helping them stand out in front of the boss will make them want you.
  • Technology curtilage? Feed their vanity by highlighting the technical problems with the project that other developers would struggle to solve.
  • A master of ideas? Look for opportunities to compliment him on how many good ideas he has, even if you came up with them in the first place, by encouraging him to share your ideas and then praising him for his great ideas. For example, if you think you should create a feature on a video platform that allows users to post a bullet screen, don’t directly say to the “idea king” : “You are responsible for creating a bullet screen”, instead, you should start from the problem, you can say “our video is too interactive, users don’t like to post comments”, and then lead him to the idea of creating a bullet screen.
  • As for shy developers, you can deliberately give them a chance to express themselves in meetings. They will be grateful and look forward to working with you again. Knowing what developers want, and finding ways to give them opportunities within existing projects, can be a great way to work together. As for how to figure out what a developer wants, why don’t you set up a coffee date with him to get a personal perspective, or even simply ask him, “How do you decide what you’re doing is valuable and what matters to you?”

Two, should you know how to communicate most effectively with developers

There’s nothing most developers hate more than meetings, because 30-minute meetings interrupt their thinking time and slow down their coding. Consider whether this meeting is really necessary for developers to attend, and whether it can be timed before or after another meeting of the developers so that they can program efficiently with as little interruption as possible. ゞ You also need to think about other ways to make decisions efficiently, such as making a list of the main points and sending a link to youdao Yun’s notes.

How do you push developers to speed things up?

Let developers estimate how long they need to spend, and then set deadlines. If their projected timeline is too long, they need to ask questions about why it’s taking so long, what can be cut, and whether it’s worth cutting features for the deadline. After the developers estimate the time they need, explain our release plan to the developers, such as the date on which the marketing team will start promoting product features, the date on which we need to start operating, etc., so that the developers can know the progress of other departments and enhance their sense of belonging. Developers who are new to the industry are bad at estimating deadlines. If their deadlines are too long, try to get them to tell me how they figured it out and discuss it with them. Which parts can use off-the-shelf apis (Application Programming Interfaces) and which parts can take less time. If you do need to move the deadline forward, give the developer the details of why you need to move it up. The goal is to make the developer feel like you’re with him, that you trust him, and that you’re thinking about working together to solve the problem of early deadlines. See if there’s any way to rearrange some of the plans to speed up the schedule. Make sure the developers feel in control, be respectful of the deadlines, ask questions, and actively work with the developers to find ways to get ahead of time, even if the deadline is required.

What about requirements that need to be changed?

Changing product requirements is a very common process, sometimes with good planning, you start testing and find out that users don’t understand a feature at all and still need to change it. Development is an iterative process, so here are some ways to avoid changing requirements late in development, and if you do change requirements, how do you communicate them effectively?

  • 1. Have functional design discussions with developers as early as possible so they can get background information ahead of time. Start by outlining the problems to be solved and how success will be judged in the product requirements document. Write a few first drafts of the product plan, discuss them with developers, answer their questions, and get them involved from the start. Through this discussion process, we know what the technical limitations are and then modify the design based on the feedback. This prevents the developer from spending a lot of time discovering the problem and then starting all over again, causing the developer to do nothing.
  • 2. If you do have to ask developers to rewrite what they’ve already written, or cut what they’ve already written, take responsibility. This could be because you were thinking less about something, or it could be that something suddenly happens, such as a company changing its strategy or a competitor suddenly “screwing up.” It’s not necessarily your responsibility, but it’s a good time to talk to developers and take responsibility and say, “I’m doing this for you.” In many cases, even if you take responsibility, developers will not blame you. Instead, they will come to comfort you. Take responsibility and say, “Sorry, you had a hard time.” It may seem like a sentence to you, but it’s a great way to soothe an engineer who has been working hard for a month, putting in extra hours every day. In many cases, giving developers a little encouragement and warmth, while seemingly insignificant, can make them work a lot harder.

Assignment: How can you gain the trust of one of your engineers who despises that you have no engineering background and does not trust your suggestions when making decisions?