6000 words of practical information! A guide to development communication for designers

Preface

"I can't do this. It's very difficult. I don't have time. What's the point of changing this? Didn't I just change it last time? Why do you want me to change it again?"

"I've never seen a designer like you. It's just a few pixels. Is it necessary to be so detailed? It's fine as long as it can be used. You still want to change it?! I think it looks good already. It's very troublesome to do this..."

Are you designers already getting impatient and ready to give it a try? The above scenarios are often encountered when you are proposing requirements and checking designs with developers. You may feel helpless or angry, but developers have countless reasons to reject you.

To be frank, this problem will generally be encountered at some stage in your career, sooner or later, but generally not absent. I believe that many designers have stepped on the following pit...

After the launch, the leader blamed you for not restoring the design properly, "How did you design it? Why is it designed like this?" A pair of design drafts, a handful of bitter tears... You are about to defend yourself, but the leader says, "I only look at the results."

I just want to ask you if you are angry or not? Are you angry or not?

Why did the development reject you?

Put away the sword, let's analyze it first. This problem will not change with the change of technology, nor does it have a fixed solution strategy like methodology, but it is often encountered in interviews, such as "what to do when the development team does not cooperate or the restoration is not high." This is enough to show that many companies will have this problem. In fact, it is still a human problem. Let's see what the "party" says.

For some reason, I have worked with many developers and consulted several front-end friends. No matter how strange the reasons for the developers' verbal rejection are, in general, the developers' aversion or unwillingness to cooperate with the design restoration can be summarized into the following reasons:

1. Tight business and heavy tasks

Maybe the project is in a rush to go online, or maybe a bunch of requirements have not been delivered. When the developer has more important things to deal with, he can't be distracted or use extra labor to do design optimization. Many times, the given working hours are limited, not to mention if it is linked to performance. I have to work overtime to fix bugs, and you still want me to cooperate with you to adjust it. Do you still have this mood?

Therefore, designers should also pay attention to the entire schedule of the project, try to grasp the project progress from a macro perspective, and understand or evaluate the development time. Consider the current situation from the other party's perspective. In addition, it is necessary to judge the priority of the inspection results. User experience factors on the development side, such as performance and number of bugs, should take precedence over interface restoration. After all, user experience is not equal to interface development and implementation. When even the bugs have not been fixed, it is obviously inappropriate to focus on a few pixels. It is completely possible to record the low-priority issues first and save them for a certain version to update and optimize together.

2. There is a career direction

The front-end direction is either more visual (building dynamic visual restoration components, etc.), or more data-oriented (such as algorithms). Both require strong data processing and logic capabilities.

Some developers are very clear about their direction. For example, those who are into algorithms think that focusing on visual restoration is a waste of time, so they will have a certain rejection mentality when facing such requirements. They often don’t pay attention to things like experience.

In fact, restoration is considered the basic ability of developing the bottom layer. Just like some UIs are interactive and some are visual, but it is unreasonable for an interactive UI to say that it is unwilling to draw icons. After all, the main job is still design.

3. Not good enough

There is a saying in the design circle: "There is no effect that cannot be achieved, only development that you don't want to do."

Not wanting to do it is more of an attitude problem, and not being able to do it is a problem of ability. But aren't all technologies learned from not knowing how to do them? Moreover, most restoration problems can be solved with the help of search engines. It's just a matter of weighing the cost of learning and the benefits. If you are really unwilling to do even the most basic problems, you can ask the design leader and development leader for feedback when necessary.

4. Inconsistent values

Some developers will not recognize the design. When you talk to them about alignment and intimacy, they will tell you that they don’t understand and want to leave. They don’t want to accept or understand the role of design, and are immersed in their own cognitive system, so naturally they will not agree with you. This is a very rare situation. It can only be said that the company recruited people carelessly. You can try to communicate many times. If it still fails, you can give feedback to the leader.

