A Designer’s Guide to Collaborating Effectively with Engineers
I don’t know about you, but I love working with engineers. I’ve had the opportunity to work with some bright engineers who really value designers and design-thinking. I’ve also worked with engineers who don’t understand designers. Over time, I’ve realized that developing the proper workflow is essential if you want to collaborate effectively with engineers. (Or anyone for that matter, but we’re going to talk about my engineer friends today!)
In my experience, designers and engineers often have similar goals; most of them want to build cool products. The interesting thing here is that both designers and engineers have their own way of getting to the end result of said “cool product.” They have different skillsets and their own way of reasoning. That difference can sometimes makes it challenging to stay on the same page when developing and designing products.
Bottom line? We’re all special snowflakes, so how do we go about collaborating effectively with engineers?
Cultivate a Shared Language
This first rule of thumb typically goes for an cross-functional collaboration. When working within teams of vastly differents skillsets and thought processes, it’s important to take time to make sure everyone is on the same page. That involves developing a shared language between the team members. In order to create and cultivate a shared language, team members must take time to understand what everyone else does; they need to get to know the other people’s tools, their specialties, and even their expectation.
Sometimes, creating a shared language means literally learning some new vocabulary! If you don’t know what the API is or does, how would you be able to figure out what designs you need to send to the back-end guy, and not the front-end engineer?
One of the best things that has helped me (UX designer) create a shared language with my engineering peers was to spend more time around them. I even physically moved closer to them so I could be part of their conversations and not just chime in on a Slack message. This face time helped the entire team begin to understand each other in a way we had not before.
Another great way to help your team create a shared language is to simply go out to lunch together a few times. Team lunches tend to be more lighthearted than office meetings and therefore, people loosen up a bit. This is a great time for smaller side conversations to happen where the team organically begins to learn about one another’s skills and develop their own shared language.
Pro-Tip: If you are a designer working remotely, opt for a video chat when meeting with an engineer and request for regular check-ins or sync up meetings. Oh, and don’t always jump straight to business (yeah, I’m talking to you Type A personalities out there…). Spend time getting to know the other person and ask questions about their work.
Agree Upon a Process, then Iterate
Creating and sticking to a product development process is not always easy (or fun), but it needs to happen if your team values collaborating effectively with engineers. The team needs to know what to expect and how to proceed. This means that if a product manager produced a prioritized list of items, it could go through this process and the process can produce results.
There is no one product development process for any team. My suggestion is to get with product managers and engineers and talk about what is working and not working with your current process. See where and how you could do better and create a game plan to do so.
Once you have the game plan in place, test it out for a few weeks to see how it goes. From there, the team iterates! A process is not one-size-fits-all and it will never perfectly fit your team, that’s one thing to understand and be okay with. However, you can strive to be aware and note problems as they arise. When you find need improvement – maybe certain checkpoint meetings unnecessary or maybe engineers didn’t know they had to scope out a certain product feature for the backend. When that happens, pause, talk with the team and find a way to fix the process. That’s the way to get to the right process for your team!
Creating a process means that everyone knows their part in the story. Each engineer, designer and product manager knows what is happening in which phase and they feel that they have been able to properly provide input. This not only makes product development pleasant, but it also ensures that the finished product is as close as possible to the best solution.
Get Feedback Early and Often
This is something that comes natural to many designers. After all, many of us were trained through design critiques and endless ideation. However, one thing we should always remember is to get feedback from engineers too. Collaborating effectively with engineers means using their knowledge and skills wisely. They bring valuable knowledge to the table and without them, our sketches and pixels… well they would be no more than just sketches and pixels!
Engineers bring a designer’s pixels to life!
For that reason, they know of complications or dependencies that the designer might overlook or not even be aware of. Engineers are also very good at thinking up edge cases and are valuable when you need someone to poke holes in your design.
Oh, and I forgot to mention the best part of it all! When you ask an engineer for feedback early in the process, they feel like they were part of the creation and are bought into the final design outcome. Yes, my designer friends, that means the engineers and you are fighting on the same side!
So, go ahead, grab your engineering buddies and show them your scribbled sketches or colorless wireframes. Trust me, they’ll love you for it.
Hold Regular Retrospectives
So in any relationship, whether it be romantic or platonic, it’s healthy to have hard conversations. These hard conversations are what help us grow and develop stronger (and deeper) connections with others. This philosophy applies to team members in your development team when you’re trying to collaborate effectively with engineers. After a certain agreed upon timeframe, it’s valuable for the team to sit down and talk about what went well in the development process and what didn’t. In the agile development process, these conversations are called Retrospectives.
Retrospectives open up “real talk” and let team members speak openly about struggles and challenges. It helps if the entire team is on board with the idea of having open, “real talk” like this and is willing to make positive changes, if needed.
If you’re a designer and there is an engineering manager that runs Retrospectives for the engineers, ask if you can be part of those meetings and contribute. Another option is to set up a meeting yourself and pull your team together for a chat. I have had to do this in the past when I realized there were several things we needed to talk about it the previous development cycle. I knew that there were feelings that needed to be understood and addressed. What I did was simply message the people involved in the specific project and mention to them that I’d like to discuss the project and how it went. They were each open to the chat, so I sent a calendar invite for a meeting where we could all sit down and have a healthy conversation.
What’s interesting is that Retrospectives uncover blind spots for everyone. For example, in a recent Retrospective I was part of, several of the engineers noted that the Zeplin plugin for Sketch that we use to share designs with them felt overwhelming; they never knew which screens to look at to begin development. Additionally, one engineer mentioned that designs would keep changing after a project was supposed to be design complete. As one of the designers on the team, I had no idea this was an issue. Immediately, I felt bad that they were finding this piece of the process so difficult.
What did I do? I told the team I’d find a new way to solve this problem with my counterpart. My counterpart (another designer) and I sat in a room and noted all the issues with our process and found a way to use Zeplin that cleared up those issues. We decided to not update designs in Zeplin once they were locked down with an engineer. Additionally, we decided to tag screens and send engineer the tags we created so they could simply click and see the group of screens they needed at the moment. Problem solved!
So, in this case, the Retrospective uncovered a problem we didn’t know about (a blind spot) that we were happy to fix moving forward. In general, it makes the team work much better together and feel good about it at the same time. It’s a great way to become aware, learn, and adjust when collaborating effectively with engineers.
Build Empathy With Each Other
When collaborating effectively with engineers, the last piece to the puzzle is to build empathy with each other – which won’t come a surprise to you. When possible, try to put yourself in your peer engineer’s shoes. Try to understand what they have been through and how much time they’ve put in to solve a certain problem. Are they under any pressure? Have they had a hard time working on this type of feature before? Are they excited to get started and dig into the code? Taking a moment to understand the engineers on your team will help you understand why they do what they do.
If conflict arises, the empathy you’ve built with the engineer will only help you. It’ll help you remain level-headed because you get where the other person’s coming from. This will help you react in the best way possible while helping the team move forward to complete the task at hand.
These guidelines are something you can begin implementing today! Keep them in your arsenal and make them a habit. As a designer, when you master the basics of collaborating effectively with engineers, the quality of products you output escalates. Not only that, but your engineer teammates will be clamoring to work with you and every project that comes their way!