I don't mean to stir up so-called conflicts between roles, but today I came across such an article. Yes, it's an article about code monkeys and design lions. It originated from a netizen asking a question on some community:

A developer refuses to reproduce the design according to the UI specs. How can I make him understand the importance of precise reproduction and thus modify the code?

When a development engineer repeatedly asks, "What's the point of moving this 1px? Why should I waste time doing this?" and refuses to change, how can we help this developer understand and recognize the importance of the change?

Why do many visual designers in China have to chase engineers to fix details that seem trivial, even negligible, but are still very important to designers, listing issues one by one, yet get no positive response from the engineers? For example, I heard from a colleague that the engineers at Frog developed their own software to check design fidelity so as not to affect the visual designers' work.

What is the underlying reason that makes design implementation so difficult? Is it because designers don't understand code? The aesthetic awareness of some technical staff? Or a big-company mentality or other reasons? How can this situation be resolved? At what era or turning point can it be solved?

Well, unsurprisingly, the top-voted answer was this.

Due to space limitations, please copy the link to your browser to view the full text. Link: http://zhi.hu/8lyF

Throughout the article, the author spares no effort in vilifying and mocking designers, even shifting the topic. The article says:

For software development, the work of a code farmer is essential. The work of a designer is optional.

Without design, the software is still usable. In fact, in today's flat-design era, many development platforms like iOS have system default templates that aren't pretty, but they're not a bare concrete shell either. But without code, there would be nothing at all.

The importance of the work determines who listens to whom. It's that simple.

Well, after reading it, the only feeling Jingdian had was: Is this a gangster gang or just extreme self-importance? If the user base determines the quality of answers, I don't doubt it at all. Apart from expressing a slight distaste for this community, Jingdian also wants to share some thoughts and experiences about the relationship between designers and developers in reality.

First, let me state my position: Jingdian is a designer who knows a bit about code and product.

It all starts with 1 pixel: to change or not to change?

As a responsible designer, is 1 pixel important to them? If you say it's not important, then Jingdian believes that person is not a qualified designer, because this is the designer's core duty.

If you say it's important, some people will say there's no perfect thing in this world. Take it easy, it's no big deal not to change it. Don't fuss over it!

When they go to ask developers to fix this problem, the developer might say that changing this requires a lot of work and time. Besides, it's just a pixel issue with no big impact, so don't change it.

The product manager says: Our ultimate goal is to ensure rapid iteration of the product and that the core features work fine. No need to adjust that 1 pixel; it's a waste of time~

Stop fussing, stop fussing, stop fussing!

At this point, a designer who can let go would probably give up such persistence. Though unwilling, they have no choice, thinking: Fine, if it won't be changed, it won't be changed. All things are imperfect.

Over time, 1-pixel problems accumulate. Eventually, when hundreds or thousands of 1-pixel issues pile up, one day the user says: "Why is this software (webpage) so ugly? How did you do the design? Are you incompetent?"

Everyone around the designer says: "This is a problem with your design. Can't you design properly? Your skill is lacking! Your attitude is problematic!"

Designer: "..."

I think this is something that happens around all of us. In the end, a messy software (webpage) goes live. As for the market reaction, you know...

I think at this moment, the designer must have ten thousand alpacas stampeding in their heart.

A bad product is born from countless compromises and 1-pixel misalignments. In today's highly homogeneous product landscape, users will naturally choose products with beautiful, easy-to-use interfaces.

No one does design, but the software is still usable?

Yes, it's usable. Without design, the software is absolutely usable, it's just a pain to use. For example, when humans were in ancient times, everyone ate raw meat, and nobody saw anything wrong with it. Later, some fussy idiot (sorry for using that word, apologies) said to everyone, "Hey, actually meat roasted over fire tastes better." I'd imagine many people told him, "What the hell are you doing? Raw meat is delicious. Eating raw meat is enough. How troublesome to eat roasted meat!" But in the end, cooked meat triumphed over raw meat, and as a result, no one ate raw meat afterward. What Jingdian wants to say is, settling is not impossible, but settling can no longer meet people's increasingly high aesthetic needs. People not only need to eat, but also eat their fill, and then eat deliciously.

The same goes for the value of design. As for someone's statement on ZhiX that code is mandatory and design is optional, besides saying "heh", Jingdian would also like to unleash a taunt: "Actually, code isn't optional either, because eating is optional, being alive is optional. Everything else can go to hell! My friend, don't you agree?"

When designers start writing code, and programmers start trying design, what are you doing?

