9 Practical Tips on Design-Engineering Collaboration
How to become a 5-star design partner for your engineers
Yelp’s Product Design team hosts a Lunch & Learn every month, and it’s one of the Yelp events that I look forward to the most. Topics covered range from Data Science for Product Designers to Voguing, and I recently had the opportunity to talk about Design-Engineering Collaboration. This post is a written version of my talk, with the hope of reaching a broader audience outside the Yelp community.
I’m a designer with an engineering background. I studied the intersection of design, engineering, and business for both my bachelor’s and master’s, and I worked as an application engineer before I became a designer. Given my background, I often get asked this question from the design students and junior designers that I mentor:
Q: Should I try to learn how to code?
When I take a step back to understand the why behind this question, I find it’s often more about improving design-engineering collaboration and less about the actual act of creating higher-fidelity prototypes or writing production code. So, my short answer is:
A: Being able to code is definitely an advantage as a designer. However, even without any coding experience, you can still be a 5-star design partner for your engineers as long as you are aware of a few key engineering concepts and have a good understanding of when and how to improve design-engineering collaboration.
Here are my 9 practical tips on becoming a better design partner for engineering (especially front-end engineering, as designers tend to collaborate more often with front-end engineers).
Understand the general engineering process and build empathy
When it comes to cross-functional collaboration, I consider it as a service that I design and offer. Just like anything I design, I try my best to make this experience useful, usable, and delightful for everyone. Also, just like how understanding user behaviors and pain points come first in the normal design process, I believe understanding the general engineering process is the first step in learning how to become a better partner for engineering. Although the specific details may vary depending on the company and the team, the key phases of engineering are: Plan – Develop – Test – Launch.
Plan
During the planning phase, engineers work with designers, product managers, and other engineers to understand the problem space, conduct preliminary analysis, gather and set requirements, provide scoping, and start working on the high-level systems design.
Invite engineers to early research & brainstorming sessions
This will help your project team as a whole build deep empathy for the problem space and the people that you are building solutions for, feel included in defining the best solutions, and gain more ownership of the project. Also, engineers often come up with brilliant ideas, and involving them from the very early brainstorming stage can be extremely helpful. Most importantly, as your team spends time on these activities together, your team will start to build a sense of camaraderie, which I personally believe is one of the most important factors in successful teams and projects.
Be responsive, especially during engineering scoping
Timely communication is especially beneficial during scoping. Engineers usually have a time-boxed window for scoping, during which they need to analyze the details of the requirements as much as they can and try to provide the most accurate estimations on the feasibility and timeline. The faster you can respond to their questions, the more likely their scoping estimations will be accurate and your project will be delivered on time with high quality.
Develop
During the development phase, engineers implement the logic and UI/UX details. If multiple engineers are working on the project, they also need to ensure that all of their work gets integrated seamlessly.
Have an official kickoff meeting to review design details together
Although it’s possible to kick projects off asynchronously, I highly suggest having a face-to-face meeting if possible. This way, you have the opportunity to walk your team through your designs more thoroughly, answer questions to bridge any gaps in documentation, and ensure alignment even on the smallest details.
Learn the basic concepts of coding and speak their language
Knowing the general building blocks of code will help you better understand your design’s impact on the engineering side and, therefore, better estimate your design’s implementation complexity. The difference between HTML vs. CSS vs. Javascript is a great place to start.
Also, using the terminologies that are used in code can help with more precise communication with engineers. The difference between padding vs. margin is a good example.
Test
During the testing phase, engineers test their implementation with the internal team, external teams, 3rd-party quality assurance (QA) services, beta testers, etc.
Be proactive with visual QA and aim for a quick turnaround
If you’re not doing so already, proactively participate in visual QA even if there are other testers. This way, you can ensure that the UI/UX details are implemented just as expected and are of the best quality. Try to do so at your earliest time possible so that if you find any major issues, engineers will have enough time to address them before the launch.
Be as detailed as possible when reporting issues
If you do find any issue during testing, double-check whether it’s reproducible. If so, help engineers more efficiently investigate and triage the issue by providing as many details as possible to describe the environment (e.g. device, version, account) and the exact steps to reproduce it. Including screenshots or screen recordings is very helpful, and you can also feel free to share your thoughts on how to fix the problem.
Be brutal with prioritization, especially during bug fixing
I know. As designers, we want to be the best advocate for our users and ensure all our pixel-perfect designs get implemented just as designed. But sometimes, we need to become comfortable with launching products that may not be fully pixel-perfect so that we can maximize our learnings and impact from rapid launching. Whenever this gets uncomfortable, ask yourself: ‘From the larger perspective, is this a big enough blocker that will prevent us from learning the things we want to learn through launching?’ If your answer is ‘No,’ it’s probably okay to launch what has already been implemented, learn more from the launch, and make further improvements afterward.
Launch
After the launch, engineers monitor performance, resolve any high-priority issues, and often have a project retrospective meeting to reflect on what went well and what could be improved next time.
Attend the project retrospective
If your engineers are having one and you’re not on the invite already, ask to be invited. Project retrospective is an excellent venue for receiving objective feedback on your design-engineering collaboration skills and providing feedback to your engineers. If you’re doing a great job, you’ll get a pat on the back and get your confidence booster. If there are any areas you can improve, this is a safe opportunity to learn more about them and make action plans for the next project. Same for your engineers. This is a great way to help each other grow and strengthen the design-engineering partnership together.
These were some of the tactics that I have found to work well for me personally. Looking back at your own experience, what has worked well for you? If you happen to be an engineer, what are some things that you think engineers can do to help improve design-engineering collaboration?
Please comment below and share your thoughts on how we might be able to make the collaboration experience more useful, usable, and delightful together!
Special thanks to Aaron Brown, Brian Chan, Brenda Kaing, Clara MacDonell, Dandi Wang, Rose Chang, Scott Tusk, Shuang Wu, and Xuan Zheng ♥
