Reading a UI like a user, not a developer
Developers and users see interfaces differently. The gap between those two readings is where most UX problems live.
Developers see interfaces differently to the people using them. We see components, states, edge cases. Users see a task they’re trying to finish. The gap between those two readings is where most UX problems live.
The shift I’ve had to practice — and still have to consciously make — is reading an interface as a sequence of moments, not a collection of elements.
The first second
What does a user see before they’ve processed anything? Not what’s there, but what registers first. If it’s a wall of options, the screen has already failed.
The path of least resistance
Users don’t read interfaces — they scan for the thing that looks most like what they want. If the path of least resistance leads somewhere wrong, most users will follow it anyway, then blame themselves.
The moment of doubt
Every interface has a moment where the user isn’t sure what to do next. Good design makes that moment short. Bad design makes it a loop.
The recovery
What happens when something goes wrong? Developers think about this in terms of error handling. Users experience it as embarrassment or frustration. The copy in an error message matters more than most developers think.
I try to read an interface at least once the way a user would — starting from the top, following the obvious path, noticing where I hesitate. It’s a small habit that catches a lot.