Kaifa said it couldn't be realized until I changed into Heisi-v2tn

Hello, everyone. I'm grey two~

I'm not a gray license. The point of this article has nothing to do with the gray license. Don't disturb the gray license if you have any problems or different opinions. He's busy writing code (laughter)

▲ classic lines of "Lu Xun" in the TV series "Lou Wailou"

Today, I saw an article on the homepage of UI China, discussing that development cannot be achieved. What should designers do?

The main idea of this article is to strengthen communication. In the early stage of docking development, we should confirm product documents, review, prepare cut outs, annotations, component specifications

In the middle of docking, do not modify frequently and synchronize information in time

In the later stage, we should track the progress, check the design and track the data

This article is well written, but in fact it is only suitable for some large factories with relatively standardized processes, which is too idealistic for most small and medium-sized companies. The probability of implementation is very low~

▲ according to the interesting comments I saw below this article, this brother's idea is absolutely amazing. I didn't think about it as thoughtfully as he did in those years. I just wanted to untie the top two buttons of my shirt~

In my opinion, such an article is more suitable for telling your leaders and programmers' colleagues when reporting and reporting, and is suitable for improving your KPIs and making ppt reports. I have different ideas and opinions on this issue. These ideas are more discussed for our designers.

In fact, according to my years of work experience, once the developer says that your design cannot be realized, there are probably the following situations:

1. The implementation of your design is too cumbersome. There are no ready-made components and code fragments. It is very expensive to write from 0 to 1 by programmers themselves. It is easy to be thoughtless and easy to produce all kinds of unexpected bugs.

In this case, if it is not the mandatory requirement of Party A or leaders, I will generally modify the design draft to make my design rely on the existing components or controls as much as possible. Let the front-end brother's hair drop a little less, so that everyone can relax and get off work early~

2. The designer knows nothing about the boundaries of technology. The design draft and ideas are unrestrained. The programmer wants to hit someone after reading it.

In fact, designers still need to know a little bit of development knowledge or common sense more or less. Being too wild and unconstrained will really make programmers headache.

3. The programmer's lack of beauty, his lack of understanding of design and his straight man's fixed thinking are difficult to change.

Many programmers are straight men. It is as difficult for them to distinguish between 10px to the left and 20px to the left as it is for them to distinguish between red numbers. In this case, you can only move a small bench and sit next to the programmer's little brother, patiently guide him several times, and slowly cultivate his aesthetics and preciseness in design annotation.

4. The programmer you work with has just worked for a while.

Everyone comes from Xiaobai. You should understand and be more tolerant. Need to have more patience to grow with her. Finding technical solutions with her and helping her introduce old programmers with strong technical strength are all good solutions to problems.

5. Programmers are old-fashioned and have a bad working attitude.

In fact, many programmers, they are just not sensible in high school, casually registered for the major they don't like. For them, writing code is just a job and a family income. In their eyes, completing the function is equivalent to completing the work. They won't and don't want to spend time and effort restoring your design. For this kind of people, after several times of cooperation, we should understand that they are likely to be eliminated by the industry, and don't hope to change them. Do your job well, keep the chat records of communication, and show evidence at the critical time to avoid being thrown into the pot by such a veteran.

6. Project cycle is not allowed.

Most of the outsourcing project time is money. The earlier the acceptance, the more money you will earn (faster). Your boss will only try to shorten the project cycle, and won't give programmers too much time to make things perfect. Such a company will not give you time to study and grow at all. Prepare your works and resume, see if there are opportunities outside, and try to change a better environment as much as possible (except for the high salary)~

7. Party A and the boss don't pay much attention to design. Programmers have a big say, and the boss is more willing to listen to the ideas of technicians.

Many bosses are programmers themselves, so they are easier to stand on the other side and trust programmers more. It's hard to change your fixed thinking. Don't try to convince anyone or change the status quo. Although your design draft can't be achieved in the company, you can desensitize it and make your own aircraft draft, publish various design platforms to increase your popularity and influence, and strengthen your collection of works by the way. (don't read those bullshit articles about how to improve the discourse power of designers. It's useless, and you can only improve a piece of wool. A design service staff, where there is any discourse power, wants to have a discourse power, he will become Party A or the boss himself. It's really not possible, just write your own code like me.)

In the articles related to design restoration, we are often instilled with the view that we should work very hard to do a good job of design walkthrough. Usually, the gods also teach you to output very detailed walkthrough documents. I have different views on this walkthrough.

1. In the early stage of running in with programmers, you need to do walk through very carefully. Because they are not familiar with each other, they need to look at the restoration of each interface point-to-point.

2. If a programmer who has worked together for many times still refers to changing one place to another, or even an obvious problem on the interface, he should take pains to guide him to modify it every time, then what kind of walk through documents will not work, and such colleagues will only consume you.

3. Walking through this matter is actually the need of the company, products and projects. But it's not very helpful for your personal growth. Do you really need it? You take these time to learn AE, C4d, blender or other things. Isn't it fragrant? If the walkthrough can be dumped to testers, project managers, product managers... You must find a way to dump it. Use your time and energy where it is more beneficial to your growth.

In general, if your career plan is not a manager (such as product manager or project manager), you only intend to become a design God. I personally think you should pay less attention to it. Don't touch those "chores" that consume you, can't let you grow, and are not conducive to your job hopping and salary increase.

Sometimes, design walkthrough is more like a chore to wipe others' buttocks. If others' work is not done well, you have to bear the consequences. If your design has many details, or the interaction in some places is complex, you should take a serious look. If you can see inconsistencies or poor restoration at a glance on the interface, don't call it away and check, it's really wiping the bottom of your programmer colleagues!

Finally, if the interviewer asks you during the interview: if your design front-end cannot be realized, what are you going to do?

Here is my answer:

“ This is about to be analyzed in detail. The design draft can't be realized. Is it the designer's unrestrained and excessive design, which makes an infeasible scheme, or the programmer's level is not enough? This requires designers to figure out the problem first.

Usually, I will ask the experienced gray license in the design group. He is both a designer and a programmer, and usually can give clear answers and technology related solutions quickly.

If the designer over designed, it is really difficult to achieve, it is natural to modify the design draft. But if the programmer is not good at it, I will help him find a ready-made technical solution and try my best to restore the design 100%.

In addition, we should also consider the overall progress of the project. It does not rule out that time is tight, the task is heavy, the development cycle is very short, and there is not so much time cost to complete complex design. The probability of this situation is to compromise the design. We should also stand in a higher perspective, focusing on business and the overall situation.

But in general, no matter what the situation is, a designer should not always make a very conservative design because the programmer can't realize it, and always use those ready-made design effects and existing program schemes. The position of designer itself is a creative job. We must think boldly and do it bravely. Only through innovation can our company's products shine in front of users, open the gap with peers, and survive in this cruel business environment”

Finally, when the development says that it can't be achieved, wearing black silk doesn't work. The results of products or projects are not good. It's better to try some more effective methods mentioned in this book: