by Simone Pompe, Frontend Developer, and Lisa Reichart, Senior UX/UI Designer

Contrary to the common misconception that design is “just about making things look nice” and development is “just about implementing it somehow,” our goal at meteocontrol is to create the most user-friendly experience possible—for our customers, who must keep track of highly complex energy and control systems on a daily basis. Every frustrating interaction costs valuable time, while every intuitive interaction fosters focus. For this to succeed, a relationship is needed that is often underestimated: the one between designers and developers.

In our session “An underrated relationship: When designers and developers work hand in hand” at Hackerkiste 2025, we demonstrated how close collaboration not only reduces misunderstandings but also significantly shapes a product.

The path to achieving this quickly resembles a sweat-inducing round of Overcooked—a cooperative video game—where clear agreements tend to give way to a frantic back-and-forth. Yet clear principles help us navigate the path together without obstacles.

Misunderstandings, the Waterfall Model, and Frustration—and How to Do It Better

We’ve all been part of projects where the following situations keep cropping up:

• Designs are created for components or user flows when it’s not even clear yet whether these will be needed later.
• Clearly defined requirements are missing right from the start of the project, a fact that becomes painfully obvious to everyone involved—at the latest—during implementation.
• The waterfall model—a model with strictly sequential and self-contained project phases—creeps in.

And in the end, both sides ask themselves: “What kind of collaboration are we actually engaged in here?”

To build a foundation that involves both sides, rather than just passing off responsibility, we follow four basic principles.

Our Four Principles for a Strong Design and Development Partnership

1. Kill the hand-off – Collaboration does not begin only after the design phase

Traditional handoffs (“Here’s the link to Figma—good luck!”) have caused plenty of frustration. That’s why handoffs are outdated, and our approach is: 

• With the first prototypes, the design team initiates discussions with the development team; for complex issues, this happens even earlier.
• This allows us to discuss the technical feasibility of requirements as early as possible and incorporate them into the design process.
• In line with the concept of shared ownership, we establish mutual responsibility for the project without blurring the lines of accountability.

This helps us avoid surprises and create solutions that are both user-friendly and technically robust.

2. Talk like a team – A common terminology prevents us from guessing wildly

Equal footing, lively discussion, and a shared language are the buzzwords here. What does that mean?

• In the design system or style guide, standardized terms are used for UI components so that everyone knows whether a modal or a dialog might refer to the same thing.
• Still have questions? We ask the team directly! Often, someone else has already had the same thoughts.
  • Tip: If you include a proposed solution with your question, the person you’re asking usually responds faster. This is helpful in situations where we already have a good idea and are just looking for confirmation.
• Lively exchange in the form of daily and weekly stand-ups—and, very importantly, ideally modeled after the “hot potato” process. This means working together frequently and with overlapping efforts on the same topic, as this accelerates the resolution of open questions and fosters mutual understanding.

Create visibility in sprint reviews with stakeholders and also in dedicated design reviews—a process in which UX/UI-relevant implementations are cross-checked by designers before they go live.

When we all share the same perspective, the project stays on track and heads straight toward the goal.

3. Single source of truth – Key points of the specifications

To ensure that designs and implementations stay on track, we need to agree on where we want to document specific information. This prevents misunderstandings and helps keep all information up to date, since it isn’t scattered across five different locations.

Specifically, this means:

• Design requirements do not belong in the ticket. They are maintained in our design tool (Figma).
• Components are maintained consistently—in our already implemented component library as well as in the design system in Figma, which is synchronized with our style guide in Zeroheight.

Consistency—in the product and within the team—can only be achieved when both worlds refer to the same sources.

4. Respect finished work – Compromises instead of roadblocks and fresh starts

What happens when a ticket is already in code review and suddenly a message pops up saying, “I noticed something else…”? Frustration takes over, and concerns grow that everything implemented so far will now have to be changed. That’s why we make sure to:

• Break tasks down into the smallest possible steps. This makes refinements shorter and effort estimates more reliable.
• Changes can occur at any time. In such cases, the team should decide together whether a follow-up ticket to address the new requirement makes sense or whether the existing ticket needs to be blocked.
• Don’t just demand a willingness to compromise—practice it yourself: In disputes, it makes sense to first gather and weigh objective arguments from both sides. On this basis, it’s often easier for the team to decide on a new course of action.
• Avoid stagnation—but also avoid a “start-from-scratch” approach when it’s not necessary

Respect for work done is a sign of appreciation and ensures that teams stay motivated rather than burning out.

What this means in practice

With our talk, we wanted to show what happens when we continue to bridge the design-development gap. 
Suddenly, ideas aren’t just discussed—they’re taken further. Designs don’t emerge in a vacuum; they evolve alongside development. A design is scrutinized, adapted, and technically considered through dialogue between design and development—from the initial concept to implementation. And along the way, the entire team understands the context, sees the connections, and collaboratively develops solutions that actually work and eliminate ambiguities.

Conclusion: True collaboration isn’t just a nice-to-have—it’s the foundation

At meteocontrol, design and development share the same goal: to create products that support our customers in their daily work.

When both sides think, communicate, and make decisions together from the very beginning, a true partnership is formed. The result is software that not only works but also delivers real added value.