In 2013, I developed a web-based system for a transportation company. Looking back, that project changed the way I think about software.

 

When I delivered the first version, I felt confident about the result. The interface looked clean, the features were complete, and from a technical standpoint, everything worked as intended. I assumed people would be able to use it without much difficulty.

 

I was wrong. Within the first few days, I started receiving phone calls from the company's staff. Most of their questions weren't about bugs or technical issues. Instead, they struggled with everyday tasks—uploading documents, finding previously registered letters, or simply figuring out where to go next. Tasks that seemed obvious to me during development were not obvious to the people who actually used the system.

 

That experience made me realize that the biggest problem wasn't the code. It was the gap between the way I had designed the system and the way users naturally approached their work.

 

Since then, I've tried to look beyond visual design and functionality. Before deciding where a button should go or how a workflow should be organized, I ask a different question: "What would make this easier for the person using it?"

 

Looking back, that project taught me something I still carry into every new project: people don't experience software the way developers do. Understanding that difference has changed the way I design, build, and evaluate digital products.