Beyond the Try-Catch; Code optimization prevents the system from crashing, UX optimization prevents my users from making mistakes in the first place

developer studying user behavior for error reduction

As a developer, I’ve spent a lot of time obsessing over technical stability. I used to think that as long as my try-catch blocks were solid and my local caching was efficient, I had a “resilient” system. But I’ve realized there is a much bigger bug we often ignore: User Confusion.

I’ve learned that a confused user is an unpredictable user. And an unpredictable user will find ways to break a system that no unit test no matter how robust can ever catch.

human use past experience from different scenario to solve present problems

My Secret Sauce: Cross-Industry Intuition

I’ve always loved creating product and poster designs, and learning marketing strategies to catch user attention or divert in certain cases.

I take ideas from other practices that have nothing to do with code and apply them to my frontend work. I’ve built a sort of “intuition” by immersing myself in:

• Interior and Product Design: In a gym, dumbbell racks are designed with the heaviest weights at the bottom and the lightest at the top to prevent injury and maintain stability. I apply this logic to heavy, multi-step forms. I front-load the “heavy” fields and reduce the number of inputs as the user progresses. This makes the form feel “lighter” the further they go, reducing fatigue and increasing the chance they’ll actually finish.
• Minimalism: To me, minimalism isn’t just an aesthetic, it’s a functional requirement. If a feature doesn’t serve a direct purpose ; it’s noise.
• Marketing Strategy: Typography sizing for eye flow , contrast color for high and low impact actions, symbols and icons that represent real life to reduce recall.

Watching the documentary “The Social Dilemma” was a turning point for me. It showed me how UX isn’t just about buttons; it’s about how technology integrates into our very vocabulary and lives.

Some recommended to know more on human behavior aspects:

1. https://ixdf.org/courses/hci-perception-and-memory/lessons/1.1
2. https://ixdf.org/master-classes/how-to-design-for-the-human-mind-cognitive-science-for-ux

Moving from “Gut Feeling” to a Blueprint

In the projects I work on, I’m often encouraged to supervise design choices. But I found that telling a stakeholder “it just feels off” rarely wins the argument.

courses from IXDF that help to know study user behavior aspects

This is where my studies into IxDF (Interaction Design Foundation) changed everything. Using their **Heuristic Templates allows me to objectify my “hunches”. The Shift: Instead of saying “I don’t like this,” I point to a metric like “Consistency and Standards**”.

I especially enjoyed learning about Cognitive Load and Human Behavior Phycology. As someone who personally struggles to remember complex flows, Miller’s Law (+ or — 2 items) became my go-to tool. It helped me rethink how to reduce the load on enterprise-level applications, especially in fast-moving environments like logistics.

certificates acquired in the coursers of one year

If your organization isn’t exploring these skills, you have to be the one to call it out. I’ve found that my best insights come from observing the teams who train our users. When I hear a trainer explaining flow over and over again just to help a stakeholder understand a screen, that is my cue. If a feature needs a manual to be understood, it’s a design failure. I want the interface to be an intuition, not a memory test.

You don’t need a degree in Psychology to build better apps. I started with “little dosages” of knowledge, and you can too:

1. Observe: Watch a user actually interact with your screen. Where do they pause? That pause is a bug.
2. Curate Document: Use resources from IxDF to back up your design choices with science.
3. Call it out: If you see a pattern that increases cognitive load, speak up. Your team and your users will thank you.

Comment down some improvement/ prediction that you have raised in your team / organization which eventually became a concern , but there was insufficient data or proof to back you up at that time.