Working with engineers is such a pain.

If you have spent any measurable amount of time working on digital product teams, you have likely overheard or been a part of a familiar conversation. The designers are upset because the deliverable they spent hours, weeks, and months getting just right isn’t being implemented the way they want. Why is this happening? Don’t the engineers know how much time was spent getting the stakeholders to approve the direction? Why aren’t they even attempting to adhere to the documentation that was meticulously crafted?

Working with designers is such a nightmare.

A few doors down, we enter another room in the same office where the engineering team is having a similar conversation. Don’t these designers know that this would be near impossible to code? Why are they asking for this data? It’s going to be such a complex database query. Can’t they just take this data that we already have and use it as is? How on earth do they expect me to implement this? The codebase just doesn’t work like this.

Over the top and overly dramatic? Most certainly.

These two accounts may be greatly overblown, but the themes are all too common. Two or more groups on the same team all working toward the same goal, but instead of collaborating, they sit in separate rooms complaining about the lack of understanding. It’s all too easy to fall into the trap of assumption. We assume that other teams are either completely ignoring our hard work or even worse, that they just don’t care. But, I don’t think I am making a sweeping judgment here by saying this is generally not the case. Only a small handful of people are purposefully aiming to derail a project for the sake of just doing things their way. Sure, it isn’t unheard of, but my optimistic mind knows that it is not the norm.

Great, it’s broken. How will I fix it?

My background falls smack dab in the middle of design and development. I lean much more heavily on the design side these days, but have worked in many different roles across a number of cross-functional teams. Some of the most successful teams I’ve had the opportunity to be a part of have all shared a common characteristic, mutual understanding. So how do you get to this understanding especially when if it feels like an impossible hill to climb? The following tips, while aimed at designers, are broad enough to benefit any member of a digital team. Let’s all sit in the same room and maybe even pull up chairs next to one another!

These are most certainly someone else’s shoes.

Empathy is a fairly common theme when creating products digital or otherwise. Putting yourself in the shoes of the end user is paramount to successfully producing products that adapt and accommodate to the ever-changing needs of your users. Great products strive to provide experiences that allow users to quickly accomplish their tasks while recognizing and planning for when things go horribly wrong.

If empathy for the end user is so important to ensuring project success, I would argue that empathy for those on your team is equally, if not more important. Take the time to understand the underlying factors that are behind the decisions and actions of your team member. There is a fairly strong chance that there is a logical reason why someone isn’t doing things the way you want, need, or ask them to do. Your #1 job is to find out what this reason is.

Products and software have become increasingly complex. Engineers are generally juggling platform limitations, legacy codebases, and technical debt. Maybe they are approaching a problem a certain way because that is how it has always been done. Furthermore, there may be outside issues or concerns that you aren’t privy to. There could be personality differences amongst team members. Any number of issues may exist that, without context, may make it look like an engineer is just ignoring your hard work and doing things the way they want. Again, your #1 job is to find out what these reasons are.

One great building does not make a great city — Thomas Heatherwick.

It is becoming more common to have teams comprised of designers who can code, engineers who can design, and project managers who can do a bit of both. Maybe you fit into this mold, maybe you don’t. Either way, it is super important to have at least general knowledge of how the project you are working on is put together. Learn about the various systems and how they are all connected together. Ask an engineer to walk you through how they have implemented your designs. You don’t need to be an expert or be able to code it yourself, but high level knowledge of general concepts will empower you to make better design decisions.

It’s equally important for the people building the product to understand some of the principles that made the design come together the way it did. Again, the expectation is not to turn the engineering team into design experts. We are really just striving to build a mutual understanding of each team’s process. The easiest way to do this is to group designers and engineers together based on the problems they are trying to solve. Have engineers give lunch and learn presentations to the design team. Ask the design team to teach quick classes to engineers. Find ways for the entire team to be familiar with as many aspects of the project as possible.

Combine like Voltron.

One of the best ways for a team to feel ownership of a project when it ships is to get everyone involved from the start. The beginning of a project shouldn’t involve the design team going off to workshop ideas while the engineering team sets up its development environments. Obviously, these are tasks that need to be done, but, there has to be collaboration right at the beginning. Designers, this is your time to get members of the engineering team involved in design workshops. Sit together and hash out a wireframe or flow. Some of the most interesting solutions come out of jam sessions between designers and engineers.

The other important benefit in early collaboration between engineers and designers is much more tactical. At the beginning of a project, brainstorming can and will wander into unpredictable territory, which is the key to getting good ideas. However, once things start to get a little more concrete, it is good to have engineers present that can start to think of things from a technology and implementation standpoint. There is nothing better than being able to get early indication that your great idea may require major system work, but if slightly reworked, could be feasible with existing resources.

See the forest for the trees.

Designers are stereotyped as being anal retentive perfectionists. Every design detail is analyzed in great detail. The color has to be perfect, the spacing tight, and the type just right. Admittedly, I frequently find myself zoomed in at 5000% sweating every pixel just to zoom out to see something absolutely unusable. I am sure there are engineers that would say the same thing.

Sometimes, you have to step back and remember that a lot of thinking and activity has taken place well before you started working on your part of the project. Taking the time to understand why the project is where it is right now is core to its overall success. Everything we build is the melding of our user needs, business requirements, technology constraints, and research. All of these moving parts involve a number of different people with a number of different skillsets, that you may or may not have.

While it is important to sweat the details, it is equally important to not get lost in them. It’s a valuable skill to be able to quickly evaluate prioritization of project details. Is this something mission critical or just something that happens to be a bee in my bonnet? How many other folks involved will be affected by changing or updating this?

Go forth and be awesome.

Teamwork can be amazingly gratifying and tiring at the same time. It’s important to note that every engagement is different and some of these tips may or may not apply to your situation. With that said, I would love to hear some of your tips for creating awesome cross-functional teams. What has worked great. What hasn’t worked? I am hoping that by offering these tips from a designer’s point of view, I may inspire a developer to write a follow-up from their perspective. Any takers?

Great minds.

In preparing this post, the brilliant minds at InVision, in partnership with KlientBoost, published a post with much of the same sentiment. This should definitely be your next read. I can’t get enough of their fun animated “Design & Development Love” infographic.