How can prejudice between designers and engineers be eliminated?

As a designer who has worked for more than 10 years as a company with engineering as its core, I have spent most of my time working with engineers. So these collaborations are undoubtedly my most practical and productive working relationship.

As a designer, I believe you can also create a rapport with an engineer. And you just need to reduce the personal bias between designers and engineers and create space for effective partnerships. And if you do, the benefits of reaching that step will be far greater than the difficulties of prejudice.

When I was in the industry, I used to be a consultant at a top engineering company in the world. I've seen a lot of design techniques, and also worked with many types of designers, whether it's technology, concept, vision or other designers.

Designers have several types of behavior that can make engineers and designers in a bad relationship. But I was in a project-centric company engaged in design, through their own methods in the work process, with engineers to build a long-term, trust, and efficient cooperation between other designers to achieve greater success. For a good designer, if you have a good project partners will be more effort, but to achieve this, you must do some adjustment.

Here are a few of my suggestions for building an effective relationship between designers and engineers to help build a strong team and make better products by reducing stereotypes on both sides.

1. Using the tools used by programmers

When a designer joins a team or a new project, first ask yourself "How do you like to work?" Many designers make the mistake of contacting only the tools and programs they are familiar with, or getting successful experiences from their previous teams. But now software updates are so fast and each team is different.

By asking the technical team how they like to work and the tools they are using, they can skip the painful running-in process. Some teams like to create a collaborative document to track vulnerabilities or use some of the usual bug-tracking software. Others prefer to communicate by email or use simple project management tools such as pivotal Tracker.

The key to a designer's success lies not in how beautiful their work is, but in the success of the communication process that makes the work more in line with the ideal design. A truly successful designer can accept any product that communicates the design effectively-even if it takes a little time to learn the tool, it is worthwhile to reduce friction with the engineer.

2. Participate in the whole project cycle

Designers always wait until the product is released soon, so that designers can be easily with engineers. An engineer may feel that a nearby person suddenly comes in and asks for a change in detail (if you only appear before the product is released, you are certainly a bystander).

Engineers need designers to participate in the entire lifecycle of the product, not just the front-end. Designers should be acutely aware (if he does not participate in the whole process) building data structures, storage, retrieval and UI structures is a difficult project. Designers should work with each member of the engineering team to advance the project, even if it is only a semi-finished product.

I've seen many designers criticize engineers for their early samples. If an engineer is criticized by a designer in the face of something they have not yet considered carefully, his feedback will not be positive in the future. Finally, when the product is released, the designer always wants the engineer to make a big change, but the engineer will not accept it.

3, fully explain the need to improve the place

Many designers think that when they give engineers a complete, "pixel-level perfect" model is done. Designers are restless on the eve of a tea release. But do not say to the engineer: "This is not in conformity with my model, here is the new model", but to fully explain where the need for improvement.

Designers are trained to notice details that ordinary people will not notice. Engineers don't deliberately ignore these details--just as designers don't care about the basics and open source code, and engineers don't give priority to these details. The designer's job is to find these questions and point them out as much as possible, because the engineers you work with are not trained to be as careful in detail as you are.

Put your model and demo together when you're on site feedback. The screenshots appearing in the demo should be detailed, exactly where the need for improvement, to show these to the engineers and to explain. I often mark the "before/after" screenshots in feedback and summarize the improvements that need to be made in the form of a list. In this way, both visual and literal engineers can quickly and carefully improve.

I've done more than that. I also classify the improvement of the interactive design separately, because your team of engineers may be good at this or that--if you want to classify it, it will be easier to share. In general, engineers respond well to improved classifications, so they can be improved systematically, and can be reconciled once they are completed. It was something outside of my duty, but it made me run a few legs.

4, the real chat is very good, but the chat record can not be traced

Many of the designers I know like to have a private chat with a product manager or an engineer about design details. This is great, and it can enhance the cohesion of the team, but the downside is that there is no "written record." Unless you have a team of two people with you and engineers, everything must be documented for the entire team to understand and respond to.

So even if you and your engineer have a spark in the design improvement on your private chat, you have to go back to the table and summarize the content in the form of email or feedback immediately. This gives the team a chance to get feedback and can

As a record of the decision. Every decision that is not documented should be brought to the attention at a time when everything in the end becomes complex.

5. Drink a beer with your engineer

Never underestimate the importance of socializing with your team. Get to know them and let them know you. If they feel that you are not a skilled worker in accomplishing the design, but as a "person", their trust in you will increase.

———————————————————————————————————————————–

Fellow engineers! You didn't think the way out of this mess was easy, did you? It's all about the things that a designer should do to make your life easier. Accordingly, here are the things you should do:

1, never Let "no" blurted out

When a designer is excited to talk to an engineer about an idea, and the latter has not been asked to elaborate, let him not say--nothing can make designers more frustrated!

I find that many engineers (especially those I haven't worked with for years) often veto design ideas and innovations. Because they think those improvements seem "less important, but require a lot of work." Trust me, designers know you work hard and don't even have a rest for some minor changes.

But that's why teams need designers and engineers. Our mission is to create intuitive, innovative products that people are willing to use and willing to repeat. Otherwise, the hard work of the engineer is meaningless.

Designers are excited about some interesting or creative ideas, but don't just say "no" and try to live a little while to understand why your designer is so obsessed with the idea. You can talk to a designer or another engineer to see if you can find a way to reduce the cost of the project and achieve the same result. Once your designer thinks you are a curious and open-minded partner, you are more likely to get the design icon you need at four O ' night before the product is released.

2. Excellence is not an extra job

It's important to focus on different things in different fields. A great designer puts details and a good user experience in the top place. These details are important and may not clear their importance, but the details really affect the user's knee-jerk reaction to a product or feature. Many of the details of the error may even result in the product is not professional or unreliable impression. On the contrary, an improved app can get a stronger emotional response than an app that has no programming errors but a poorly UI interface.

A designer lets an engineer move an icon to the left three pixels, or align the text of two regions at the same baseline, and the changes seem unimportant-but the change in one is really quite different.

3, before the release with the designer to do a comprehensive product inspection

If your designer is doing a good job in all of the above, don't give the designer a chance to review the new product features-no matter how small you think the change is. Think of your designer as part of a team: the designer and the rest of the team are all for the success of the product.

Make sure that you have given the designer the time to respond and recommend revisions before the product is listed. If you show her the product just for "reference", it's not as bad as the designer never used the product.

I hope my experience and methods over the past few years can help designers and engineers to form a good cooperative relationship. I believe that good cooperation in the end can bring better products and a better user experience.

SOURCE Link: How designers and engineers can play nice (and e.g. run with scissors)