Another thing that research should include is whether there was a previous version of the same product that failed and why, and whether there is a current competing product, and whether it will be possible to break into the market.
Tom - good article, thanks. The first step in NPD is to answer the question " what problem do my customers need to solve" and from there devleop the checklist as you suggest. You're correct, too many companies come up with their version of a "solution" first, then ask users if they like it - it is a backwards approach. I'm going to forward this article to my coleagues in marketing.
One side note: working on only one cup of coffee, I read your sentence "You should walk away from this type or research thinking" as "you should avoid thinking about research this way". After a few minutes I realized "you should come away from this type of research knowing that:" Then it all made sense! Time for more coffee...
Interesting... when you are attempting to design multiple paths to a single function, how do you ensure that it is clear which path is a priority, or put more simply, how do you make sure the user is not confused by the multiple paths?
Time and time again I would put the user interface through its paces and find flaws in the specification, or put it in front of the customer to see that it wasn't really what they wanted. OEMs will draw screen shots of what they want, but rarely practice the process of pushing buttons and watching the display change. We started filming people when they had their first experience with a user interface and were always surprised to see what button they would attempt to press for a desired function. I still feel the best user interface allows multiple paths to the same function.
I am always hesitant to agree with anyone who declares, "This is THE WAY it is done." Which is written first; the music or the words? Depends on the artist.
I worked with and for a man who rarely had an original thought, yet he was able to improve on almost any project we had, once someone else got the process rolling. He used to joke that he was only good at second-guessing, but it worked for him. He became very wealthy and retired early to a life of ease.
The comments about putting prototypes in front 0of people brings to my mind that great lie,"Consumers are demanding this", when that is not the case at all. What happens is that marketing types think up some feature to make their product different. We see them worshiping "product differentiation", which is supposed to bring out those features that somebody is demanding, while the truth is that nobody ever thought of that feature.
AND OF COURSE the new feature is never tested as to useability or usefullness, or how it will work with other functions.
So it is indeed vital to do some actual research, much more than asking a group of five, who happen to not need to be at work, what they think of some offering. And it is indeed far better to first find out where an actual need is, and then do a bit more research, and finally come up with a design concept and a design.
Tom, I myself am guilty of "WAY too many R&D people just think, "I would do it this way", or "this seems to work for me". These people may be from Mars, and actual users may be from Venus!"
Not so much on test equipment projects as we generally had predefined customer specs and a huge experience base that went a long way - I designed production and lab test equipment and we were pretty good at what we did with a thorough understanding of the operating environment. Because we maintained what we built and interacted with the operators on a daily basis, usability was already a part of our paradigm.
So it seems funny to me that I didn't take this into consideration when I was designing my small business website. I developed it the way I liked it - without considering whether or not it was user friendly to my audience - I assumed that since it made sense to me, it would make sense to others. Since I was an engineer who owned horses, and my target audience was horse owners, this did not translate so well. My engineering background was a liabiity in my design since most of my audience were rural non-engineers with access to limited technology(some are still on dial-up). After conducting some usability studies I implemented some major changes that met the needs of my customers much more effectively. While this is not the development of a product - it does illustrate the need for researcjh up front rather than operating on just your own instincts.
The Smart Emergency Response System capitalizes on the latest advancements in cyber-physical systems to connect autonomous aircraft and ground vehicles, rescue dogs, robots, and a high-performance computing mission control center into a realistic vision.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.