Shark_M wrote:Yeah but you should give the doctor a feed back as to what is the best way to heal your injured arm. A doctor could solve the problem just by giving you pain killers, that would stop the "Complaining", and the problem would appear as gone for you. But the arm is still broken! Or a doctor might just solve it by amputating it, instead of healing the broken bone! SO the expert can only present "Possibilities" or spectrum of possibilites to the customer, and let the cusomter choose which possibility or option to go about and producing a solution to the posted problem. This has a basis in the Scientific Theory itself. You have to get feedback to know what is the best answer to the problem.
What you call "feedback," I call describing a problem. "It hurts when I move my arm this way, but not that way." What you don't want to do is tell the doctor "the best way to heal your injured arm." That's the doctor's job. Did you go to Medical School?
Real doctors do not fix broken arms by amputating them. (Or at least, not competent ones.) But if your doctor runs tests and your broken arm turns out to be gangrenous, your doctor might NEED to amputate to save your life, even though you would be telling your doctor, "All I need is some more Percoset."
Bottom line, it's a cooperative process, but at some point you have to decide who knows more, who's doing the design, who's driving the bus. If you know more than your doctor, why are you going to a doctor?
There are many expert companies that produced solutions, that would work and all, but they did not work well for the intended people....
Either poor implementation, or poor design, or failure to understand the original problem. Usually it's the latter...
Shark_M wrote:The Information Technology sector is growing, more and more people are becomming mini-experts on computers, and they know alot than before. So what if 80% of the end users are experts, would you not want to tell them how a tool was made, or what would be a good way to go about producing a solution? Option A or Option B?
The "savvy" people can be the worst, because sometimes they think they know it all. "I once launched Microsoft Access, therefore I know relational database design."
I mean when you did a project for some customer, dont you first have an outline of the project, and show the pathway to getting the project done to the customer?
No, the first thing I do is listen. And take notes. And ask questions. I try to understand the problem really, really well, before I get anywhere near having "an outline of the project."
Once I'm at the point where I can describe the problem in my own words, the customer's eyes light up and they go "Yes! Finally, someone who understands the problem."
The best doctors are the ones who take the time to listen as well.
Customers should be shown and asked "What is best for you. If i place a TreeView or aListview, or a radio button, or a check mark".
I think that's incredibly scary. LOL
The Doctor doesn't say, "What is best for you? Xanax, Percoset, or Aspirin?" Those drugs do different things.
Treeviews, Listviews, Radio Buttons and Checkboxes all do different things. They don't substitute for one another. For hierarchical structures, you'd use a Treeview. For a series of exclusive choices, you'd use Radio Buttons, etc. I've seen those hellish applications where someone implemented Checkboxes instead of Radio Buttons because the customer thought Checkboxes were prettier, or whatever.
Again, the task is to know the problem in sufficient detail so that you KNOW (as a Designer) whether to use a Treeview, or Listview, or whatever -- not to ask the customer what they prefer.