The above are the common reasons why developers are unwilling to cooperate. Some situations are really difficult to resolve due to objective conditions, and sometimes they can just turn a blind eye.

So what other solutions are there?

What should designers do?

As designers, we often cannot intervene in development issues. As designers, we should solve problems from our own perspective.

I have worked with quite a few developers before, and I have used all my life's knowledge to compete with them. Before I ran out of energy, I finally learned some tricks and would like to discuss them with you. At the end of the article, I have also attached all the tools and manuals I used, and I hope it will be helpful to you.

1. Good communication is a prerequisite

All cooperation is based on communication, and good communication will directly determine the results. Don't get angry and fight when you hear that the developer is unwilling to do the work. Friendship can be overturned at any time. We are all colleagues, and we will see each other every day in the future. This will only make you look more unprofessional. Stay calm...

First of all, you need to be objective and focus on the problem. As a designer, you need to be clear about what problem the solution is to solve and why you need to make this solution. You should analyze the root cause of the problem as deeply as possible and try to ask yourself 5 whys for a problem in a row. In this way, when you meet the needs, you can not only prove that your solution is correct, but also respond to the other party's questions with ease.

On the other hand, when communicating or reviewing designs, you can listen to other people’s suggestions extensively. Everyone’s starting point and cognition are different, which means that they will look at problems from different angles. Recording and thinking about other people’s perspectives will broaden your own thinking, which is also conducive to design handover.

Having said so much, here are some of the most common practical solutions that can be directly implemented:

• If conditions permit, move a stool and sit next to the developer to discuss the details (it is best to bring some snacks and gifts in the early stage. After receiving gifts, you have to give face and make some changes. This trick usually works). Face-to-face communication of details is the most efficient.

Some developers don't understand design at all, and can't even see the basic alignment. It's not that they don't want to do it, but they really can't see it. Don't laugh, a lot. Although this method is more time-consuming in the early stage, it can not only cultivate feelings, but also be clearer and more efficient than chat-style communication. Because face-to-face communication can feel your emotions and state, there is a saying that goes, "It's better to meet offline than to chat a thousand times online."

• Try to get along well with your developers. For example, play together when there is a ball game, eat together when there is a chance, and chat and play together when there is a party. Once you are familiar with each other, it will be a piece of cake to adjust the style.
• When explaining your own plan , you can use "Have I explained it clearly?" instead of "Do you understand what I said?" and explain from the listener's perspective.

2. Have some basic knowledge of front-end

Don’t worry, I won’t tell you how to code here. I think many friends who are designers are discouraged by code and choose design.

Designers are not required to be able to write code, but it is not difficult to understand some common content. On the one hand, it improves the efficiency of our inspection and restoration, on the other hand, it also reflects our "professionalism", increases the trust of developers, and also makes communication smoother.

Familiar with mainstream UI frameworks

There are currently three main ones on the market: Vant for mobile H5, Element and Ant for PC. The official website has the source files of the component library, which can be directly called by importing Sketch.

