Working with engineers is such a pain…
If you’ve spent any measurable amount of time working on digital product teams, you’ve 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?
Related: 6 tasty ways for designers and developers to collaborate better
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 2 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’m making a sweeping judgment here by saying this is generally not the case. Only a small handful of people purposely aim 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 I’ve 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 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!
There 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 your teammates is equally, if not more important. Take time to understand the underlying factors behind the decisions and actions of your team member. There is a fairly strong chance that there’s 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.
“Empathy for teammates is equally, if not more important, than empathy for users.”
Products and software have become increasingly complex. Engineers are generally juggling platform limitations, legacy codebases, and technical debt. Maybe they’re approaching a problem a certain way because that’s 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’s 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’s super important to have at least general knowledge of how the project you’re working on is put together. Learn about the various systems and how they’re all connected. Ask an engineer to walk you through how they’ve 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.
“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’re 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’re 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.
“Find ways for the entire team to be familiar with as many aspects of the project as possible.”
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’s good to have engineers present who can start to think of things from a technology and implementation standpoint. There’s 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. Self admittedly, I frequently find myself zoomed in at 5000% sweating every pixel just to zoom out to see something absolutely unusable. I’m sure there are engineers who 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 skill sets, that you may or may not have.
While it’s important to sweat the details, it’s 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’d love to hear some of your tips for creating awesome cross-functional teams. What has worked great? What hasn’t worked?
This post was originally published on the Cantina blog.
More on designer-developer communication
by Paul Demers
Paul Demers is a Senior Experience Designer at Cantina, a design and development agency in Boston. He helps enterprise clients ignite their ideas and transform them into engaging digital products. He is passionate about teaching and volunteering with local design organizations around the city. When he steps away from the digital space, you can find him cycling around New England or noodling around on the drums.
