我在某处读过（我忘记了来源，抱歉 - 我认为是 MS Office 开发人员的博客？），当您对用户进行调查时，询问他们希望在您的软件/网站中看到哪些功能，他们会更多通常说他们想要每一件小事，而收集的指标表明，最终，大多数人并没有使用 99% 的这些功能。博客文章的一般信息是，您不应该问人们他们使用什么，您应该自己跟踪它。
当试图弄清楚接下来要添加什么新功能时，这会导致不幸的先有鸡还是先有蛋的情况。如果没有该功能，我无法衡量它实际使用了多少。由于资源有限（且资源严重紧张），我也无法添加所有功能，然后删除未使用的功能。
你如何找出对你的用户有用的东西？如果调查是唯一的选择，您是否必须以某种方式组织您的问题（例如：不要显示可能的功能列表，因为这会引导他们）？
与普遍的看法相反，你不问他们。好吧，当他们告诉你他们想要什么时，你不听他们的。当他们使用他们现在拥有的东西时，你会看着他们。如果他们没有任何东西，你听他们足够多的东西给他们一个原型，然后你看着他们使用它。一个人实际使用软件的方式告诉你的比他们实际说的要多得多。观察他们的所作所为，找出他们真正需要的东西。
给他们选项，让他们按重要性排列它们。正如您所说，用户将想要一切，但这将使您能够说出他们最想要的东西。
你告诉他们。那你们俩就知道了。
（不，您的用户不会告诉您他们想要什么。那是工作。如果用户想要做更多的工作，他们就不会寻找软件来为他们完成工作。）
前世的一则轶事：
我们正计划发布一个新版本，并希望为应用程序添加一些新功能。我们将用户召集在一起，集思广益，讨论他们希望在系统中看到的内容，将每个“功能”放在白板上的黄色便签上。然后，我们将类似的请求组合在一起，并消除了重复或接近重复的请求。
然后，我们将每个粘性物放在一张桌子上，前面有一个杯子。每个用户有 10 美分来“投票”他们想要的功能。他们可以在每个杯子里放任意多的便士，如果他们愿意的话，最多可以把他们所有的便士放在一个杯子里。然后，我们计算了每个杯子中的便士数量，并按得票顺序选择实施前 5 名得票者。
令人惊讶的是，人们在集思广益和分类时对某项功能充满热情，却不为该功能投票（或轻轻投票）。
当然，这样的技术只有在您可以随时访问您的用户群时才有效（这是针对我们内部开发的企业系统）。
你问他们。
（不，你不知道你的用户比他们更想要什么。是的，你会得到很多愚蠢的答案。避免多项选择调查，而是选择查看自由形式的答案。你收集的信息将是无价的。 )
当然——你总是可以让你的用户投票选出他们最喜欢的功能......
用户知道他们不想要什么比他们知道他们想要什么更好。
我们引入了一个团队来执行 Oracle eBusiness Suite 实施。他们采取了一种有趣的方法，过去对他们非常有效。但这在我们的环境中是惊人的。
我们有文化问题，这意味着没有一个用户会伸出脖子说出他们想要的东西。我与过去的用户有过历史。试图从他们那里得到要求就像试图从石头上取血一样。但是一旦你上线，就会开始讨厌。
无论如何，实施团队开箱即用地安装了 Oracle eBusiness Suite。对用户进行基本培训。然后在接下来的 6 个月中，他们大约每 4 周定制一次基础安装以适应投诉。
我建议不要向他们展示选项；正如您所指出的，如果它可用，那么人们会为了拥有它而想要它。用户通常不知道开发特定功能的额外成本，只是想要它，因为您提到了拥有它的可能性。
另一种选择是列出您可能添加的所有功能的列表，然后为每个功能附加价格，然后询问用户，拥有功能 Y 是否值得 X 美元，或者您会多花多少钱愿意为功能 Y 付费吗？
尽量使用自己编写的应用程序。然后，您将知道如何改进您的应用程序。
根据37 Signals - Getting Real的书，你什么都不做，你甚至不记录他们想要的东西，你只是在阅读后删除邮件，没有任何动作。
在实施/修复内容时，您会记住用户最想知道的最重要的事情。显然，这需要一点用户基础。
您需要将功能与成本联系起来。每个人都想要功能，但并非每个功能都值得付费。询问哪些功能最重要，您的用户愿意为哪些功能付费？根据用户提供的优先级开发功能，并在他们不愿意支付更多费用时停止。尽快将产品交到他们手中，这样您就可以获得关于哪些不起作用以及需要添加哪些内容的真实反馈。当用户可以访问真正的软件时，您可以获得更好的信息。当您专门为特定客户进行开发时，这最有效。如果您无法接触到真正的客户，请考虑免费为您的产品播种（您可以说是公开测试版吗？）以获得更好的反馈。
了解用户“真正”需要什么的唯一方法是“成为”用户。其编程功夫黑带级别。
“就像水从裂缝中流过。不要固执己见，但要适应对象，你就会找到绕过它或穿过它的方法。如果你内在没有什么是僵硬的，外在的东西就会暴露出来。清空你的思想，成为无形无形如水会崩溃。做水我的朋友。
当您成为水/客户时，您现在就可以了。
我认为李小龙会是一个很好的程序员。
我很认真。这就是我的工作方式。我不能做我不明白的事情，所以在我做事之前我必须了解。当我明白了，我的顾客也知道我明白了，我就能做好。没有理解就会产生误解。您是唯一知道您何时拥有正确理解水平的人，您也是负责获取该知识的人。
用户不知道他们想要什么功能。您不知道它们可能提供哪些功能。“特征”除了帮助他们完成任务和实现目标之外没有任何意义。这就是你应该开始的地方，因为他们对它们之间的关系有非常不完美的理解。
他们知道一件事，也许，比你好得多。这就是如何完成他们的工作。
一旦计算机/软件概念和术语开始渗入用户和设计师之间的讨论中，你就偏离了轨道。
很多时候，用户会将他们的需求集中在他们当前使用的软件有什么问题或可以改进的地方。随着时间的推移，即使他们也失去了他们的工作和他们用来完成工作的软件之间的区别。
解决这个问题对你来说是一个非常困难、至关重要的问题。
德尔福的甲骨文
优点：准确性非常好 缺点：如果你能解释信息，很多人都做不到（经常看到他们想看到的）。还需要恳求，这可能会变得一团糟（与流行的观点相反，你的坟墓不必是 100 只相同类型的牲畜）。
通灵者
优点：精确到一点。
缺点：很少见。容易精神不稳定，极易受到可怕生物的攻击，并可能引起他们不必要的注意。此外，需要经验来梳理人类思维的奥秘，以获得所需的信息。有时你仍然需要在他们实际做他们需要帮助的事情时探查他们，因为用户撒谎。
种下鼹鼠
优点：新的小工具。新毒药！计划中的计划中的计划。宝贝是个怪胎秀。除了帮助用户所需的信息之外，您还可能学到各种有趣的东西。
缺点：昂贵。代理仍有可能会攻击你，或者无法学习任何你无法更简单地学习的东西。如果被发现，组织可能会转手或清算资产，这代表着巨大的资源投资。组织可能会有所回报。
猜测
优点：带一群想象力和解决问题能力一般到极强的人，给他们喝点酒，并用《捉鬼敢死队》、《小中国的大麻烦》或《大卢博夫斯基》中的一些名言来激励他们。谁知道它会去哪里，但它会很有趣，他们可能会产生一些有趣/有用的东西。
缺点：满足用户需求的机会比你想象的要高，但不是那么好。
询问用户
优点：作为流程的一部分，用户感到被赋予了权力。
缺点：直到他们必须决定任何事情，此时您只能靠自己了。除非用户是一个非常有经验的用户，在这种情况下，他们可能很清楚自己想要什么。不过，这个星球上只有大约 4 个经验丰富的用户，而且没有人知道有谁可以为他们工作。他们可能是神兽。
假装你关心并询问用户（即使你并不真正关心），然后观察他们做任何涉及的关键工作流程/流程/等，并注意他们在做什么。
优点：你欺骗用户认为他们的意见很重要，这赋予了他们权力，但不会带来任何其他包袱。由于用户撒谎- 没有故意或恶意的想法 - 您实际上可以看到他们的行动并更好地掌握问题所在，从而为构建解决方案提供更好的基础。此外，你避开了通灵路线，从而避免了一条漫长而曲折的道路，这条路以承诺开始，但以你和通灵者被不属于这个世界的某种可怕的、无法形容的东西吃掉而告终。观察这个过程就像完全是禅宗，这对你的开发者神秘感有好处。
缺点：没有到 Oracle 的公路旅行（这将是 EPIC）。间谍更性感。小鸡挖间谍。捉鬼敢死队|小中国的大麻烦|大Lewboski可能没有参与。感觉比其他选项更像工作。
向用户询问功能将促使他们与您讨论功能。
如果您想了解用户真正想要什么，那么您就是在谈论了解他们的目标和动机。我发现开始这样做的最简单方法是用户访谈，而不是关于功能，而是关于用户如何使用您的产品和类似产品，他们为什么使用它以及它如何适应他们的生活。
一旦您了解了用户尝试使用您的产品做什么以及他们为什么要这样做，您就可以对人们要求的功能是否是他们真正需要的功能做出明智的判断。
理想情况下，我认为您的问题在于了解用户，而不仅仅是倾听他们的请求。
这是一个老问题，已经有很多很好的答案，但我想我只是为了将来像我一样通过搜索最终来到这里的人们添加一点个人经验。
如果您的项目不需要尽快获得受众以取得成功（如 web 应用程序），如果它更多是为固定客户或客户类型出售的内部项目或产品，那么我相信您最好赌注是采用 37signals 的方式：首先为您的用户提供他们需要的绝对最低限度，以完成最基本的工作周期中最基本的任务，然后倾听他们所说的客观缺失的内容，以便他们完成他们的工作好好工作。不是他们想要或希望它拥有的东西，而是他们真正需要的东西。你确定你真正需要的唯一方法就是当你没有它的时候。
我在一个基于 Intranet 的“公司核心”应用程序的开发团队中担任设计师，该应用程序遵循该策略，结果非常好。第一周：每个人都很生气。当它结束时，90%+ 的批准，应用程序仍然简单漂亮。大多数不完全满意的人似乎都明白为什么它不能像他们想要的那样，几乎每个人的主要要求是，无论我们做什么，保持应用程序简单。
同样，如果您正在开发需要首先吸引人们的产品或网站，那可能不可行或延迟很多事情。但是，如果您对用户群有一定的控制权或回旋余地，我肯定会推荐这种方法。
你不要求功能。你问问题。痛点。找出他们对当前解决方案的厌恶之处。找出他们的时间吃什么。
当您知道他们不喜欢什么时，您就可以为这些问题构建解决方案。
当你解决真正的问题时，你就是在创造人们会乐意为你花钱的真正产品。
但同样重要的是在你的研究阶段尊重他们。调查仍然很适合做研究，但如果你问他们十几个问题，他们会讨厌你。您需要尊重他们的时间并使用能够吸引他们并留下深刻印象的调查工具。
事实证明，用户不知道他们想要什么。你需要问他们现在的问题是什么——他们对你的软件有什么问题？他们为什么不使用 x 功能和 y 控件？为什么交互 x 对他们有用，而交互 y 让他们试图判断自己的眼睛？
当然，为了能够提出这些问题，您需要进行一些实地研究，看看使用了哪些功能，您的用户展示了哪些模式并分析了这些数据。该分析将为您提供更具体的问题的基础，用户能够果断而准确地回答这些问题。
用例。
他们将如何使用该功能？
它是这样工作的。
人们采取行动。我们构建软件来帮助他们采取行动
为了采取行动，一个人必须做出决定。我们构建软件来帮助他们做出决定。
为了做出决定采取行动，一个人需要信息。我们构建软件来收集和呈现信息。
每个特征都必须是一个动作、一个决定或信息。连接最好是直接的。不会导致决定或行动的信息甚至不是“很高兴拥有”——它是垃圾。
用户说了很多。他们做什么？他们做出什么决定？他们需要什么信息？
编辑
请注意，并非每个人都擅长描述用例。有些人没有远见，只会告诉你他们今天做了什么，而不了解他们如何创造商业（或个人）价值。他们可能并不真正知道他们应该做出什么样的决定，并且对他们需要的信息含糊其辞。
其他用户知道他们创造了什么价值，以及为什么，并且可以很好地讨论用例。他们可以设想创造价值的替代方式；他们可以为他们的行动阐明选项。决策没有很多替代实现（人们做出决策，而不是软件），所需的信息也没有太大变化。
如果你是认真的，你可以在他们的工作中录下他们的视频，然后你分解他们想要完成的事情以及你的产品如何帮助他们。这是称为可用性工程的整个学科的一部分。Jakob Nielsen 的书可用性工程是对技术的一个很好的介绍。在他成为一个无耻的小贩之前，Jakob 是一位非常优秀的科学家，他学到了很多关于找出用户需求的廉价方法。如果你有预算的话特别好。最让我印象深刻的是使用纸质原型；这是模拟您尚未构建的软件的好方法，并有助于回答您关于下一步构建什么的问题。直到我看到这种技术的实际应用，我才相信它会有多么有效。
PS 如果您只是询问人们会发生什么情况的一个示例：对于 Microsoft Office 2007 的功能请求中有 90% 是针对 Microsoft Office 2003 中已经存在的功能。在这种情况下，用户需要的是更好的方法来查找已经存在的功能。我希望我能找到我在哪里读到这个......很抱歉没有参考。
根据您的措辞，我假设您正在构建要销售的产品，而不是为特定客户构建要订购的东西。
在这种情况下，我会说您应该首先自己成为用户并以您想要的方式构建您需要的功能。随着产品的发展，您将需要其他用户的反馈，但这至少可以让您开始并打破鸡蛋-鸡蛋循环。
至于衡量功能的实际使用情况，您可以建立一个讨论论坛来获得有关您添加的功能的反馈……如果您时间紧迫，您不需要太复杂的东西。
我个人喜欢客户的不干涉方法。他们给你高水平的要求，你提供实施。您的软件团队/公司/部门应该是专家。当然你会犯一些错误，如果它很糟糕，客户会提出来并且你会修复它，但通常让你和你的开发人员来解决它是一个有趣的困境。
研究，研究，研究。向其他设计学习，然后制作自己的超棒设计。不容易，但话说回来，他们不会无缘无故地向开发人员支付大笔费用。
这是个好问题。
如果你正在构建一个 FPS 游戏，你真的需要自己知道应该包含哪些内容，因为 99% 的用户永远不会联系你说“我希望你的游戏只有 X”。经验丰富的 beta 测试团队可以在这里提供帮助。
如果您正在编写一个会计应用程序，您需要了解行业以及用户在使用您的产品时试图完成什么，并尝试将您的功能集集中在这些目标上。
如果您正在为一个企业中的 100 个用户编写自定义应用程序，您可以与该软件的十几个最狂热的用户聊天。他们从头到尾了解所有表单，发现了所有未记录的快捷键，并且还弄清楚了如何规避您的许多数据验证规则。
想象你是他们
基于以下原则：
这似乎是一个先有鸡还是先有蛋的问题。很像计算 PageRank。页面的页面排名取决于链接到该页面的其他页面的 PageRank。计算 PageRank 的一种方法是迭代。
迭代是关键！
A. 投票
收集所有用户想要的功能的大列表（让他们列举他们想要的每个功能）。
然后让他们查看列表并允许他们对功能进行投票。比如说，给他们 100 分来分配特征。他们可以给一个功能超过 1 分。
B. 分析
分析商业模式，列出你认为需要的功能。这是必需的，因为：
C. 实施
从 A 和 B 分析列表，合并，删除一些，改进一些。实施。
D. 测试
对用户进行测试。听听他们的抱怨。看看 - 他们经常使用的功能 - 他们卡住的东西 - 等等等等
E. 迭代
通常，用户并不总是知道他们想要什么以及他们是否想要任何东西。在我们公司，销售人员会去找现有的和潜在的客户，向他们展示我们的产品，并解释他们为什么迫切需要这样的产品。
在我上大学的时候，我们被教导了一种叫做“userp-driven development”的东西。在这里，你真的必须去拜访客户，观察那里的人们是如何工作的，他们使用什么工具，并试图找出什么可以促进他们的生活。然后您创建一个模型，再次访问客户，将其展示给用户，获得他们的反馈，然后继续改进您的模型。当每个人或多或少都同意行动方案时，你就会执行，定期向客户展示你试图尽早获得更正反馈的内容。
重要的是不要与想要该产品的经理交谈，而是与将使用该产品的用户交谈。否则整部戏什么都不会带给你。
PS直接问他们“你想要什么？” 可能是一个危险的问题... 巴比伦 5 - 你想要什么？
它被称为市场研究。
不，这不是在挖那个家伙，这就是它的真正意义所在。当然，UCD 人员在该领域使用大量技术来获取用户需求，但它们与市场研究人员使用的工具完全相同。卡片分类、优先级列表等都是市场研究术语。