Whether you are a product, or do service, as long as it stained with it, then the two role relationship is more prone to contradictions, one is the product and market, one is the design and development. I believe that the following dialogues have occurred more than once in the corporate teams of all sizes and backgrounds:
Designer A: "I design the interface effect is not so, the details are gone." ”
Programmer B: "Yes, we developed it in the default structure." ”
Designer A: "Why not follow my design to achieve it?" ”
Programmer B: "In accordance with your design to achieve, if the system is not stable, we can not be responsible for AH ~ ~ ~"
。。。。。。
The game with the programmer, widely reflected in the Internet products and consumer digital products design and development process, the focus is not that we put forward this phenomenon, but lies in how to skillfully solve the problem. I share some of my own experience, does not necessarily mean that I have handled very well, in most cases, programmers still have the right to speak, and sometimes the way the thinking of the designers need to change, we look at these root causes and crux.
The first thing to be reminded is that not all programmers and development engineers are beans, and I've seen and worked with some of the best programmers (including some South Korean engineers), and can say that their ability is perfectly equal to the normal designer's conversation. These are rare cross media talent.
Secondly, not all products and services require the adoption of procedures to achieve "visual beauty" and "attractiveness", stability and efficiency is still the absolute premise of the system, I do not advocate because to meet the design needs of high cost, inefficient development.
1. Understanding the differences of thinking between the two sides
We have said that in order to have a design empathy for customers, we need to maintain this patience and sincerity for any partner who is not familiar with the design rules and methods. Communicate with the programmer, first of all to understand each other's thinking form, a program development process is rigorous, need to have accurate input and requirements definition, and according to the logical relationship to organize clear.
I found a lot of design results that I couldn't achieve, and the problem was exposed from the start, the development definition given is not complete, or just a "done on my graph"-a requirement that only the kind of man of God who develops can fully understand what you mean, and most ordinary programmers do not analyze the design results again. The reason is very simple, one this is not someone else's work, two this demand is likely to add extra time, three of your description of the perceptual ingredients too much, programmers can not translate into machine language structure.
So if you want your design results to be implemented correctly, you need to start with the rhythm of communicating your needs and the description of the product development from the perspective that the programmer can understand, and in some of the larger companies, the job is done by the Product Manager-Unfortunately, most of our product managers can't do it, So you have to rely on yourself.
2. Measuring the company's status
Yes, not all companies are focused on design, although they are ostensibly reluctant to admit it, because in the current market position and customer relationship, their leaders temporarily did not discover the huge value-added and competitiveness of the design, as designers, we need to give the leaders a little time (maybe this time is too long, So we changed jobs).
But in any case, as a technical basis for the development of the program is always more important, because of its knowable (can be demonstrated immediately after development), controllability (two programmers must be able to do more than one programmer), the ability to adjust (the basic framework of the program is good, later work easier, meaning lower maintenance costs). And what about design? You can't say exactly how much more value the hiring of 3 designers can bring than 1 designers and quantify it, and this data will take time to prove. If not the leadership of the extreme character and advanced thinking, basic your efforts is a bubble.
So, what you have to face is that if your company really doesn't value the front-end impact of your design, you can only do as much as possible to minimize your stress in later maintenance--and programmers to negotiate with the fastest way to modify the visual solution.
3. Understand the difficulty of program development
As a designer, you think that program development is not something you should be concerned about, well, that's what programmers think. So how can you ask programmers to understand your design intentions? Have no desire, others. If you want to get the best out of your work, at least you need to know a little bit about the basics of programming, and if you're a mobile interface designer, you don't even understand the difference and limitations between Symbian and Windows Mobile, and you don't know the functional definition of several platform versions of MTK, I don't believe you can work well with programmers.
Designers need to make up a lesson, this is not your time and energy as an excuse for things, now if you do not care about the difficulty of development, and finally because of the difficulties caused by a lot of problems will return to your head. This is the present tragedy for us as a designer, but it's not scary, it just takes you a little extra time.
4. Reasonable and progressive advancement
Sorry, one day your boss figured out, hope that the designer to go to the forefront of product development, at this time we do not have any showered ideas, because the program development rebound will be very serious. No matter how much your ideas and designs are, you are still vulnerable to the technical bottlenecks in the face of reality. We want to understand the limitations of a platform, the depth of a function, the rational development of the layout and planning, which requires you and programmers to communicate with each other to make compromises.
As far as the current industry situation is, a new application is being developed on the platform, 2-3 programmers give 1-1.5 months of time is more appropriate, do not ask why, the world is inconclusive, mainly to see a probability, because too fast will also have a reverse effect, you do not want to be every day with the programmer's butt behind the bug, change the interaction?
5. Value of private friendship
Work in cooperation, friend relationship is far more practical than colleagues, so since your identity and the department is very serious, private contacts will not be so serious, and even between departments can organize a little more private activities, increase feelings, Mater hard, we will bear the point.
I'm not talking about a coterie, I'm talking about ... Well, it's just a coterie, so what? A gang of better communication, willing to spend time for your programmers buddy is still very cute, at least our products at the end of the level up, the atmosphere is also harmonious. Okay, so that's the point of the relationship between co-workers in the workplace. Yes, you find that if you deal with this matter, the preceding 4 can be ignored ...
Finally, I would like to say that the programmer itself also want to make good things, if your design can really impress people, they are willing to spend energy and time, but why repeated war repeatedly defeated? In addition to the above mentioned issues, I heard that your company has never been good development projects and programmers to reward, I think we found the reason.