Marriage of Minds: When Designers and Engineers Co-Create

🎧 Listen to this post on Spotify

In tech, when engineers and designers don’t work well together, it causes delays and poor outcomes. It might go unnoticed when this happens at, say, an ad-tech company that can easily absorb delays. However, in civic tech, where budgets are constrained and project failures put the public at risk, we have to consider every sustainable way to help projects succeed. The quality of collaboration between engineers and designers can be the tipping point, where small changes lead to significant improvements in delivering on-time solutions.

On a personal note, fifteen years ago, a recruiter scrubbed design from my resume. Since then, I’ve downplayed my experience in fashion, fine art, and graphic design to package myself as a serious software engineer. But I never stopped designing because I love doing it.

Fast-forward to today. As part of the support for in-house civic tech teams working in public transit, I’ve learned to value my interdisciplinary perspective as an edge in positioning designers and engineers for success.

That said, cross-functional teams can slip into a rut where they act like the workplace equivalent of a divorced couple who still live together but lead separate lives. Sure, they work out some arrangements, so the garbage always gets taken out, but they don’t benefit much from their relationship because they’ve prioritized being apart.

Fixing this may require shifts in thinking and team orchestration.

The following document explores four angles to mend and strengthen this strategic connection.

“I see the company itself as a handmade project.”
Rob Kalin, Handmade Millionaire: How Etsy’s Founder Struggled to Make Commerce Human, Sep 2020

“In this section a mathematical model of the growing embryo will be described.”
Alan Turing, The Chemical Basis of Morphogenesis, Aug 1952

Let’s take a moment to consider Rob Kalin, the founder of Etsy, the e-commerce marketplace connecting 46 million buyers with 2.5 million sellers. He is an entrepreneur, furniture designer, photographer, and artisan. His artistic background didn’t just contribute to his business success—he describes it as the very foundation of it because he saw opportunities where others didn’t. Or think about Alan Turing, whose unprecedented approach to cryptography brought together concepts from mathematics, logic, engineering, and early computer science and the observation of patterns in nature and biology, enabling him to crack codes, helping turn the tide of World War II.

These stories highlight an essential truth: artists and technologists (or artist-technologists) bring diverse perspectives to their work. Like designers and engineers on technology teams, their varied ways of looking at problems and lived experiences defy stereotypes that imply designers aren’t businesslike or that engineers can’t handle ambiguity. In reality, engineers and designers are often the people in any organization driving innovation through their deep engagement in customer needs and system capabilities—and their productive partnership.

However, when team structures pigeonhole designers as mere decorators and engineers as coding machines, they limit their ability to contribute strategically to delivering solutions. If left unchallenged, these misconceptions can become self-fulfilling prophecies. Designers and engineers may start to believe they are only what others see them as, disengaging at the most critical point in any technology project: solution design.

It’s no surprise that stereotypes persist in tech teams—they often don’t communicate clearly about each role’s purpose and how they fit together. While detailing every role here would be overwhelming, I’ve outlined key responsibilities to highlight their dynamic and interconnected nature.

In civic tech, designers:

• Conduct research with transparent rubrics to understand the needs and challenges faced by the public or operations staff.

• Apply problem-solving and critical thinking to identify root causes, ensuring technology teams address the correct problems.

• Deploy prototypes to gather user feedback, avoiding the high costs of building software to test early-stage hypotheses.

• Use storytelling to influence stakeholders and align them with the solutions that people need, especially when these solutions differ from initial expectations.

• Advocate for users during negotiations about product scope.

• Co-create conceptual solutions with engineers for collaborative delivery.

• Deliver visual designs tailored to the context, ranging from rough wireframes to detailed mock-ups.

• Partner with engineering throughout feature delivery to navigate emergent needs and unexpected challenges.

In civic tech, engineers:

• Partner with design teams to research the right people and scenarios, ensuring a clear understanding of user needs.

• Use iterative and incremental methods to release minimal versions of features early, validating their effectiveness and maintaining transparent delivery progress to preempt issues.

• Collaborate with designers to develop conceptual solutions for joint delivery.

• Investigate technical challenges and opportunities to guide implementation planning.

• Create implementation plans that balance trade-offs within constraints while maintaining reliability and security.

• Apply modern software engineering principles to produce maintainable code and ensure sustainable team operations.

• Adhere to info-security and infrastructure requirements to deploy scalable, secure digital services without compromising private information.

• Maintain relationships with internal IT partners, respecting different IT operating models.

• Write backend and frontend code that meets all expectations and is fully validated through automated testing.

• Manage integration and delivery pipelines to streamline operations and enable easy rollback during critical incidents.

Both design engineering have a shared responsibility to:

• Critically assess implementation work to prioritize tangible outcomes over mere outputs.

• Deeply immerse in their team's complex subject areas to become subject matter experts.

• Understand and adhere to applicable accessibility and inclusion standards.

• Navigate bureaucratic obstacles, departmental silos, and hierarchies that can unexpectedly jeopardize projects.

Today, anyone can fire up VSCode or Figma, watch a few online tutorials, and create something that seems workable. In civic tech, half-baked “trial-and-error” approaches don’t work. We need high-performing designers and engineers to use their expert judgment to navigate complex constraints, co-creating highly contextual and tailored solutions that address the unique challenges of working in government for the public. These solutions are often counterintuitive or have many dependencies; otherwise, they’d already be solved. Arriving at a viable and appropriate solution requires design and engineering to be on the same page, even before a wireframe is drawn or a line of code is committed. In many cases, the true benefit of having a designer or engineer on a team isn’t their specific outputs but their strategic thinking, which guides what the team works on and how they approach it.

