Designers and engineers have a lot more in common than they think.
The two disciplines are often positioned at odds with each other, operating in different silos unless completely necessary. But it doesn’t have to be that way.
“The biggest challenge I’ve seen is isolated streams of work,” said Brian Blomer, a senior digital program manager at the manufacturing company Caterpillar.
It’s not that one side doesn’t value the other’s contributions, but that they have fundamentally different ways of working. Even when striving toward a common goal, it’s easy to stumble into misunderstandings.
That’s why Blomer emphasizes the need to not only foster collaboration between individuals, but joining forces with disparate groups — no matter how challenging.
“The intent is to build trust and open collaboration through the ideation process,” Blomer added. “This, in turn, will build alignment and prevent any technical limitations later.”
To learn more about how to avoid an us vs. them mentality, Built In Chicago reached out to a group of local designers and engineers who have embraced a culture of collaboration to inspire solutions and fuel synergy and alignment throughout the development process.
What is the biggest challenge you see designers and engineers run into when working together? How have your teams overcome it?
In my experience, across organizations, the biggest challenge I’ve seen at times is isolated streams of work. Architecture solutions start without the customer experience, or UX designers ideate without engineers’ participation.
I have seen a lot of success by simply starting with the customer first — having a virtual collaboration session where designers and engineers agree on a user persona and map out what the ideal experience should be. This allows the team to anchor itself to a visual artifact of a baseline experience. Engineers can think through what specific application programming interfaces are needed or how the architecture needs to scale to support that experience. Likewise, designers are able to hear an engineer’s technical insight as part of the ideation exercise. This is easier said than done, but I would encourage designers to help their teams articulate a problem statement and their user persona, then work toward some type of structured ideation activities, such as design sprints or journey mapping exercises. And remember: Share your designs early and often to build support and get feedback from engineers and product teams early in the process.
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 can be a perception that developers don’t need to see designs until they are “ready.” In my experience, development partners can be the greatest allies in creating a great product for customers. I recommend bringing development leads into the creation space. Allow them to hear the problem statements that are being solved and how the team is beginning to think through solutions. Likewise, I encourage designers to lean into development discussions on architecture or API work. These technical discussions can provide a wealth of information for how the experience works, but also spark solutions that were previously unknown.
Development partners can be the greatest allies in creating a great product for customers.”
What’s a strategy you’ve found to be particularly effective for creating and maintaining alignment among teams?
In addition to workshops and formal design reviews — which engineers are invited to — providing developers visibility into actual design artifacts is an effective tool for alignment. Collaborative interface design tools can allow full transparency for development and product leaders to access flows and visuals weeks before handoff. They can also provide feedback and recommendations directly to screens.
What is the biggest challenge you see designers and engineers run into when working together? How have your teams overcome it?
In my experience, challenges between designers and engineers generally show up in one of three ways: as a disagreement about the feasibility of a feature, as debate around the validity of a design decision or as discrepancies between the intended design and the developed experience. All of these situations can be resolved through open-minded discussion, but that kind of conversation requires a foundation of trust. The biggest challenge I see between designers and engineers is a lack of trust. Without a trusting relationship, small conflicts cause big delays, and big conflicts become insurmountable.
As a general rule, trust takes time to build, and teams that work together for longer have more time to learn from each other and naturally build rapport. That said, I’ve had the opportunity to work on some great teams over the years, and one practical thing I’ve observed strong team players do is to consistently frame their opinions within a level of confidence. For example, as the designer of a feature, I might say, “I’m very confident that our customers need this information because of the research we conducted, but I’m less sure that this is the best way to display it.”
Without a trusting relationship, small conflicts cause big delays, and big conflicts become insurmountable.”
Designers and engineers bring very different perspectives to the work they do. What can these teams do to better understand each other’s space?
From my perspective, it’s just as important to understand your coworkers as people within an organization as it is to understand them as experts within a discipline. We are all at different points in our careers and skill development, different points in our personal lives and different points in finding our place within an organization.
As a younger designer who was eager to make an impact and see results, I frequently failed to drive the change I aspired to simply because I didn’t appreciate the complexity of the social dynamics. Respecting your colleagues as people who are managing complex lives and relationships is the first step toward understanding their perspective at work, and how best to work together.
What’s a strategy you’ve found to be particularly effective for creating and maintaining alignment among teams?
Consistent, purposeful meetings keep teams aligned. That may sound overly simplistic, but in my experience, having a regular communication routine goes a long way toward maintaining stability and shared understanding, especially during periods of dramatic change. As a leader, it can be tempting to cancel or reschedule meetings when you don’t have clear direction or something encouraging to share. But I have found that holding the meeting and sharing the status of whatever is in progress keeps your team informed, motivated and supportive.
Another, very basic, habit that I’ve adopted for maintaining alignment is running meeting documentation. At ShopRunner, I usually attach the document to the recurring invitation so everyone knows where to find it. For my team’s biweekly design meeting, we use an ongoing slide deck where everyone has the opportunity to share their updates visually. For my leadership meeting, we have a text document with bullets and links to anything pertinent to the group. This simple habit creates a place to understand the context for decisions and remind ourselves what we’ve committed to.
What is the biggest challenge you see designers and engineers run into when working together? How have your teams overcome it?
The biggest challenge I have found is finding time to meet as we work across different timelines. Designers tend to work on tighter deadlines with shorter sprints, while our machine-learning teams work on projects that can span several quarters. Motorola Solutions' solution has been relatively simple: We bring designers into our development process by giving them as much warning and flexibility to meet as we can, generally starting these meetings as early as possible.
Designers and engineers bring very different perspectives to the work they do. What can these teams do to better understand each other’s space?
Machine-learning engineers bring a practical perspective on how to execute new technologies, while designers bring creative approaches to solve problems. In order to find synergy between the two, I always believe that, as engineers, we should be listening more than talking in our meetings and adopting a “yes, and” mindset. This helps us build on ideas rather than limit them. This simple adoption of language helps frame new ideas as exciting engineering challenges, as opposed to concepts that must be constrained in order to make them practical or possible. After all, in software, there is very little that is actually impossible.
This helps frame new ideas as exciting engineering challenges, as opposed to concepts that must be constrained in order to make them practical.”
What’s a strategy you’ve found to be particularly effective for creating and maintaining alignment among teams?
One strategy we have found to be successful for aligning teams is putting together a workshop early in our development process prior to collecting data or facilitating experiments. The workshop consists of product managers, researchers, designers and machine-learning engineers defining the end users and their needs, and from there, developing a sequence of steps in a user experience. Virtual tooling has helped immensely with this process, keeping a record of workshop progression so we can triage workflows from an engineering standpoint while maintaining utility for the end user.
What is the biggest challenge you see designers and engineers run into when working together? How have your teams overcome it?
Inconsistencies and communication. At One North, we pride ourselves on creating pixel-perfect digital deliverables, which puts a lot of pressure on our teams. In a traditional waterfall approach, designers are responsible for delivering many different page mockups for multiple screen sizes, which invites inconsistencies between font hierarchy and sizing, spacing and color. This, compounded with inevitable time constraints, can be confusing for a front-end developer who is creating a template system between components and pages that doesn’t match the designs, despite careful interpolation of the design files. Without a clear line of communication between teams, the final result can end up very different from what was envisioned and shown to the client.
Our agency-wide adoption of the design platform Figma helps us streamline our workflows. Designers have the tools they need to work consistently across entire projects, using component libraries, auto layout and shareable libraries for color and font systems. Developers use the Inspect panel to easily grab exact CSS values. We’ve also built in more overlap time for designers and developers to collaborate directly instead of at a fixed hand-off point.
Without clear communication between teams, the final result can end up very different from what was envisioned and shown to the client.”
Designers and engineers bring very different perspectives to the work they do. What can these teams do to better understand each other’s space?
It’s as simple as open lines of communication. Designers and developers have a lot more in common and shared knowledge than they think. That’s why, along with UX strategists, our Experience Design practice group includes both designers and front-end developers. We have shared team spaces for inspiration as well as team meetings to share ideas and keep current on digital trends.
While design as a discipline is of course thought of as creative, I try to stress that front-end development is incredibly creative as well. Just like designers, front-end developers must also be creative problem-solvers, and there is never one solution to a development problem. This similar line of thinking is what leads to our best brainstorming sessions, when both designers and developers are pitching ideas to each other for interactivity, animations and overall site flow. And that is where the magic happens.
What’s a strategy you’ve found to be particularly effective for creating and maintaining alignment among teams?
Involving both teams early on, and keeping that momentum going throughout the project. It’s not always possible from a resourcing or budget standpoint, but for the most part, we try to make this a standard on most projects. Front-end developers should be involved from the wireframing stage onward to give perspective on what is possible and what makes sense from a build and budget standpoint. Designers need to stay involved through testing to ensure that from static to interactive, the design is visually consistent with their vision and what they have promised to the client. While this may seem more costly upfront, the savings are in the timeline and the work that does not need to be redone or iterated several times due to a lack of understanding on either side and with the client.
What is the biggest challenge you see designers and engineers run into when working together? How have your teams overcome it?
One of the biggest challenges I’ve found is that collaboration is generally an ad hoc activity and not something that’s necessarily scheduled into a sprint. In addition, sometimes neither team is accustomed to nor has had the luxury of collaborating with each other. To overcome this, with any new team at Stride, I outline how I like the teams to collaborate in order to talk through any problems the engineers are encountering while implementing the design. I introduce the concept of design pairing, where we’ll sit together — virtually nowadays — and work through tweaks so the final result reflects the design mockups. I also encourage the engineers to bring us problems as they encounter them, rather than waiting for the end of the sprint. In addition, I ask the designers to ideate with engineers about any design solutions that may be a little tricky in order to get their input before it’s finalized. Daily standups are the perfect time to bring up any problems and arrange for collaboration.
Designers and engineers bring very different perspectives to the work they do. What can these teams do to better understand each other’s space?
Designers need to understand that there are no maybes in coding. For every element on the page that requires an action, engineers need to know what happens when that element is clicked or hovered over. In addition, designers need to think about what should be displayed on the UI when the happy path doesn’t happen — that is, when a search result returns nothing or when an error occurs. If there aren’t designs for these, then the answers need to be in the story’s acceptance criteria.
Engineers need to understand that designers are often restricted by a brand’s design library and can’t always play outside the box with layouts or interactions. In addition, initial designs focus on the happy path for a feature with perhaps an alternative flow. Edge cases usually aren’t addressed until they’re identified, which sometimes happens once the engineer starts getting into the code. Collaboration is key here, and the engineer and designer can decide whether acceptance criteria will cover the edge case or a design solution is needed.
Designers need to understand that there are no maybes in coding.”
What’s a strategy you’ve found to be particularly effective for creating and maintaining alignment among teams?
I have found it’s essential for designers to be included in the various sprint activities. Not only does it allow them to see what’s going on with the overall project, it gives them a voice into the upcoming sprint.
Pre-grooming and grooming are where they can explain their design thinking and walk the engineers through the designs. It also gives engineers the opportunity to ask questions so they can get a fuller understanding of behavior and interactions on the UI. Sprint demos, especially if there are multiple development teams, let designers see that, as the product is developed, all aspects are aligned with the brand guidelines and design library.
It’s also very helpful to the engineering team to see the end-to-end product walkthrough, especially as additional features are designed throughout the project engagement. These design demos give them a thorough understanding of the various features that comprise the full application and how the current sprint fits into all of that.
