Programmers and designers do not always communicate well with each other, which leads to many problems in software development. Understanding each other’s work is not always smooth and sometimes even very difficult. As a designer, I have naturally acquired two perspectives, enabling me to examine this issue from different perspectives.
Who are designers
“You’re the artist, your whole family are artists!”
Every designer hates being called an artist, and it’s like an insult that kills the ideas, taste, vision, feelings, and hard work that they put into their product. As the Internet company’s closest thing to art, it would certainly be a leap to violate their proudest identity.
What do engineers think about design
“Just draw a few pictures, or design a website/app?”
In the eyes of engineers, a website/application can work, involving interaction, content, vision, front and back end docking and other links, each of which affects each other, and a few static design drawings are far from enough to show the complete form of a product, or even, it will be full of loopholes.
So should designers learn to program?
I just took two extreme examples. In reality, most of the designers I have worked with are very nice. After all, our goal is to create great products together. Although the industry has never required designers to know code, in the process of transition from design to development, I really feel the code ability brings great promotion and improvement to design ideas.
I have seen a very appropriate analogy, a designer is like an artist who cannot draw. Every morning, he tells his ideas to his assistant, who then tries to reproduce them on the drawing board. At the end of the day, the artist looks at the final product, either satisfied or dissatisfied, and gives new instructions.
Indeed, this is the workflow of most designers: deliver the design, wait for the finished product, make a long list of changes, and then wait for the next version to be tested. The process is annoying, and many details remain unsatisfying after many revisions. And that’s not bad enough, when so many flaws are left unchecked, it can be maddening for designers who are obsessed with detail.
Prototyping changed that, and INSTEAD of just printing out designs, I made real working prototypes to validate all kinds of imagination. Does it feel natural or confusing? What animation transitions can make the interface smoother and more textured? What kind of speed curve makes touch interaction more “trackier”? All the effects I wanted were designed and polished directly in the browser, producing an interactive product without having to explain what “should” look like over and over again across the screen.
So should engineers learn design?
“Don’t write it dead here, it will be changed later.”
Then I moved on to the front end of my career, and the workflow went back to what it used to be: waiting for a design, delivering the finished product, receiving a long list of feedback and starting another iteration. Fortunately, I didn’t have to go through the tedious process of rewriting, because I knew exactly how to make the other person happy, let alone crazy.
Alan Kay once said: A change in perspective is worth 80 IQ points. By learning to put yourself in the other person’s shoes, you can anticipate the need in advance, greatly reducing communication costs and improving efficiency and quality.
In addition, with the emergence of tools such as Sketch, the threshold of design is constantly lowered. At the elementary level, the time cost for engineers to learn design is much less than that for designers to learn programming, which is really a thing that can quickly gain a sense of achievement.
One last little secret
If you are a developer or designer, it is best not to let the designer/developer who works with you know that you are “out of bounds”. Don’t ask me how I know.