Technology First vs. Needs First

There’s a debate that’s been going on in the design and user research community because the legendary Don Norman wrote an essay in which he did an about-face and decided that doing user research to start a project was mostly a waste of time.


老汤注:唐纳德·诺曼(Donald Arthur Norman,1935年12月25日-),为美国认知心理学家、计算机工程师、工业设计家,认知科学学会的发起人之一,关注人类社会学、行为学的研究。代表作有《设计心理学》、《情感化设计》等。

That’s an oversimplification – he actually was only talking about those seeking the big, society changing innovations like the airplane, the telephone, and indoor plumbing. He argues that in each of these cases, first the underlying technology had to be invented, and then only later did we discover uses for it.  So his point (and title of his essay) is – technology first, needs last.


In part I think he’s trying to shake up those in the design community that advocate a very dogmatic approach of first doing weeks or even months of research to determine needs (e.g. ethnographic research, market research, user research), and only later come up with the technology to deliver on these needs. I’ve also known many of these people that believe this is how innovation is supposed to happen.


Unfortunately, while I think there is an important truth to Norman’s observations, I think his conclusions have confused a lot of people.


I’d like to use this debate to try to underscore what I think is a fallacy of those that believe needs come first, and those that believe technology comes first.


In fairness, for typical, incremental innovations like improving the effectiveness of a web site, Norman thinks that observing users and determining their issues first and then using those learnings to drive technical solutions is great, and I would argue that covers the majority of what most of us do in product. Not many of us have had the chance to work on something that radically changes society.


However, for most interesting innovations, it’s not that technology comes first and then needs second, and it’s also not that the needs come first and then technology second.  Rather, it really is a collaborative and parallel effort between product, design and engineering to come up with solutions that are both possible/feasible and useful/valuable.


When Fred Smith innovated to create what would become FedEx, it was a beautiful blend of combining a long-standing need (getting a parcel from anywhere to anywhere overnight) with a solution that was just now possible – a fleet of jets using a hub and spoke system and some impressive logistics software and hardware.


When the TiVo team innovated with the DVR, it was a beautiful blend of a long-standing need (recording was such a pain with video tapes and we hated being forced to watch commercials) with a solution that was just now possible – a low-cost Linux-based appliance with a very large hard disk and some very impressive video management software.

还有TiVo团队基于DVR的创新, 它是一个结合了存在已久的需要(用录像带记录是如此的痛苦,我们讨厌被迫观看广告)的解决方案,只是现在可能——一种低成本的基于linux的设备与一个非常大的硬盘和一些非常令人印象深刻的视频管理软件。

Apple is full of examples of just such elegant combinations of technology and need, and the iPad is just the latest.


Are FedEx, TiVo and the iPad as fundamental to society as the invention of the airplane or indoor plumbing?  Maybe not.  But are they non-incremental innovations that have had a profound impact on their respective businesses and their customers?  Absolutely.  And in every case this wasn’t just pure technology research hoping to one day be useful.  Rather, they were all innovations built on the back of hundreds of other innovations, but without question driven by the desire to solve specific hard problems addressing real needs.


Now, I think the value of Norman’s argument is that none of these innovations required months of formal market research or ethnographic research in order to understand the user or market needs.  No, the real challenge was in coming up with solutions that were feasible and usable. The need wasn’t the issue.


Norman’s argument is similar to the argument against Waterfall or marketing-driven products. Spending a bunch of time up front defining the problem sounds logical but isn’t the way innovation works. And of course we learned a long time ago that you can’t get the solutions from the customer because they don’t know what’s possible.


So while I agree with Normal that spending a lot of time up front is not time well spent, I do believe there is value in framing the need or problem to be solved, as this often opens your mind up to alternative approaches to solving the problem.  But I argue for a very quick problem definition statement (e.g. an opportunity assessment).


But I think the deeper issue here is that this overly simplistic view of “technology first” or “needs first” obscures the real dynamic of what happens during product discovery.


I would argue that it’s not very hard to start with a clear need, but product discovery is really about trying to find a solution that addresses that need (it’s valuable), is usable and feasible. Product discovery can have lots of outcomes:


– Sometimes we validate that this need is real and users are hungry for a solution, but sadly the solution isn’t yet technically feasible – either because of missing or immature core technology, or because of cost (development time or investment required), or because of performance.  I never like to give up too quickly on feasibility because so often I’ve been surprised by what the engineers can solve when you include them in the discovery process, and give them a little time to think about it and try out different approaches.

– 有时我们验证这种需要是真实的,用户渴望得到解决方案,但遗憾的是,该解决方案在技术上还不可行——要么是因为缺少或不成熟的核心技术,要么是因为成本(开发时间或所需投资),要么是因为性能。我从不喜欢过快地放弃可行性,因为我经常惊讶于,当你把工程师包括在发现过程中时,他们能解决什么问题,给他们一点时间来思考和尝试不同的方法。

– Sometimes we find that users are not nearly as concerned about the need as we were, and it’s really not such a great product idea after all. Or a variation of this is that we discover that there are reasons behind the current solution and they are motivated to resist changing to a better solution.  Happens way more often than we like to admit.

– 有时我们发现用户不像我们那样关心需要,它也不是一个很好的产品想法。或者另一种说法是,我们发现当前的解决方案背后有一些原因,而这些原因促使我们抵制向更好的解决方案转变。发生的次数比我们愿意承认的要多。

– Sometimes the need is real and the technology is feasible, but the solution is just so complicated or foreign that users can’t figure it out, or are unwilling to invest the time to learn.

– 有时候需要是真实的,技术是可行的,但是解决方案太复杂或者太陌生,用户无法理解,或者不愿意花时间去学习。

– Sometimes the very act of putting your ideas in front of users and letting them play with it (and open their eyes to what’s possible) opens up new possibilities, occasionally even more powerful than your original concept.  We call that a “pivot,” and it’s one of my favorite surprise outcomes of product discovery.

– 有时候,把你的想法呈现给用户,让他们去体验(并打开他们的眼睛去看什么是可能的)的行为本身就会带来新的可能性,有时甚至比你最初的想法更强大。我们称之为“支点”,这是我最喜欢的产品发现惊喜之一。

– Most of the time, however, once we put our ideas in front of users, and we can see which aspects of their needs are addressed well and which aren’t, it provides us with the insights and understanding we need to refine our solution, sometimes in minor ways and sometimes in significant ways, but we iterate and zero in on a good solution – one that is valuable, usable and feasible.

– 然而,大多数时候,当我们把我们的想法摆在用户面前,我们可以看到哪些方面的需要并没有解决好,它给我们需要改进我们的解决方案提供了眼界和理解,有时在次要方面,有时在重要的方面,但我们迭代和把注意力放在一个很好的解决方案上,它是有价值的,可用的和可行的。

It’s not always pretty, and it’s not always predictable, but one way or the other, you’re combining a real need with something that’s technically possible.


I think the lessons to be learned from this debate include not only Norman’s point of not going overboard on user or market research before you start considering feasibility, but also on the importance of viewing innovation as a true collaboration between product, design and technology where we strive to discover solutions that are valuable, usable and feasible.


分享到QQ 分享到微信 分享到微博

0 条评论



  • 昵称 *
  • 邮箱 *
  • 网址