In a fast-paced B2B SaaS environment, especially when engineering is shipping continuously and design is stretched thin, it’s easy for UX to become a bottleneck. Either you get pulled into every minor decision, or worse, bypassed altogether in the name of speed.

This post is about how we changed that…

How we built a two-way working relationship between engineers and designers. One where trust and autonomy go both ways, and where small improvements can be shipped without waiting weeks for capacity or approval.

The problem

We had a legacy consistency issue. Our team had been operating across three separate products, all built in isolation. Eventually we merged them into a single modular product. The result was messy.

• More than 100 colour swatches

• Multiple font systems

• Components and patterns clashing across views

• UI decisions made without any shared baseline

Engineers were rightly focused on roadmap-impacting work. Smaller design issues weren’t making it into planning, and designers were being pulled into low-priority visual questions constantly.

We needed to break the dependency. Engineers needed a safe way to make smaller design decisions. Designers needed the access and support to make low-risk UI changes directly.

What I did

1. Created a shared rulebook

I wrote up clear, scenario-based guidance showing when design should lead, when we should be informed, and when we weren’t needed at all.

It gave engineers clarity and confidence, and helped designers stay out of the weeds.

2. Paired with principal engineers to understand the workflow

I took time to properly understand our tooling, naming conventions, PR etiquette and repo structure. This wasn’t just about being able to write code. It was about making sure that when we submitted a PR, it wouldn’t cause unnecessary rework or tech debt later.

3. Built a design reference guide for engineers

I wrote a short internal guide, inspired by Refactoring UI, covering design basics like form structure, spacing, hierarchy, keyboard accessibility and microcopy.

It wasn’t about training engineers to design. It was a safety net for the moments when a designer wasn’t available and a quick call had to be made.

4. Started tackling small design debt in the code

Designers started actively contributing small UI fixes straight into the codebase. Things like inconsistent padding, overuse of shadows, duplicated tokens, and broken mobile layouts.

The kind of stuff that doesn't make it into quarterly planning, but still chips away at user experience if left untouched.

5. Joined tech meetups and showed up

I made a point of regularly joining internal tech sessions. Sometimes to listen, sometimes to present. Topics included UX laws, usability heuristics, or just sharing a perspective on a recent release.

This helped keep UX visible, and showed that we cared about the same things as engineering.

What changed?

• Designers started submitting PRs regularly and cleaning up the interface without waiting for dev time

• Engineers stopped seeing UX as a blocker for small design decisions

• Our styles began to converge. We cut down our grey palette from 27 tints to 7. Colour tokens and font styles got cleaned up. Our design system finally started to take proper shape

• Most importantly, the process started to feel collaborative and lightweight, rather than dependent or ceremonial

We didn't need a major “design and engineering initiative.” We just needed shared expectations, clear boundaries, and the ability to work in each other’s worlds without stepping on toes.

Final thoughts

This was never about designers becoming engineers, or engineers becoming designers. It was about giving both sides permission (and empowering) to contribute without creating risk or friction.

In lean, cross-functional teams, you can’t afford handoffs and over-policing, you need to trust people to act in good faith, and give them the tools to do it well.

This shift gave us that. And the product is better for it.