“It can often feel like engineers and designers are playing the same game by different rules.”
So said Bria Vicenti, senior software engineer for TaxBit — perfectly articulating why collaboration between the two departments can be so challenging. Design and engineering are the pitcher and the catcher of a tech company baseball team — they see entirely different parts of the field and have completely different roles, but good communication between them is the make-or-break factor for their success.
This comparison does more than just clarify the relationship — it also provides a hint as to how to solve the collaboration problem. To keep designers and engineers on the same page, leaders need to use the same approach that works for the pitcher and catcher relationship: Develop a shared language for communication. Much like the hand signals shared between the two positions, establishing a shared set of terms between designers and engineers is the best way to close the communication gap.
It’s important for all parties to remember that everyone is on the same team — the success of one part contributes to the success of the whole.
Built In Seattle sat down with four local tech companies to learn how they implement these strategies in their own design and engineering relationship. Engineers and designers from TaxBit, Anduril, Limeade and Ookla opened up about their efforts to improve communication and connection between two critical departments and how those improvements contributed to the organization’s mission.
What is the biggest challenge you see designers and engineers run into when working together?
It can often feel like engineers and designers are playing the same game by different rules. It’s not always realistic for cross-functional coworkers to understand the inner workings of the technologies we each utilize, and so communication will inherently be muddled when technical jargon on either side of the product forms the basis of a discussion.
Communication will always be the single most powerful tool at our disposal, so we have focused on developing methods to have clearer, quicker and more impactful discussions in the early stages of the TaxBit product and engineering relationship. These include the development of a shared language, goals and priorities. At the end of the day, there will always be roadblocks when technical limitations or design constraints slow our progress towards our goals — these roadblocks are cleared the quickest, though, when the full team understands what the obstacle is in the first place.
Designers and engineers bring very different perspectives to the work they do. What can these teams do to better understand each other’s space?
Empathy is key in improving the relationships between all contributors to the product life cycle and engineering and design in particular. Product designers and software engineers generally aspire to the same goal: Build a quality product and help the business grow. Although it’s not always easy to do so under the heat of an impending deadline, I find it helpful to assume best intentions — that is, to assume that a designer is offering critique or altering a plan not to slow down a project but rather to take necessary steps towards the shared end goal.
Unfortunately, us-vs.-them traps are easy to fall into and difficult to escape from. It’s just as important to have an empathetic attitude towards your coworkers and their decision-making processes as it is to have empathy for your users — reframing communication in a way that validates others’ decisions and the rationale behind them can go a long way. A simple change I’ve made is to replace “but” with “and” in working through problem sets with empathy. It’s a small change to my daily verbiage and one that I’ve found extremely impactful on my relationships in a working environment.
It’s just as important to have an empathetic attitude towards your coworkers and their decision-making processes as it is to have empathy for your users.”
What’s a strategy you’ve found to be particularly effective for creating and maintaining alignment among teams?
The biggest jump we’ve made in cross-team efficiency has been the development of a shared set of design tokens — plain English names for colors, font sizes, spacing and other styles. This is often considered an extension of Brad Frost’s atomic design system. These tokens allow us to ascribe meaningful names to the styles that go into any given component and how they fit together and take the guesswork out of whether a given style will match the current code and appearance of the platform. They not only ensure that our platforms look and feel the same for users, but also that the user interface code is consistent, reusable and maintainable. They allow us to finesse our branding, speed up our coding and ultimately focus our efforts on the more important task: building an awesome product!
What is the biggest challenge you see designers and engineers run into when working together?
Design and engineering tools and jargon are quite disparate, even though both disciplines are built on the goal of solving problems. Introducing our workflows to each other and aligning on the end goal is the first thing our teams discuss. Often, we have proved that we can avoid tedious processes that are familiar but unnecessary to achieve the needed result. But this challenge cannot be permanently overcome — it’s a constant work in progress. Like a relationship, you have to work at it, because it’s a different problem each time with different solutions.
At Anduril, we have the benefit of design and engineering teams sitting together — next to a full fabrication shop. This makes collaborating and testing with engineers much easier. For example, I can fabricate a mock up and walk over to the shop and test it on a prototype being built, or I can go over to our warehouse to look at an assembly and make design changes to the CMF.
Designers and engineers bring very different perspectives to the work they do. What can these teams do to better understand each other’s space?
There is often an artificial notion that engineering is only technical and design is just art. The more realistic day-to-day scenario is that both teams are in fact quite eager for input from each other.
Something that I’ve found successful is encouraging both teams to learn each other’s language — asking the engineer to hand-sketch their idea or asking a designer to 3D-model theirs. This has opened up a much more organic understanding of the problem to solve — there is so much creativity in good engineering, and complicated structure in good design.
Something that I’ve found successful is encouraging both teams to learn each other’s language.”
What’s a strategy you’ve found to be particularly effective for creating and maintaining alignment among teams?
We bake in both engineering and design processes into the product cycle from the beginning. Often, the lack of alignment comes from the lack of expectation and visibility — I’ve seen a lot of progress by defining the stages of the product, expectations from roles and clear deliverables. Along with keeping a pulse on what is expected to change and when, showing progress along small milestones and not at the end is critical. This also means initiating feedback to make sure teams are aligned.
For us at Anduril, design, marketing, engineering and business development — all key stakeholders of a project — are in constant communication. The goal is not to add noise, it’s to optimize.
What is the biggest challenge you see designers and engineers run into when working together?
The biggest issue is that designs sometimes do not match the framework’s capabilities or components used from the engineering perspective. Our teams overcome it by having design work with the team throughout the lifecycle. By including design in the entirety of the feature process, it’s easier to be agile and adjust the design or do some additional due diligence in the engineering space to meet the user’s expectations.
Designers and engineers bring very different perspectives to the work they do. What can these teams do to better understand each other’s space?
Getting engineers and designers together in the earlier stages of the feature lifecycle helps engineers see what the process looks like — that there is a lot of thoughtful care and research that goes into those designs. Similarly, designers should involve themselves throughout the engineering process. This way, they have exposure to the complexity that some designs might introduce.
I have seen component libraries and design systems do wonders for aligning teams.”
What’s a strategy you’ve found to be particularly effective for creating and maintaining alignment among teams?
I have seen component libraries and design systems do wonders for aligning teams. Additionally, taking away the complexity and providing clean-cut answers during the development process leads to better team alignment. The fewer choices a person must make independently, the less drift you will have in the design choices.
What is the biggest challenge you see designers and engineers run into when working together?
The biggest challenge is having designs that are complete and speak well enough to the desired functionality. We use tools like Figma and Invision to better collaborate between teams, but this is an ongoing process — and there’s not a perfect solution for us yet. We are also working towards leveraging Storybook more heavily. Storybook is a great collaboration tool for architected components — but for new components, there’s still a gap between getting the designs out of Figma and creating something in Storybook to discuss further or implement.
Designers and engineers bring very different perspectives to the work they do. What can these teams do to better understand each other’s space?
Tools like Storybook allow engineers to parametrize components and create usable chunks of UI that the design team can leverage in their decision making and communication process. Over time, as these internal component libraries mature and the two teams work together on them, a shared understanding of capabilities gets established. Working this way brings these two perspectives together — but it takes time and concerted effort to be immersed in the same tools as either an engineer or consumer of the tool.
As internal component libraries mature and the two teams work together on them, a shared understanding of capabilities gets established.”
What’s a strategy you’ve found to be particularly effective for creating (and maintaining) alignment among teams?
We are still working towards this goal in some respects. I think a design team that adheres to reusable design patterns and a brand or theme does an engineering team justice. The engineering team can create reusable components shared across all of their applications in a way that’s predictable and maintainable. This creates alignment and efficiency across teams not only during implementation, but any future communication or collaboration.
