Implementation disagreements with a designer or a backend developer follow the same playbook — only the vocabulary changes.

The universal approach

1. Ask why before pushing back. Their position usually protects something real you can't see yet.
2. **Translate your concern into their language.**
3. Bring evidence — a prototype, a benchmark, a payload size.
4. Offer options, not a no.
5. Disagree and commit on reversible decisions; escalate only true non-negotiables.

With a designer

The concern is usually feasibility, performance, or accessibility vs. their UX vision.

The designer wants a parallax hero with scroll-linked animations. You're worried about jank on mobile.

• Translate: "On a mid-range Android this drops to ~25fps — that is the UX, just a degraded one."
• Prototype both, test on a real device, decide together.
• Option: full effect on desktop, a tasteful static/reduced version on mobile (and respect prefers-reduced-motion).

With a backend developer

The concern is usually about the API contract — shape, granularity, number of round-trips, who owns which logic.

Backend returns deeply nested data; you want a flatter shape, or you want one endpoint instead of three calls.

• Understand their constraint: maybe the nesting mirrors the DB, or one endpoint is hard to cache.
• Translate: "Three sequential calls means ~600ms of waterfall before the page is usable — here's the network trace."
• Options: a BFF/aggregation layer, GraphQL, a single composite endpoint, or the frontend stitches it (with the cost noted).
• Agree on the contract explicitly (types/schema) so neither side guesses.

Short STAR

Backend wanted the client to make 4 calls to assemble a product page. I shared the waterfall trace showing 700ms of dead time. We agreed on a single /product/:id/page aggregation endpoint — backend owned the stitching where it was cheap, and TTI dropped by ~half.

What interviewers want to hear

• The same calm, evidence-driven process regardless of who you disagree with.
• You respect their domain and assume their position is reasonable until you understand it.
• You make the trade-off explicit and measurable, then let the right owner decide.

Senior framing

The senior move is recognizing that most "implementation disagreements" are really undefined contracts or invisible trade-offs. Once you make the API contract explicit (with a designer: the responsive/accessible behavior; with backend: the schema and call pattern) and attach real numbers, the disagreement usually resolves itself.