Bridging Design and Engineering: How Office Hours Lower the Barrier for Collaboration

Several months ago, I was brought on as a contractor to design an internal Observability tool for a large enterprise organization. The team had been managing design work alongside their engineering responsibilities—creating UI concepts in Figma, developing features, and making interaction decisions. Design reviews naturally focused on technical feasibility and implementation details.

Walking into my first meeting, the opportunity was clear. The tool had a strong technical foundation, and I saw a chance to complement that with dedicated design thinking and user-centricity.

The Challenge: Finding Structure

Meeting with every developer individually to review UI concepts wasn't sustainable. Fragmented feedback would create friction, not clarity.

But here's the thing: the developers were already doing design work. They were crafting UI concepts, making interaction decisions, and shipping features. They weren't waiting for a designer to save them—they were moving forward with what they had.

That realization changed everything.

The Solution: Design Office Hours

I created optional 30-minute Design Office Hours, Monday through Thursday.

It felt like a natural progression. Developers were already thinking about design—they just didn't have a dedicated space to collaborate on it. Office Hours became that space.

Started small with the core UI developers, then expanded to product and tech leadership. The goals were simple: learn the domain, provide design feedback, build relationships, and gradually own the design work.

Different developers attended different sessions. Sometimes simple UI feedback. Other times, deep dives into complex workflows where technical context was everything.

A few weeks in, I started seeing the shifts:

• Deeper insight into Observability workflows
• Lower barriers to influencing design decisions
• Easier collaboration built on trust through regular, low-stakes touchpoints
• Natural role clarity—knowing when to consult versus take the reins
• Structure that gave the team predictability and accessibility
• More doors opened to influence user-centricity in product development

Building Trust on the Ground

Without support from tech leadership and product, this approach could have easily fizzled out and I still had to earn trust on the ground.

I went the distance. I watched YouTube videos on Observability patterns, used AI prototyping tools to visualize complex workflows (vibe coding), read technical articles, and asked many questions through Slack chat. That willingness to step into their world is what built real partnership.

Trust takes time. It's earned through small, consistent actions—not grand gestures.

The Bigger Lesson

Design Office Hours worked for me, but they might not work for you.

I was figuring it out as I went, taking a risk on something I'd never tried. The format mattered less than the goal: lower the barrier for collaboration and make it easy for people to work with me.

Your version might look completely different. Lunch-and-learns over pizza. Pairing sessions while developers build. A Slack channel for quick feedback. Prototyping in standups.

The point isn't to replicate what I did—it's to experiment with what makes sense for your context. Try something. See if it sticks. Pivot if it doesn't. The willingness to adapt matters more than getting it perfect.

Looking back, a few things made the real difference

• Read the room. Developers were already designing—I just gave them a space to do it collaboratively.
• Create consistent, low-pressure touchpoints. Make collaboration optional, regular, and collaborative—not prescriptive.
• Learn their language. Understand their constraints, priorities, and workflows.
• Start small, then expand. Build trust with a core group first.
• Have leadership support—and use it. It gives you permission to push for change.
• Experiment and pivot. Take the risk. Adjust as you go.
• Show, don't tell. Demonstrate your craft in action. Present multiple design patterns to solve the same problem—show them the options and reasoning, not just abstract principles.

Engineers solve problems through logic and systems. Meet them there. Show how design consistency reduces bugs, user testing catches issues before deployment, clear feedback prevents errors, and thoughtful hierarchy speeds up development. When design solves real problems for them, collaboration deepens.

And it by showing up. Learn how they work. Adapt to what they need. The rest follows.