Mikel
英文原文：How to avoid building products that fail
本文编译自 Medium， 作者 Rian van der Merwe 2005 年到 2009 年间曾就职于 eBay，现在在 Jive Software 担任产品设计主管。在这篇文章中，作者提出打造一款成功的产品，必须在产品开发的始终关注着“用户需求”、“商业需求”以及“技术需求”。
“如果我问人们他们想要什么，他们会说想要一批跑得更快的马。”这句话据说是福特汽车创始人亨利·福特的名言。人们经常引用它来支持那些未经用户测试的所谓的创新。这句话其实价值不大，因为福特可能压根没说过这句话，而且按照这种思维方式经营公司很可能会在市场上惨败。
我们应该认识到，把一个没有经过验证和测试的 idea 拿去执行是一件非常危险的事情。我们在理解某个问题之前，不应该直接跳到解决方案部分。而这也将是本文所要讨论的。
开发一款产品出发点永远是需求。我们不能想当然的认为某个产品会很好，只有真正满足用户的需求并在商业上获得回报的产品才能取得成功。我认为开发产品的过程应该在以下几部分给予更多投入，我们在本文也将详细讨论这 3 方面需求：
- 用户需求。我们必须很好地理解市场，理解公司的消费者（包括现有的和潜在的），了解他们的行为和态度。我们在产品目标受众研究方面不应留有死角。
- 商业需求。“用户至上”的口号经常掩盖了一个事实，那就是产品存在的意义是为了赚钱。但商业方面的需求也不能成为糟糕设计的借口。
- 技术需求。人们常常过于重视更直接的前端和商业需求，而忽视了技术需求。开发人员知道产品的局限，他们知道有哪些问题需要解决，也知道技术方面什么欠缺需要补上。
产品开发中容易犯的最大一个错误就是在完成合理的产品规划前开始执行。所以，我们需要给规划环节足够的重视。首先，我们来谈谈收集用户需求。
用户需求
我们首先要区分清楚两个概念：需求和功能。人们经常错将产品功能等同于用户需求。来看一些家电行业的例子，你就知道为什么我这么说：洗衣机上的 预置模式可能有很多种，但是你常用的是不是只有一两种？用面包机时你需要几种烤面包的方式？这两个例子说明产品的功能并不等同于为用户创造的价值，多并不 意味着好。我们不需要更多的模式来洗衣服，但我们可能需要快洗或者更安静洗衣方式。
当产品设计得过于复杂的时候，我们就得自己想办法解决问题了。（图片来自 Reddit）
Facebook Home 面世后不久，相关评论和使用统计数据就开始出现，John Gruber 说了一句让我印象深刻的话：“它的设计精良，但是没有人想要这个创意。“他的这句话有夸张的成分，但是也说明了如果把功能（首页信息流、朋友充满屏幕、 Chat Heads 功能、app 启动器···）等同于需求（人们为什么会愿意把他们手机的操作系统换成一个 app）的后果。功能和需求之间的差异是非常重要的，有时又很难发现，这时就应该进行用户调研。
收集用户需求的调研主要依靠观察和分析，而不只是收集一堆预先设置好问题的答案。但是探讨优化产品的各种方法之前，我们需要定义一些基本研究内容。
首先，我们需要区分定量研究和定性研究。在定量研究中，数据往往不直接收集自受访者，而是通过调查问卷或网页分析收集。定量分析能帮助你理解发 生了什么情况，或者在多大程度上出现了这种情况。而定性分析数据直接从参与者处收集，通常以访谈或者可用性测试的方式进行。定性分析可以帮助你理解某些特 定的行为会怎样出现，以及为什么会出现。
其次，我们还需要区分市场调研和用户调研。二者都非常重要，但他们的目的不同。市场调研是要了解市场上整体的需求，主要关注品牌价值和市场定位 等问题。态度调查问卷以及焦点小组访谈是市场调研人员通常使用的基本方法，用于搞清楚如何在市场中定位产品。调查问卷和焦点小组访谈在理解市场趋势和需求 的时非常有用，但在产品设计方面用处不大。
另一方面，用户调研的关注点则在于用户如何与你的产品互动，关乎到人们如何使用新技术，以及从他们缺少的，需要的以及感到沮丧的地方我们能了解到什么。在这部分，我们将主要关注用户调研的方法。
那么，基于上述定义，我们来看一些最常用的用户调研方法。大体上分成三类：
1. 探索性调研（Exploratory Research）
当我们的目标是发现用户使用产品最重要（通常是未被满足的）的需求时，探索性调研非常有效的。探索性调研包括情境访谈（也叫做“民族志研究法” 或“实地访问”）、参与式设计会议以及产品概念测试（concept testing）。这么做的目的是发现现有产品在解决用户需求时所出现的不足。新产品或功能的创意常常出自这些会议。
不要搞错，这种方法并不是问人们是不是想要“更快的马”，而是观察人们，发现他们在哪些方面需要比现在做得更好。
举个例子，我们曾对世界各地许多 eBay 卖家做过实地访问。通过走进人们的家中，观察他们如何管理销售，我们发现了一个通过网页分析或问卷调查绝对不可能发现的问题。每个卖家管理店铺的方式都不 同，有些人在显示器周边贴满便利贴，还有些人使用带有复杂公式的 Excel 表格。卖家不得不自己完成一些本该由 eBay 做的事：如何记录销售过程并做出分析得到结论。通过实地走访，我们发现了一些还没有满足的用户需求，并通过多种方式解决了这些问题。而需求是这一切的出发 点。
2. 设计研究（Design Research）
设计研究帮助开发者利用需求分析得出的结论进一步改进产品创意。具体方法包括传统的可用性测试、RITE 测试（rapid iterative testing and evaluation，快速迭代测试与评估），甚至包括眼动记录等定量的方法。这类研究在设计产品，解决用户需求过程中作用十分明显。举个例子，我们可以 先开发一个交互式的原型机，然后把人们带到可用性测试实验室，给他们一些任务让他们在原型机上完成，通过这种方式我们可以在进入代价高昂的开发环节之前发 现一些可用性方面的问题。通过深入的一对一访谈，我们有很多机会深入了解自己是否很好地满足了在探索性调研中发现用户需求。
3. 评估研究（Assessment Research）
评估研究帮助我们验证对产品所做的改变是真正提升了产品，还是只做了无用功。这类研究常常被忽视，但它是产品开发过程中非常重要的一环。我们可 以通过调查问卷和网页分析了解随着时间推进产品的表现如何。这里需要关注的不仅是一些硬指标上的变化，还要看用户态度上的转变。只有将评估研究和设计研究 深入地结合起来，才能更好地理解我们为什么会看到产品发生的变化。比如说，表格分析可以看出人们在哪里放弃填写一份表格。每当我们改进一次表格的可用性， 就需要了解这些改变对表格的完成度有什么影响。没有评估研究，我们就没办法知道产品是否对了方向。
商业需求
在互联网行业，我们见过很多充分满足用户需求但没法赚钱、没法持续发展的公司。在过去几年，很多优秀的网络服务关停就是因为缺少收入。比如 Editorially 是一款出色的协同写作和编辑工具，但它的创始人却发现：“即使所有的用户都付费也不够。”
在 Editorially 之前，照片管理服务 Everpix 也关门大吉了。部分原因就在于他们无力支付云储存费用。虽然 Everpix 平台上有大量付费用户，但仍然入不敷出。创始人后来承认，虽然公司开发出了人们真正喜爱的产品，但是团队在产品上花费得时间过多，没有留出足够的时间去关注公司的发展和产品的推广。
现在很多互联网产品都希望先获得尽可能多的用户，然后再考虑赚钱的事情。但是在我看来，这种并不是做生意的方式。我并不是说一款新产品需要从第一天开始就盈利（当然能做到更好），但是至少你要规划好能够带来稳定收入的业务模式，在做商业计划时明确公司未来的收入来源。
那么，公司应该如何获得收入呢？大多数情况下，我们需要依赖消费者。在“用户需求”的部分，我们讨论过一些调研方法可以帮助你判断用户是否愿意付费，以及愿意支付多少费用。开发产品的过程中，需要联合公司内的业务拓展团队、销售团队、营销团队以及工程团队，做好两方面工作：放弃不良收入，追求优质收入。
放弃不良收入
一位古希腊作家曾说过：“收益总是甜美的，即使它来自与欺骗。”（Profit is sweet, even if it comes from deception.）这句话揭露了我们在金钱面前是多么的脆弱。通过欺骗的手段赚钱有时看起来很诱人，但这种短视行为在长期来看会带来巨大的问题，而且 会让你背负沉重的道德包袱。
在界面设计中，我们把一些欺骗性的技术手段称作“黑暗模式”（Dark Patterns），也就是通过诱导性的界面，让用户做一些正常情况下不会做的事情。在 darkpatterns.org 这个网站上，我们可以看到这样的案例：
- 会说话的汤姆猫等一些针对儿童的 iOS 应用中会随机弹出一些页面，诱导儿童购买一些内购项目。
- 登陆 PayPal 时经常会看到全屏广告，只在右上角有一个小小的按钮能关闭广告继续账户操作。
- Zynga 出品的农场类游戏 FarmVille 在开发时只有一个目标，那就是迫使用户尽可能长时间的照料他们的虚拟土地。
- Ryanair 把取消购买保险的选项放在一个无关的下拉菜单中，所以很多人根本没有意识到自己买了保险。
Ryanair 网站上如何取消购买保险。（来源：Dark Patterns）
很明显，有一些收入是不道德的，因此也不值得追求。问题在于，这些方法常常是能赚到钱的（至少在短期内）。但是其长期的效应也不容忽视，一旦用 户搞明白发生了什么，他们就会开始抱怨。这些不光彩的手段会直接影响到公司的声誉，同时也会增加客服费用。Ryanair 那样保险销售的阴谋已经成为“黑暗模式”的典型反面教材。
当然，大多数人内心深处并不想通过欺骗的手段挣钱，但是“黑暗模式”可能会潜移默化地侵蚀了我们原本正常的想法，直到彻底改变它们。
对于“黑暗模式”，我们不需要花费太多心思去斗争，只需要提醒自己：小心，不要掉进这个陷阱。每当遇到能增加收入的机会时就问问自己：“如果一 个产品让我这么操作或者让我付费时我会接受吗？”如果答案是否定的，那就放弃这个念头，还会有更好的方法。虽然有时找到合适的盈利模式比较困难，但是牺牲 短期利益来换取用户的长期忠诚才更有价值，你也会过得更加问心无愧。
还有另外一种情况，一条收入线在起初是良性的，但是随着外部环境的变化逐渐变成了一笔不良收入。如果这笔收入已经成为你的一项重要收入来源，那你就需要十分小心谨慎了。
这方面的一个案例就是 eBay 搜索结果中的图片。1995 年 eBay 创办时，存储是非常昂贵的。所以当用户在商品列表中上传图片时收取一定的费用是合理的。10 年过后，到了 2005 年，存储已经变得非常便宜，上传照片要收费这种做法看起来十分荒谬。但是图片上传已经成为 eBay 的一笔可观的收入，要放弃这笔钱，把图片上传免费，着实是一个非常艰难的决定。
我们的用户体验团队和分析团队通过研究发现，在搜索结果中默认显示图片不仅能增加销量，而且对于搜索结果有用性的评分也有积极作用。最终，eBay 决定放弃这笔不良收入，把图片上传免费（最多 8 张），而且后来也没有再改回去过。
眼动追踪数据显示出图片展示对于搜索结果的重要性
在产品开发过程中如果涉及到一些不良收入时，最好的做法就是进行调研，理解用户的需求和动机，结合 A/B 测试来衡量不良收入对优质收入所带来的影响。
追求优质收入
优质收入可以来自许多不同的渠道。对于消费者来说，只要产品的价值是显而易见的，他们就有付费的意愿。因此，在整个产品管理的过程中，需要首先明确产品的价值，然后再开发产品并开展相关的业务，不能先开发出产品再附加给它价值，用户需求研究永远是产品盈利的第一步。
对于一些已经存在的收入，有一些标准的增长方式，比如拓展到新地区，建立新渠道，延伸到更广阔的市场，为已经现有市场开发新产品等。在 Brandon Schauer 所写的《Adaptive Path》一书，还提出了一种新的收入增长理念，称为 Long Wow。原书中对 Long Wow 的定义如下：
Long Wow 意味着通过一次又一次地满足顾客来获得他们长期的忠诚。Long Wow 不仅仅是衡量忠诚度标准，更是通过以用户体验为核心的方式来培养和创造忠诚度。
Long wow 由以下四个步骤组成：
1. 了解与用户沟通的平台。明确线上和线下与用户接触的不同方式。
2. 满足用户尚未被满足的需求。在用户需求研究的基础上，认清哪些重要的用户需求还没有被你的产品或者任何一款现有产品所满足。
3. 创造并发展一套可重复的流程。将公司现有的优势和新的创意结合起来，不断满足消费者需求，取悦用户。
4. 做好计划，呈现惊艳的用户体验。随着时间的推进，改进你的 idea。在产品整个生命周期中不引入新的、更好的用户体验。
然后，根据情况不断重复这个过程。通过这种方式，你可以衡量产品是否带来了优质的收入，而且能确保为用户持续提供价值，培养更多愿意付费的忠诚客户。
技术需求
在讨论技术需求之前，需要先明确两个概念：“技术资产”和”技术负债“。 所谓“技术资产”就是产品所依赖的底层技术以及一些日常办公所用的系统（采购、财务、后勤）。相反，“技术负债”指的是限制产品开发的系统和代码（经常以 bug 的形式出现），技术负债如果长期得不到缓解会带来更加严重的问题。Construx 公司的首席软件工程师 Steve McConnell 认为，技术负债主要可以分为两类：
- 无意的负债(unintentional debt)会出现在错误设计被实施时或者程序员写出了差劲的代码时。这种负债并不是刻意的，当然越少越好。
- 有意的负债(intentional debt)是指公司明知道某种情况并不理想，但是出于种种原因还是做出了妥协（通常是由于预算或时间限制）。尽管这类技术负债也并不是件好事，但是对任何组织来说，它都是不可避免的，我们需要做的就是将其影响最小化。
对于技术负债来说，我们需要尽可能地减少负面影响，不然就会遇到我们常说的“破窗效应”。
“破窗效应”是犯罪心理学中的术语。用来解释城市中秩序混乱和破坏公物的行为，其含义是：
城市管理中需要保持各种设施处于良好的状态，并随时监控，这样才能阻止进一步的公物破坏甚至升级成更严重的暴力犯罪。
我们可以把软件比作城市的环境。如果有几扇窗户破了（软件中出现一些糟糕的代码），而破窗又没有尽快修好，那么很有可能会出现更多破碎的窗户 （人们变得不再关心优质代码），继而环境进一步恶化：垃圾到处出现，擅自占用空房的人越来越多（代码标准普遍下降）。不久之后，所有的窗户都会破碎。
如果负债扩大到一定程度，公司最终花费在弥补这些漏洞上精力会比用在创造新价值上的还要多。常见的情况就是遗留的代码库往往需要耗费大量的精力去维护（也就是“还债”），留给开发系统新功能的时间就变少了。——Steve McConnell
在产品开发时需要竭尽全力去避免此类技术负债。如果遇到了，找时间来处理这些欠账的过程会非常艰难，经常看不到任何改变，团队内会有一些人不理 解这么做的原因，很多人懒得去清理代码中的这些垃圾。然而，在开发过程中清理这些技术负债恰恰是一项非常重要的工作，如果做不好很可能会摧毁整个体系。
当然，需要注意的是，技术负债并不一定都是坏事，有时技术负债会催生一些强大的功能。总得来说，新出现的负债是没问题的，但是长期累积起来的旧账就不好了。Henrik Kniberg 在他所写的《Good and Bad Technical Debt》 一文中曾提出一个避免技术负债失控的好方法，那就是引入了债务上限的概念，当你的负债达到一定限额时需要采取措施以避免进一步失控：
当债务达到上限时，我们就宣布进入“负债紧急状态”，停止开发新项目，所有人都将注意力放在清理旧代码中的问题，直到回归到基准线。
理论上在每个开发周期中你都会遇到技术负债，但是当负债达到上限时，就需要及时调整，以免事态恶化。
权衡三方面需求
收集用户需求、商业需求和技术需求只是产品开发中一部分工作，更重要的是如何处理这些信息，平衡三方面需求。这时我们应该主要考虑以下三个要素：
- 产品在生命周期中所处的阶段。这是一款全新的产品，还是已经问世一段时间的产品？
- 用户获取情况。你们在努力吸引用户的阶段，还是用户会自己找上门来使用你们的产品？
- 公司的财务状况。你们是在想方设法挣钱的阶段，还是已经有了稳定的收入？
这三个要素的组合不同，你关注的重点应该也不一样。如果是一款正在努力获取用户的新产品，那么你就需要十分关注用户需求；如果公司在寻求大规模良性的增长，那你就需要把重点放在盈利上。
最后，需要强调的是：如果不理解产品的核心用户的需求以及商业上、技术上的需求，那你的产品就是建立在虚无之上的。一款产品可能在一段时间如日 中天，但最终肯定会有新的产品出现。所以不要把你的产品建立在危险的假设之上，开发产品时做到深思熟虑，努力开发出可持续的产品。
