featured_collaboration

3 ways designers can improve working with engineers

By Megan Kluttz Posted Jun. 24, 2016 Reading time: 2 minutes

The importance of design in the tech industry has grown over the last few years, along with a greater appreciation for designers who know how to work within development constraints. We produce our best work when our designers and engineers work in a harmonious, cross-collaborative environment.

Over the last 8 years, we’ve learned a lot about working together. Here are three key takeaways that will help designers improve their relationship with engineers.

 

1) Be more pragmatic with decision-making

You need a solid understanding of what is feasible to build within the scope of your product. The best starting point is to digest your platform’s guidelines and standards (here you go: iOS, macOS, watchOS, material design, and web design).

Be able to see how each component will be built from an engineer’s perspective. Start to learn a programming language. Don’t feel overwhelmed by the idea that you need to know how to build a product from scratch, but any amount of knowledge that comes from knowing how to code will help you make more informed design decisions and will also help you better communicate with engineers.

Design for the best user experience first, then add the whimsy and fun after. Remember, basic UX principles should guide your design from the beginning. There has to be a balance between the amount of effort required to build a feature and the benefit of the result.

 

2) Make the engineer’s job as easy as possible

Provide your engineers with clean, well-organized design files that have comps and layers plainly named. Cut assets yourself and name them appropriately for the given platform. I know, this isn’t the most fun job. But it ensures that what goes into the finished product is exactly what you want. It also takes the work away from your engineers, which means they can dedicate more time to building better features.

Make sure your designs are consistent. Run audits over your work at different points in the design process. It’s better to check yourself a million times, than to block an engineer from developing down the road because there are differences in the treatment of similar elements.

Make annotated documents when necessary. You can create your own, or utilize one of many tools such as Red Pen, UX Pin, and Notebook for SketchLiving and static style guides can aid in the cohesion of development for your product. Keep in mind that some developers never look at the style guide and work straight off a comp, so make sure to communicate early in the process with your engineering team. Spend your time wisely and efficiently.

Prototypes and interaction animations show engineers how something should work in the most straightforward way possible. Some of our favorite tools that offer different levels of control are Keynote, After Effects, InvisionFlinto, and Pixate. If you rely on word-of-mouth to get your point across, you leave a lot of room for misinterpretation and increase chances of the final product misaligning with your vision.

 

3) Communicate constantly and respect the engineer’s opinions

Don’t silo yourself (or the engineer) off by only talking when it’s time to hand off designs. When you work together from the beginning, you are more powerful and will ultimately create a better product.

If you are unsure about a feature’s design, how a transition will work, or the flow of a user’s interactions, consult with your engineering team. They have a wealth of knowledge and can approach your problem from an analytical, technical perspective. Don’t be shy to admit you need advice.

These three lessons boil down to empathy, organization, and communication. The key with all of these is to make sure you are in control of the execution of the final product. You want your vision to be realized, right? So do everything you can to equip your engineers with the right materials and knowledge, so they can execute your vision perfectly and you end up with a kickass product.

 

[– This article was originally posted on the Tendigi blog, republished with permission from the author –]

Aa