[hyperman1]

Give your program to a real user. Ask them to do a task. Shut up, look, and watch 'm squirm. Keep up for an hour. If you start assuming this particular user must be braindead and failed basic logic, repeat with a new real user until the lesson sinks in. Realize your crystal-clear design has in fact plenty of holes, and user will curse your name if you release now. Bang head against wall for therapeutic value (your head, not theirs). Congrats, you're now an UX expert.

I did it once. Turned out my understanding of the real core problem was deeply flawed.

UPDATE: Maybe interesting to give some details of this. I was developing a program everybody called the calendar. Basically there's a list of people, and they need to have a timeslot each somewhere in the next year. Customer was the people who scheduled these time slots.

First version of the calendar app was ... a calendar. Columns monday tuesday wednesday ..., rows with hours and minutes. Drag a person on top of it and presto. You know the drill.

Testing with users revealed something was off. No user could really tell what was wrong, it looked exactly as they had asked, but everybody agreed this was not it.

Somehow, the better design dawned: Even if they called it a calender, they wanted a task list. Not the date/time aspect but the person aspect was central and required most screen estate. They needed to be able to select the right people in the right order, giving priority to some people but also being sure nobody was forgotten. Date/time selection could generally be automated or needed a simple text field so they could quickly type it in.

The redesign took about a day. All the business logic and most of the UI widgets could be recycled. Just had to add a dumb list with checkboxes. Nevertheless, it looked completely different when finished, with widgets moved between pages and resized as their importance grew or shrunk. I kept a calendar widget in there out of some kind of residual guilt, but it was almost completely ignored.

[hyperman1]

Maybe another fun example: Data entry. The state has some official paper form, people want to type it in the computer. So I created a page with fields in a reasonable order: First identification, then contact info, then the different aspects forming the purpose of the form.

One day, I manage to acquire an actual form as provided by the state. It turns out to be organically grown and the resulting field order made no sense at all. The first field was a phone number, for some reason. Name and surname were actually on 2 different pages, with lots of stuff in between. No idea how it got so messed up.

So I ordered the fields in my form in the same bad order as the state form. Users loved it. The could just tab-tab-tab quickly fill it in.

[mgkimsal]

> Realize your crystal-clear design has in fact plenty of holes, and user will curse your name if you release now

If you're a designer working with some web folks... don't be too proud to take their feedback as well. I've lost count of how many times I was given a set of mockups that were confusing. When I raised the point of "this is confusing to me - I don't understand X"... sometimes it's taken to heart and we converse and iterate. Sometimes it's not, and I'm pushed to "just do it like this", which almost always leads to ... a big delay in getting the exact same "this is confusing" feedback from people weeks or months later.

To be fair, this hasn't happened to me as much in the last... 3-5 years. And there are times I really do not know the domain very well. What's confusing to me is 'industry standard' (labels/names/workflow/etc) - sometimes there's even regulatory reasons for doing things a certain way. I learn from that.

The other side of that is... I've worked on systems for 6-12-18+ months, and know how the system is currently providing value. "Designer X" coming in and making radical changes without any ability to give them feedback - at any stage of the game - is just really bad.

If someone has more experience in X, and tells you "this is confusing/wrong", they might just be correct, and everyone can save a lot of time by addressing the confusion earlier rather than later.

> Even if they called it a calender, they wanted a task list.

I've hit this exact one a few times, from both angles. Wanting a task list, but calling it 'calendar', and wanting a calendar view, but using "schedule". Takes some digging and sometimes side by side comparisons of 2 or 3 different visualizations, but eventually we get there :)