By the way, element is developed based on vue, while the mainstream of ant is react, but there is also a vue version (https://2x.antdv.com/docs/vue/introduce-cn)

Therefore, you must confirm with the front-end which framework to use before designing. Especially on the B-side, non-large teams do not have enough manpower and resources to do native development. Most companies' early development is based on ant or Element, and they can directly use official components to make design drafts. In the market, Element still has a higher market share.

Taking development efficiency and cost into consideration, basically all styles are adjusted based on the framework, so if you encounter styles with very large differences, it is best to confirm with the front-end in advance.

Application of walkthrough tools

Before talking about the tools, I suggest that you learn about the concept of the "box model". It is the basis for restoring the design draft of the front-end design layout. The tools to be discussed below will also be used. Due to limited space, the content about the box model will not be expanded. Those who are interested can search it by themselves.

I wonder if you have ever encountered the following scenario:

After the development is launched, you may find that the actual effect is a little different from what you expected. You may want to fine-tune the font size, spacing, or a certain color. You can either ask the developer to adjust it for you, or use software to make adjustments by trial and error. These methods are not impossible, but there is a faster way. The two tools mentioned below can help you.

Browser review positioning, rapid trial and error

Step 1: Press F12 on the keyboard or right-click "Check" to bring up the code interface as shown in the figure.

Step 2: Click the small arrow in the upper right corner , and then move to the left page to find any element you want to view, such as "UI Design_Baidu Encyclopedia". When you move the mouse over it, you can see the basic element properties.

Step 3: Click on the element "UI Design_Baidu Encyclopedia" that you just want to select, and the corresponding code will be automatically located on the right. Double-click to type whatever you want, and press enter to take effect immediately. Sometimes when testing the text limit value, you don’t need to open Sketch and type the text again.

Step 4: Locate elements and design by trial and error. Now comes the highlight. Let’s take the “UI Design_Baidu Encyclopedia” as an example and click “Computed” in the upper right corner of the code block. Now the large color block is the legendary box model. In simple terms, when implementing the front end, each element is implemented layer by layer in a box-like pattern. Yes, you can also think of it as nesting dolls.

Move the mouse to the corresponding layer, and you can see where each layer corresponds to in the interface. For example, the padding here corresponds to the height of the green bar on the left interface: 10px.

How do we understand quick trial and error? For example, if we want to adjust the spacing on "UI Design_Baidu Encyclopedia", click "Filter" below, enter padding and you can see this value.

Click the arrow to go directly to the modification path, and double-click to make the modification take effect immediately.

The same goes for changing other properties. This avoids the need to ask a developer for help, and also saves the trouble of using software to adjust the design effect through trial and error.

Of course, this is just a small example. There will be many new discoveries after applying it in various scenarios. For example, some online design websites can get the original pictures in this way. You can try it yourself.

CSS Peeper

CSS Peeper is a Chrome browser plug-in. It is mainly used to assist in checking. If you have a headache when you see the code, and F12 review can't help you, then this is definitely your best medicine.

1. Quickly check element properties and spacing. Font size, line height, color value, font weight, element spacing, click on any part you don’t understand, it turns out that acceptance can be so easy.

2. Preview all the color values ​​of the webpage. If there is anything not in accordance with the standard, it will be revealed. I will pull out the color values ​​of the entire website for you to check the color. I am a professional.

3. One-click download of website image materials. Downloading images is easy, icons, banners, and any other materials. As long as you have a picture, I can download it.

Just ask you if it smells good.

The above two methods can help us quickly accept the design. Back to the topic, this section mainly mentions understanding the basic knowledge of the front-end. In fact, it is mainly for better handover. Speaking of this, let me mention some tips for design delivery:

1. In addition to delivering static images, interactive instructions are also required. For example, basic field limits, icon hover, disabled state, adaptation solutions, etc. These are not necessarily considered by the product. During the design execution process, you can write them down on another drawing board to avoid frequent communication during development.

In addition, for micro-interactions/styles that are difficult to implement or describe, you can give the developers ready-made products for reference. Directly calling the code, learning or modifying it can increase their efficiency or increase their willingness to do it. After all, seeing is worse than talking. Dynamic effects are always easier to understand than text descriptions. Not all developers can know how to implement it by just looking at a static picture.

2. After the design is completed, there should be a formal handover when it is delivered to the developer. You can also bring in tests and briefly explain some of the restoration, interaction difficulties and points of attention of the design. After all, it has not yet been officially involved in the development. If there are any problems, they can be dealt with in time. Small problems are generally encountered during development execution, and then you can provide design support.

3. Pay attention to the layout and grouping of the design draft of the marked platform. Let's first give you a taste of the common online platform design drawings, including but not limited to Blue Lake, Muke, Codesign, etc.

Often when there are too many canvases, the designs are all piled together. Even if you set the alignment and spacing, it is still difficult to locate them. Even the built-in dispersion function of the product cannot solve this problem.

Let’s start with a little development. Who am I? Where am I? Where should I click? When there are too many pictures, it will become messy and inevitably cause a certain degree of discomfort.

So is there any solution?

At this time, you can organize the design drafts by category/module. Try not to have more than 10 design drafts for a module. If there are more, consider creating a subcategory and an additional drawing board for grouping. At the same time, the platform's built-in grouping function should also be applied, and the design drafts should be named accurately to facilitate location through search.

Finally, create large folders by version to store the design drafts. Don't put all the drafts in one canvas. The inconvenience of finding too many is secondary, and the most uncomfortable thing is that you are stuck and want to smash the screen.

Since we have been talking about experience, the developers who read the manuscripts are our core users. A good reading experience may bring higher code efficiency. Don't underestimate these details. They are all small things. It's nothing more than naming and dragging the canvas. It only takes a few minutes with patience. These are all manifestations of personal ability and professionalism.

3. Establish a walkthrough mechanism

What has been discussed above is based on a personal perspective, while establishing a walkthrough mechanism is a bit biased towards the team side. Incorporate walkthrough into the entire product design process. After the test is submitted, you can enter the walkthrough stage. During the process, you need to record and communicate with the developer to modify and restore the problem.

Firstly, it can be traced to prevent scapegoating (you know), and secondly, it can allow the restored problems to settle, making it easier for us to record and review.

For table templates like this, the fields may vary because the size and working mode of each team are different. Some tables are jointly maintained by production, design, and testing. You can refer to this template to add or delete as needed according to the actual situation. In addition to visual verification, you can also use interactive self-check tables to do some verification and fill in the gaps.

One thing to pay special attention to is to write the feedback as detailed as possible. For example, after taking a screenshot, put an arrow on the picture, and fill in the "problem description" column with text, such as the spacing is wrong or misaligned, etc. If there is a wrong color value, mark the correct color value.

Finally, even if you are in a hurry to complete a project, there must be a basic design bottom line. Some principles cannot be changed at will, such as general design guidelines and consistency. Designers need to grasp this balance point according to the actual situation and screen and precipitate the inspection content.

4. Enhance the influence of design in the team

The "design" here not only refers to the designer himself, but can also be extended to specific design outputs, design teams and all other people and matters related to design.

For example, we can share design knowledge and review and summarize design team (or individual) projects to make the results more professional. During this period, we can also introduce user voices, user research conclusions, data analysis, etc. These are all ways to build trust and increase influence, which will bring great value in the long run.

5. Cultivate user experience awareness in development

The higher the design awareness of developers, the smoother the design implementation will be. On the one hand, through the technical sharing mentioned above, we can continuously improve the design awareness of the development side.

On the other hand, relevant assessments can increase the weight of user experience factors on the development side. For example, stability, performance, system resource usage and consumption, number of bugs, bug resolution rate, etc. At the same time, some appropriate screening should be done during recruitment. Another thing is the commonly mentioned interface restoration, visual, interactive effects and optimization, etc., which can be quantified to a certain extent through the number of acceptances.

However, it is difficult to achieve this, especially for a newly established small team. The process involves collaboration among multiple parties, and it also depends on the cognition and cooperation of the development side. It is necessary to establish a design consensus based on people and existing workflows, so it is necessary to take it slow and work through it one by one.

Conclusion

The above mentioned are thoughts on issues such as lack of cooperation from developers and difficulty in restoring designs. With limited experience, I may not be able to solve all situations, and the specific implementation will vary from person to person. If you really can't accept and change the status quo, you can just change it if your strength allows. Large teams must have more standardized and mature processes.

I have also met a very considerate developer who can even discuss solutions with you. Visual restoration and other things are basic operations, and you don’t have to worry about them at all. This kind of development can only be said to be a once in a lifetime opportunity. If you come across it, you must seize it and cherish it~