In fact, the 1-pixel problem is not a problem at all. When the designer completes the design mockup with meticulous thinking and clear annotations, and the developer follows the mockup, the fidelity is very high, basically reaching 80% to 90%. As for the small details at this point, Jingdian suggests that designers actively communicate and coordinate with developers to solve problems. I believe most developers are very willing to help us solve problems. On the other hand, during communication, designers also need to understand from the collaboration process how developers reproduce the design mockup: how the code is written, how the layout is reasonable, where problems can be avoided, and what can be thought through and solved together with developers.

In Jingdian's APP development process, the computer has the same runtime environment as the developers (Xcode), and git is used to keep the code in sync with the developers' code. This helps us understand how software is produced. When necessary, we can also learn some small style-adjustment tricks. For designers, this means learning more things that help with implementing the design mockup. For developers, they would certainly welcome you doing this, because there is someone around who can also write some code and help them solve problems rather than just raising issues and leaving them to deal with. Thus, good buddies are born.

During this process, a very good phenomenon is occurring. Because of the progress of your relationship, as a designer, when a programmer encounters color-picking or some simple image problems, you can conveniently help him. You can even install Photoshop for him and gradually teach him some simple image processing.

In this way, mutual collaboration and harmonious communication come about. At that moment, what are you doing? Are you writing a sour manifesto on ZhiX, or endlessly complaining about the other party?

Excellent designers and developers — communication and mutual understanding

Actually, we keep emphasizing communication. What is communication? Two-way exchange is communication. One-sided explanation while the other side is indifferent is not communication. Earlier we assumed that designers and developers are both reasonable and not so incompatible in temperament. But what if you meet someone incompatible? Or what if the other party simply refuses to change that 1px? Possible reasons could be:

• 1. The design mockup is not careful enough, with frequent changes. Designers, please imagine the situation where you are working for a client and changes drive you to the point of vomiting blood.
• 2. If the design mockup is careful and fully annotated, but the fidelity is consistently low, so low that you can't stand it, then besides communication, there's also a question of capability and attitude before you. If it's the initial collaboration, we can try to communicate. If both sides have a good attitude, the other party will generally be willing to help. There's another situation that everyone pays most attention to: the other party is extremely uncooperative. At this point, we need to ask the PM or your leader to act as a mediator to coordinate and successfully resolve the conflict. Remember, in this situation, designers should not be too stubborn, otherwise it's a needle against an awl, and both sides end up hurt.
• 3. When the designer has shown consideration and understanding as described in the second point, but the other party remains extremely uncooperative, eventually causing product problems, this is no longer something the designer can solve. Trust that your superior or leader will have a deeper understanding and judgment of the overall situation. All you need to do is do your own job perfectly without any flaws. Because the quality of the final product is no longer something you can control. Let it be, and find your sense of achievement through other means.
• 4. There is no proper bug feedback and quality control mechanism, and problems are attributed to differences in individual perception rather than process standardization.
• 5. Poor communication. I know, designer, you are saying "change, change, change," but the developer might be "... (not even bothering to respond to you)."

To our dear developers

• 1. We know you are very busy, facing countless lines of code every day until your eyes are dazzled, and countless bugs to fix. But I really want to learn some code to share your burden.
• 2. We know you are not a low-class, tasteless code maniac. There must be a pursuit of perfection in your heart.
• 3. Please understand that communication is two-way. Many times, we need you to tell us designers, who know nothing about code, how to do things better.
• 4. We know that concise, elegant, highly efficient code is your lifelong pursuit, but working with a designer to fix a 1-pixel problem might be fun too?
• 5. Our ultimate goal is the same: to create a satisfying product. Please trust the designer's professionalism, even though you may be more talented than them.
• 6. Designers are happy to help you install some small tools on your computer that make interface development more convenient.
• 7. Please don't say hurtful things like, "If programmers could use Photoshop, what would artists be needed for?"

To myself — a designer striving for that 1 pixel

• 1. Being strict with yourself is definitely right. Take every design draft and every 1px seriously.
• 2. If you have been tormented by Party A's unreasonable clients, consider how you, as Party A, treat "Party B" now.
• 3. If a pixel can be adjusted once, don't adjust it twice. If you adjust it back and forth many times, it's best to apologize to the developer, and then learn how to adjust it yourself.
• 4. Learn simple code. It's not that hard, and it's even quite fun. Try asking engineers to install a development environment on your computer; trust that they'll be happy to help.
• 5. Our ultimate goal is the same: to create a satisfying product. Please trust the developer's professionalism, even though you may be more talented than them.
• 6. Believe that the distinctions between professions will become increasingly blurred in the future. You are exactly such an awesome designer who can write code, or perhaps a product manager who understands design. Let them envy you.
• 7. Try to believe that every developer is lovely and kind. If you can't believe the previous sentence, don't give up searching.

Finally, I love every designer and development engineer who works seriously and dedicatedly, knows how to improve, and has aspirations.