Ahmad Haizul Amany

I usually start by figuring out what someone needs to get done. I follow that task through the interface and the data behind it, then build a small working version so I have something concrete to question.

Once it works, I go back through the awkward parts. I try longer text, narrow screens, failed requests, and changes that haven't been saved yet. Those checks often reveal something the first version missed.

I also change my mind. A reference can look convincing on its own and feel wrong inside the actual project. When that happens, I revisit the decision and keep what holds up in use.

I value interfaces that tell the truth. A successful save should mean the data was saved. If a request fails, the page should explain what happened and keep the work someone has already entered.

Consistency matters to me because small differences create extra work for the person using an application. A familiar control should behave the same way wherever it appears.

I care about being able to return to my own code later, too. Clear names and a short explanation of an unusual decision make it easier to understand what I was thinking and decide what needs to change.