Experts - the detriment of usability development?

I have one philosophy going - try not to be the expert of the program - instead, let the domain experts tell you what they know. This way, you can remove yourself from all the noisy data and the intricacies of certain ways of doing things. What I try to find most of all, is to ask the right question to compel a better response to find the answer.

Of course, easier said than done. To NOT become the expert requires almost complete removal of yourself and the ego some designers or usability practitioners might have. I heard of one definition of what certain politicians are suppose to do - represent their constituents - namely, our users.

So in that case, remain objective in no matter what you do. Most of all, embrace uncertainty because even though I might have to learn or become familiar about a certain program, all I really need to do is learn enough to understand the why's and the how's and the sequence that they come in so that even the sequence or its fundamentals can be shifted to improve productivity.

I'm finding that the experts that give me the data can sometimes be too much - so I read between some lines and find the fundamentals, something the novice user can understand. Because let's face it, the experts and the expert users aren't necessarily your everyday user - what about those coming aboard to learn the program? To dumb-down the level on conceptual understanding translated through a less complex and task-flow streamlined interface is the way to go, and I believe this eases the tension more for these expert users. They become experts for a reason - the interface is sometimes too difficult to understand, so they go about learning everything within the program so that they can explain it to someone who's a novice. Ever thought of that perspective?

If you keep it simple, in no matter what you do, you'll get the message across a lot better and people will use your programs more often with less hassles. And so, not as many "experts" develop.

A process for digesting user feedback

One thing I've learned through the television program CSI, is that the evidence doesn't tell all. In the case of user experience design, neither does user feedback.

If I just blindly follow the user feedback, without combining principled thought into your designs, I would just end up with very little functionality or something unusable. The fact of the matter is, any time I come into such feedback, either positive or negative, there's always something to be learned here. Most of all, question the fundamentals - question the feedback.

I ask myself why someone says what they said. Is there a better way where I'd be able to change that perspective but tweaking my design? I usually answer - "Of course". And that's where better ideas come to solve the problem. I focus on the desired result, asking myself - "I want them to say -this- about the interface, now how could I go about getting that result?"

I look at many things in user feedback.

1. Patterns - namely, user habits.
2. "Negative" feedback - it's not always negative. There's actually more to learn from it.
3. Why it was interpreted the way it was - find the causes.

I then look at possible steps to correct or enhance the user experience in small bits at first, then use a bit of my subconscious (i.e. experience) to guide me. In these steps, I usually do several quick prototype iterations either in my head or on a whiteboard where I can explore solutions and its interactions to solve the inherent usability problems. Then I translate the best solutions into the actual mockup.

This is just one of the ways where digesting user feedback is taken in little steps - and systematically at that.