UX vs. Dev: The Ultimate Friendly Face-Off (with my pal Tom)

Ah yes, the age-old debate: UX vs. Developers. Okay, —it’s not really a war (most days), but you know what I mean. If you’ve worked in digital, you’ve probably had a few heated discussions across the UX/Dev divide. I know I have.

To dig into some of these common sticking points—and maybe shed a little light on both sides—I sat down with my good friend Tom. He’s great at both front-end and back-end dev, so he knows his stuff.

So, gloves off, keyboards at the ready—here we go!

Me: Alright, Tom. Let’s just start here: Why is it that when I write a user story about how a form should behave, including the microcopy and error messaging, it often gets... let’s say, “adapted” in the build?

Tom: Look, I love a good user story. But sometimes the microcopy feels like an afterthought, or it’s a bit too wordy. We’re often thinking in terms of logic first—what the form needs to do. So we’ll throw in “Error: Invalid input” just to test functionality, and suddenly that placeholder never gets replaced. Not intentional! But maybe we need a better process to flag final copy vs. filler.

Me: Fair! So, when I do write functional user stories, what’s usually missing that would make your life easier? What would stop all that back-and-forth in Jira or whatever program we're using?

Tom: Details. Sweet, glorious details. Stuff like: “What should happen if the user clicks this button but hasn’t filled anything in?” Or “What happens on mobile?” Often we get a general story, but not the edge cases. I’d love a simple checklist—expected states, success vs. error flows, mobile/responsive notes. Saves a lot of back-and-forth.

Me: Got it. Now let’s talk wireframes and prototypes—what drives you up the wall?

Tom: Two words: Ambiguous states. A lovely wireframe will show a perfect, sunny-day version of a UI—but what happens when content breaks? Or when there’s no data? Also: hover states, focus states, transitions. If they’re not in the prototype, we’re guessing. And then... you say “that’s not what I meant.”

Me: Fair point. So what about design assets—what’s usually missing or makes your dev brain ache?

Tom: Clear naming! Layers in design files are often chaos. If I see “Rectangle 470” one more time... Also, exportable assets in all the right sizes and formats, and knowing what’s meant to be scalable vs. fixed. Bonus points for design tokens or a mini style guide with spacing and type rules.

Me: Now let’s talk CMS design. When we design front-end stuff for a CMS, I always think about the end-users (the content team), but I feel like this gets lost in translation. What’s your experience? Would you like UX to provide user stories for managing the CMS too?

Tom: Yes please! The CMS experience often ends up being a mystery box. We’re left guessing how the content team is supposed to interact with fields. If you can give UX input on things like alt text guidance, character limits, or when to use null values—it makes it easier to build smarter defaults and reduce the chance of user error (or developer confusion).

Me: On to user testing. How much involvement would you like to have, and how do you prefer we share feedback?

Tom:I’d love to be looped in more! Not necessarily in every session, but getting context helps. If all I get is “change button to green,” I’m missing the why. Understanding what didn’t work helps me make better decisions and maybe even spot opportunities to improve beyond the fix.

Me: And lastly, let’s talk accessibility. What do you expect UX to provide to support accessible builds? Should we be specifying heading markup, ARIA roles, etc., or do you just do your thing?

Tom: If it’s clear in the designs and user stories—that's great. But if it’s not, we’ll either miss it or make assumptions. I’ll always try to build accessibly, but specifics help. UX can guide things like semantic structure, focus order, or which interactions need screen reader support. If you give me that up front, I’ll love you forever.

Me: Well, that was... not as combative as I imagined. Anything else you want to throw in before we call it a draw?

Tom: Just that it’s all better when we talk early and often. Devs and UX aren’t on opposite sides—we’re on the same team trying to build something great. So let’s keep chatting, keep documenting clearly, and maybe, just maybe, keep the Jira comments to a reasonable level.

Conclusion:

So there you have it! A peek behind the curtain at the conversations UX and Devs should be having more often. Let’s stop the “us vs. them” mindset and start building better things—together.

Got a dev you’ve butted heads with (in the best way)? Send them this post and start your own friendly debate!