Open source thrives on engineering-driven processes. Fast feedback loops, terminal tools, Git workflows: they’re the lifeblood of how we build software in the open. But for software to truly excel, we need to create user experiences that empower people to use them.

Here’s everything I learned from “Navigating engineering-focused environments.” 

1. Collaborating on the same workflow

One of the biggest misconceptions we face is the idea that designers and developers need separate, isolated workflows. Glòria immediately challenged this: at GitHub, teams work in an EPD (Engineering, Product, and Design) model, walking lockstep together. Ultimately, users don’t care how your internal teams are organized, they just care about the final product.

One way to blend these workflows is to integrate design directly into the engineering cycles you already use. Eriol shared a story of introducing “Design QA” alongside standard engineering QA, which turned the QA process into a collaborative space for discussion from both parties to understand each other’s perspectives and criteria points for something to be approved. David agreed, providing an engineering manager’s perspective. He considers that performing Design QA is a necessary step before merging any PR: designers must review the proposed change to ensure the engineered result actually aligns with their original design intent. 

• For designers: Don’t default to a rigid design framework and lifecycle. Take the time to learn the specific environment of the engineering team you are working with.
• For engineers: Invite designers into your processes early. Eriol noted that engineers are often “just waiting for the invitation” to get involved in design, and the same goes in reverse.

2. Promote communication, empathy, and translation

Culture clashes often happen when we don’t understand the constraints the other side is facing. 

For example, Glòria shared how designers can get frustrated when a seemingly simple UI filter is blocked by backend data models, leading to unfair assumptions about developers being “lazy.” The fix? Designers should expand our skillset to understand how the architecture and data models actually work.

Likewise, engineers will invariably find edge cases in a design. Designers and engineers need a culture of shared critique where feedback is given at eye level, without fear. Communication is critical.

But how can teams communicate effectively in open source communities? Asynchronous work is the norm, and face-to-face meetings may be rare. Eriol provided a novel approach to solving this debate.

What that means is treating design files as documentation. By adding version control, dates, and decision logs directly into your design files, designers can speak a language developers respect. Sharing working spaces and norms in this way helps to remove friction, making teams more effective in knowing what decisions are being made, how they are being made, and why those decisions have been made.  

The takeaways:

• For designers: As you get closer to the code and prototype with real components, the translation gap between design and engineering shrinks. Keep your early concepts low-fidelity to invite collaboration, rather than presenting a “finished” high-fidelity mockup that engineers feel they can’t contribute to.
• For engineers: Learn the intention behind a design. When you understand why a designer is deliberately using specific whitespace or information hierarchy, you build a mental toolkit you can apply to future features.

3. Prove the value of design

In environments where design might be seen as secondary to shipping features, how do we prove its impact? The answer is simple: put the product in front of real users.

For engineers, joining in user testing sessions alongside the researcher or designer is highly motivating, according to David. Seeing someone struggle with a tool or product in real time makes you want to get it right, a sentiment supported by personal experiences for each of the panelists.

Glòria shared how observing a visually impaired user navigate a sign-up flow caused the engineering team to prioritize accessibility fixes the very next morning.

Eriol recounted a story where an engineer sat in on field tests in Kenya to stress-test an app under poor connectivity. The results? The engineer stayed up all night enthusiastically writing user story issues from a newfound perspective (hopefully they got their sleep as well).

Beyond user testing, Glòria pointed out that UX work, like standardizing patterns and building design systems, is fundamentally systems thinking. Getting engineering buy-in becomes much easier when developers realize that standardizing UI components means they can delete legacy code, scale faster, and maintain less technical debt.

The takeaways:

• For designers: Don’t just tell engineers what to do. Show them the users’ pain points and write user stories to frame your specifications.
• For engineers: Design isn’t just about making things pretty; it solves complex problems like discoverability, accessibility, and consistency.

Conclusion: Be a community!

Building great open source software requires both excellent engineering and thoughtful design. The path forward is built on mutual curiosity and collaboration.

To the engineers reading this, don’t be afraid to seek out design input, ask questions about user needs, and attend design-focused meetings. To the designers, don’t be intimidated by the technical barriers. Lower the drawbridge to your discipline, go into engineering spaces, observe how they work, and contribute authentically.

As Eriol summarized, “Open source is as much about software as it is about being in community with each other.”

Join the Canonical design team

We’re looking for designers who care about craft and how systems work under the hood. At Canonical, design sits at the intersection of UX, engineering, and open source where we shape cohesive, accessible experiences across cloud, desktop, and IoT products.

If you enjoy solving complex problems and turning technical depth into clarity, explore our open roles: canonical.com/careers