The intersection of design and engineering is essential. Designers research and identify customer needs, and engineers tackle the technical challenges to meet these needs. They come up with solutions together that often involve design addressing technical limitations and engineers adopting human-centered design methods. This collaboration is key, particularly when government agencies deploy technology that can end up making life harder for their users.

When we recognize the unique and valuable relationship between design and engineering, it becomes clear that they must stand on equal footing. Any imbalance in power discourages the other from contributing their best work. We must create teams where designers and engineers are equally empowered to thrive.

Let’s delve into a fictional situation that mirrors the real-world difficulties designers and engineers encounter in their collaborative efforts.

On a civic tech team, two dedicated professionals found themselves at an impasse. A dedicated UX Designer, Nia shared her struggle with a heavy heart. “Approaching my manager felt like exposing a raw nerve,” she began. “I’d invested countless hours perfecting a design because it would be seen by and impact so many public transit riders, only to face brutal feedback from the engineers demanding extensive rework and questioning my assumptions. Each critique chipped away at my confidence, making me feel undervalued and disrespected as a professional.”

On the other side of the equation was Juan, a Software Engineer, who was also strained. “Once again, the designer on our team spent almost all our allocated project time creating a masterpiece that went far beyond what we can realistically build given the time constraints,” he began. “I know changes need to be made, but the tension between design and engineering is already palpable. Every time I bring up what I see as obvious adjustments, it feels like I’m walking on eggshells and running out of ideas to bridge this gap.”

Though the accounts are dramatized, they are close to the actual challenges voiced to managers. Communication suffers when a team artificially divides projects for two camps, one for design and one for engineering, instead of a single project with unified goals for engineering and design to meet. Whether managers impose this or when team members gravitate to functional silos, separation makes it unnecessarily hard for people to get on the same page.

Designers and engineers must simultaneously tackle the same problem to find the right solution more directly. When they work separately—even on related or intentionally sequenced workstreams—they won’t be immersed in the other side’s concerns enough to be an ideal partner because they will be too focused on their project’s separate goals.

Too often, communication between designers and engineers is filtered through intermediaries like product managers. This bureaucratic layer can lead to misunderstandings and inefficiencies. Instead, designers and engineers must communicate synchronously from the start of a project. Early discussions allow them to co-ideate, delivering a shared blueprint to describe their big-picture approach—preventing entrenched, one-sided solutions.

Designers and engineers simply need to talk regularly and have straightforward conversations about their vision. Unfortunately, organizational structures or a misguided sense of urgency often obstruct these interactions. Without space to think and talk through ideas, teams operate in perpetual “action mode,” producing work that requires unanticipated rework—leading to frustrations and delays—because initial assumptions about alignment were never confirmed.

Hand-offs would make perfect sense if digital product development were an assembly line like a toothpaste factory. The worker who fills toothpaste tubes doesn’t need to negotiate with the one who screws on the caps. Unfortunately, hand-offs are a disaster in non-linear, highly collaborative, and exploratory work.

Consider the typical scenario: designers do a significant amount of valuable work–in relative isolation from engineers, building up to a hand-off. By its nature, the hand-off method assumes that the design is essentially done, though inevitable revisions loom once engineers really engage with the subject area of the designs. When designers and engineers co-create from the start, hand-offs aren’t required because team members are already deeply involved and familiar with the project’s nuances, addressing issues individually as they arise.

The more siloed the team and the more expansive a project, the more contentious the hand-off. Rightfully proud of their work, designers might react defensively to feedback questioning their fundamental assumptions. They might wonder why engineers didn’t voice these concerns earlier, unaware that engineers were equally engrossed in their tasks. For better or worse, engineers may hold back during hand-off meetings, not wanting to rock the boat.

Next, hand-offs suggest designers will soon move on to something else, but this isn’t usually how it goes. Real challenges and adjustments arise during implementation, requiring design guidance.

At the end of the day, hand-offs are a side-effect of dysfunction and a form of “bad” process. As teams get more process-oriented, they might combat the “bad” process of hand-offs with the “good” process of share-outs–but maybe the solution isn’t more meetings. Replacing hand-offs with regular share-outs seems like an improvement, offering more frequent and incremental feedback. However, these are still formalized interactions between separate groups. For example, engineers don’t schedule regular meetings to share updates among themselves; they simply communicate as needed, sharing visuals or impromptu diagrams. This is the essence of teamwork.

Designers and engineers should embrace their roles within a cross-functional team, communicating freely and offering feedback naturally. The more they practice honest, synchronous, and regular conversations, the easier it will be, and they will face up to difficult conversations when needed. We don’t need to be dogmatic. Sometimes, hand-offs work; a share-out approach may be the right approach in some situations. Nonetheless, we should consider why we need these meetings to judge if they are better than the simple alternative of team members co-creating, co-delivering, and discussing their shared vision as needed.

We don’t live our best lives or do our best work selfishly in isolation.

Creating—in partnership for others—builds connection, purpose, and fulfillment.

For this reason, civic tech has an allure because we work in collaboration to serve the public, but the “collaboration” and “serve” aspects are not guaranteed. They depend on how we organize ourselves and strive to make change.

When compiling this list of focus areas, I was thinking about “Cultivating a culture of connection,” which U.S. Surgeon General Dr. Vivek Murthy described as one remedy for today’s loneliness epidemic, which erodes the health of so many people. While my primary interest is in delivering solutions to the public, it's affirming to see that bureaucratic box-checking and impersonal “processed work,” which we know people don’t like, isn’t what our projects need despite the proliferation of top-down approaches in tech. Projects do better when people work in an environment where they can build trust and allow themselves to be open, developing their personal sense of purpose so they can perform the best work of their lives—and be a part of a legacy of enduring impact.