29. You Can't Fix a Bad UX With Great Code

Once, someone asked me: "Thijs, can you take a look? I'm not sure how to do this. We need a deep link to an important form, but that form sits halfway down a page behind a tab. How do we handle that?"

And sure, there are plenty of technical ways to make it work. But the real question is: why is an important form hidden halfway down a page behind a tab in the first place? That's not a coding problem. That's a UX problem.

So the solution turned out to be technically much simpler: go back to UX, and adjust the UX so this important form is no longer "hidden" on the page.

Unfortunately, this isn't an exception. I regularly see developers struggling with something that looks technical at first glance, but is actually a design flaw, a process issue, or a product decision.

A few common examples:

• A "simple" form with 12 fields because nobody dares to remove anything.
• A flow with a surprise at the end ("Oh by the way, you also need to create an account.").
• A page trying to be everything at once (info, settings, actions, explanations) and therefore doing nothing really well.
• Buttons and labels that make sense internally, but are unclear for users.
• A feature that's "done", but requires three clicks just to reach the core action.

And then something interesting happens: As a team, we try to "fix it with code".

We add tooltips. Wizards. Helper texts. Conditional UI. Workarounds. And yes—technically, it's all possible. But meanwhile we're stacking complexity to compensate for something that fundamentally isn't right.

Great code can't save bad UX. It can only reduce the pain a little.

That's why in my work I collaborate closely with UX. Because the real power of a great application doesn't come from UX "designing something" and development "building it" afterwards. That approach often feels like throwing work over the fence.

The best results happen when UX and development operate as one team: shaping the problem together, weighing trade-offs together, and getting the best out of both disciplines. UX brings clarity and direction. Development brings technical reality and possibilities. And that combination is what makes a product truly strong. 🤝

I also have a UX background myself: I graduated as a UX'er and hold a Master of Arts in Interaction Design. So I speak that language, and I understand where UX is coming from. But over the years my focus shifted more towards development—and there are many people today who are simply much better at UX than I am.

And honestly: that's a good thing.

That's exactly why I love to spar with UX. Just a quick check-in: can we make this flow a little clearer? Can we remove things instead of adding more? Are we helping the user—or are we mostly "patching" a poor decision?

If you want to train this mindset in your team, use this checklist before you start building:

• 🧠 What is the user actually trying to achieve?
• 🧭 Is the flow logical without training or explanation?
• ✂️ Can we remove things instead of adding more?
• 🚪 Is there a more direct path?
• 🤝 Should we redesign this with UX/Product instead of "implementing" it?

Good developers solve problems. Strong teams make sure they solve the right problem. ✅

So next time your team is stuck on a "difficult" ticket, ask the question out loud: "Is this really a coding problem… or are we trying to fix a UX problem with code?"

Do you recognize this in your team?

• Features keep getting more complex "because that's just how it is"
• Developers spend more time on workarounds than delivering real value
• Discussions get stuck on implementation details, while the actual problem isn't clear

If your team struggles to solve the right problems—or if building has started to feel like constant "patching"—I can help.

I step in as an interim (frontend) lead to align development and UX, simplify flows, sharpen scope, and make your codebase predictable and maintainable again.

Send me a message and let's have a quick chat. 🙂