• 5-rules-for-designer-engineer collaboration: Tips to Improve Quality and Productivity
• By Andrew Yang
• The Nuggets translation Project
• Permanent link to this article: github.com/xitu/gold-m…
• Translator: Starrier
• Proofread by PokerF, NoName4Me

5 Guidelines for Designers and engineers working together

Tips for improving quality and productivity

Designers vs engineers, from society6.

Designers and engineers are seen as polar opposites. Designers are portrayed as sensitive creators and engineers as ruthless logistics personnel. However, as a former software engineer trained as a product designer, I believe these opposites can work together effectively in the workplace. Understanding each other’s roles can greatly improve the relationship between designers and engineers. Here are five general guidelines designers should follow when working with engineers, followed by five more from an engineer’s point of view.

5 rules for designers

Image by Upslash, William Iven.

1) Avoid custom styles

Virtually all front-end engineering teams use some type of library or CSS framework to implement styles for use across applications. These libraries often contain common styles, such as predefined margins, colors, and other classes, tools engineers use to make development faster and more consistent. This means that if you decide to add custom margins, font sizes, or components, engineers have to write custom CSS from scratch to override the basic styles. That’s fine once in a while, but it quickly gets monotonous. Save these custom styles only for special occasions or when absolutely necessary. After all, designing within a framework can simplify many of our decisions, which is often a good thing.

2) Communicate with engineers as early as possible

Let’s be realistic, unless you’re working for a startup or you’re a vp of engineering, engineers don’t get much say in the product. Setting the product vision is often up to executives, product managers, and product designers to some extent. However, even if engineers don’t have much input into the design, they still feel as if they are designing it themselves. When you have a meeting with the product manager, ask an engineering lead to attend. Also, set up some design reviews with your engineering team to review your designs. Explain why you made your design decision and ask for feedback. If engineers feel they are contributing to the design process, they will naturally take more care in implementing the design.

3) Listen to engineering feedback

Believe it or not, engineers are usually pretty good designers. Especially in UX, I’ve worked with a lot of very design-conscious engineers. These engineers want to be heard, and their feedback is very valuable and often accurate. When an engineer you trust gives you feedback on your design, listen. Better yet, take out a notebook and jot down their thoughts to let them know you’re listening. You don’t have to use all your ideas, but give them the respect they deserve, and there are some suggestions you should stick to.

Of course, not all design feedback from engineers is good. Treat it with skepticism and an open mind, and you’ll always get something out of it, and who doesn’t love to be heard.

4) Understand basic HTML/CSS/JS

When I was a software engineer at Salesforce EIq, one of the best designers I worked with could go straight into the Web inspector with me and quickly prototype using HTML/CSS directly from the console. As an engineer, it’s incredibly reassuring to know that the designers you’re working with understand the technology you’re using and are designing with those limitations in mind. It’s not necessary to have complete front-end development skills to be a good product designer, but some basic front-end knowledge goes a long way. Earn the respect of your closest peers — learn some code.

5) Batch small correction

Flow is the most productive state for engineers — it largely means “in the zone.” Engineers need a lot of uninterrupted time to implement processes. That’s why meetings are best scheduled at the beginning or end of the day, and constant interruptions are the bane of an engineer’s existence. Yes, that means any thoughts you might have about using a darker blue for your buttons in the shower this morning can be put on hold. Design is an iterative process, and products will undoubtedly change. However, let the small changes add up before asking engineers. For example, baseline five small changes before approaching engineers to fix them. Nothing annoys engineers more than breaking their process (changing the color of the button just seven times).

5 rules for engineers

Photo by William Iven via Upslash.

1) Understand use cases

As an engineer, you have a lot of power to create at your fingertips, and it’s really easy to do in code. With great power, however, comes great responsibility. Step back and understand the “why” of the product or feature you’re building. Talk to your product manager and product designer. Understand why this feature was built and why it was designed the way it was. Without this insight, you’re working on the edge of the product. In addition, by understanding the product, you will be able to consider all the different use cases and edge cases in your implementation and take your code to the next level.

2) Implement UX first

In an agile environment, design is iterative based on user testing and feedback. A border-radius and box-shadow blue button with 5 pixels that you deliberately implemented yesterday is now a green button with a graphic design and sharp edges. Screwed up. But don’t get discouraged: accept that this is part of the product development process. Implement the uX-design process, functionality, and overall layout first. Get the overall look, but don’t get crazy about pixel perfection. Once the design has undergone more iterative testing and the version is stable, lifelike elements will gradually be incorporated into the design.

3) back

Remember the last time the designer asked you to implement a custom component that changed colors and flipped every minute? Yeah, don’t do that. Design is a two-way street. Don’t be afraid to back off and give feedback on technical constraints and limitations. In most cases, even the best designers won’t have your technical skills or understanding of the system. However, rather than just saying “it can’t be done,” offer an alternative solution. Try, “This solution is expensive to implement, and I would suggest that you use… ?” . Remember, most things can be done with the tools we have now, but that doesn’t mean everything should be done. Your job as an engineer is to help designers find the best, most cost-effective solution.

4) Keep in touch with designers

Communication is really the theme of this article. As you implement your design, always show the designer your progress. Designers love to see their work come to life, so it’s really fun for everyone. Keeping the designer up to date on your progress will help ensure that your implementation is as expected and that there are no surprises. This is also a good opportunity to ask the designer any questions about the design or future tasks.

5) Fill in the blanks

There will always be areas where you need to use your best judgment to fill in the gaps when implementing your design. The design you implement won’t be exactly like the design handed to you — that’s the bottom line. You’ve certainly encountered situations where you felt you needed a bigger margin on some screens, or where a particular color didn’t look right in a real application. Don’t go to a designer with a problem every time. Put on your designer hat and tell yourself that you have the skills to solve them. You have it in you.

But don’t go too crazy. Always check with your designer when making big decisions. Use your best judgment 🙂

Now you understand! These are my five guidelines for designers and engineers to improve collaboration at work. These guidelines are entirely subjective, drawn from my experience as a software engineer, and now from my experience as a product designer. Please tell me if you agree with me so that we can continue our discussion below!

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.