B端创新产品探索中的关键问题总结
副标题：最小可行产品(MVP)验证过程
作者：韩竹琴 原创于：2017-01-18
根据精益设计方法，做新品前期会建立几个不同的假设，描述用户可能存在的痛点及现状等。根据假设，对用户痛点的分析，制作最小可行产品，验证用户是否真的存在假设的痛，产品能否解决用户的痛点。
对于我们目前做的B端产品，接触用户的机会是其工作时间，且用户为其单位的管理层。我们选则到用户现场，面对面交流。这可能是一个相对较长时间的交流，并不是一次访谈就能完成的。有几个问题是比较关键，也是在走过的纠结痛苦中分析出来的。
- 在验证前期提的假设哪个方向更靠谱时，不同的用户表现结果出现分散不一致的情况怎么办？
- 我们的设计与验证方法是我们的事，需要跟用户讲吗？
- 前期确定了一个痛点方向，在进行最小可行产品设计与验证阶段，还需要再次确认用户的痛点吗？
- 在不断修改最小可行产品并与用户碰撞交流过程中会得到很多信息，我们该关注什么，信息该怎么总结分析？
问题1：在验证前期提的假设哪个方向更靠谱时，不同的用户表现结果出现分散不一致的情况怎么办？
前期提出了几个假设方向，每个方向设计了简单的1~2个界面，拿着这些去客户现场拜访用户，希望能验证用户在哪个方向上存在痛点，哪个假设是靠谱的，选择一个，值得做下去。但我们拜访了7个左右用户后发现，不同用户表现出不一致的倾向，没有一个假设需求是大部分用户都觉得最认可的，这个时候我们在想，可能是用户量不够，应该还需要量的验证。于是我们计划了做问卷调查，通过几个维度调查用户的需求痛点方向，哪个方向是大部分人都存在的。问卷大部分都是网络形式填写，实施的效果并不理想。为了验证用户填写问卷的有效性及了解更多信息，让用户填写了联系方式，通过电话回访的形式与用户交流，发现看起来比较正常的问卷结果，也有随意填写的情况。
针对这个问题，咨询了一位资深的用研，这里应该考虑这样几个点：
1，网络问卷的方式不太适合调研相对较为复杂痛点需求
因为是调研需求痛点，问卷有很多文字说明，一般人填写这样的问卷都比较吃力，问卷的有效性难以保证，并且问卷的形式也很难让用户能清楚地理解我们所表达的内容。不过网络问卷是一种接触用户的渠道，进行网络问卷时可以让用户填写联系方式，在回访问卷有效性及更多信息时能使用，同时能筛选出一些用户，邀约进行深入访谈。
2，针对不同的假设需求方向，不同用户表现出不一致的结果时，应思考不一致的原因
这里可能存在三方面的原因要去思考：
（1）我们做的假设是否存在交集，是否是一个层面的假设？如果假设之间本身有包含关系或者有部分交集，用户进行选择时会有不一样的倾向。有时候从我们的角度看假设之间没有关系，但在用户工作的角度看，可能存在某些交集，我们要分析是否有把这些内容挖掘出来。
（2）是个体因素还是共性因素，我们找的用户是不是有不是我们的目标用户。不同的用户表现不一样，是因为不同的用户及其单位背景有个体的特殊性，还是都存在某些共性的特征。我们的假设是否有针对不同特征的用户，所拜访的用户是不是目标用户？这里就需要对拜访的用户进行特征分析，同时要深入分析不同用户表现不一致的原因，根据深入访谈的点进行分析，可能需要多次访谈去验证。
（3）是不是所有假设都不靠谱？这个是最糟糕的一种，也是经过上述及其他分析后最后判断的，需要多次验证和思考。
3，B端产品调研用户痛点是否一定要进行量的验证？
几个用户的行为表现及痛点挖掘，很难说服他人这个痛点就是值得去解决的点，沿着这个方向做下去的产品就是很多客户会买的，经常会被挑战：也只有几个人这样认为而已，达不到量的说明。
曾经也一直不清楚这个问题该如何解决，实际工作中，有时候没有那么多的时间与成本去做大量的调研。后来了解一些相关的分析，觉得有些道理：B端产品解决的是用户工作业务的问题，在工作单位相对稳定的情况下，同类型的单位内部工作业务逻辑较为相似，相比于C端产品用户更具体一致性，所以，在考虑成本的情况下，并不是一定要进行大规模用户的痛点调研。
但这时候需要我们对少数用户如8-10个用户进行深入的访谈，仔细观察用户行为思考方式，工作部门的特征，深入分析每个用户在场景中的痛点，需要进行多次交流。
问题2：我们的设计与验证方法是我们的事，需要跟用户讲吗？
对于管理者用户，一般对产品对问题都有一定的看法，较为强势，在产品探索阶段，我们采用精益设计方法，以最小可行产品去探索，如果不与用户交流清楚方法，很难让用户理解我们的做法，难以与我们达成一致的探索目标，使探索过程遇到阻碍。
在去客户现场前，我们根据团队内部的想法做了最小可行产品——低保原型。（无线建设的数据分析界面）在我们去用户现场前，已经有人帮我们与用户协定好，愿意参与我们的最小可行产品的验证与产品设计过程。我们到现场后，与用户开始交流我们接下来要做的事，叙述我们现在做的产品是为了解决什么问题。然而问题来了，用户不断地讲述了他对产品的设想，认为产品应该做成什么样，其描述的产品是一个特别庞大的产品，解决一个庞大的问题，而我们目前做的只是其中的一个小分支。所以，用户会说：“你们不要只想着做这个……”显然用户误以为我们做的最小产品就是最终的产品架构，所以不断给我们“画饼”，使交流受到阻碍，双方似乎不在一条线上。
后来，经过团队的分析，这次MVP探索的目标及方法，没有给用户讲清楚，错误地以为用户能理解我们的做法，实际上，这些做法是相对专业的设计思路，在没有交流的前提下，用户并不清楚，使双方在探索目标及方法上没法达成一致。告知用户这次MVP探索的目的及方法后，用户很自然地能够理解，并走到一条线上顺畅地交流。MVP的验证过程，是拿一个最小可行产品去验证，并不是一开始就做一个庞大的产品设计。
问题3：前期确定了一个痛点方向，在进行最小可行产品设计与验证阶段，还需要再次确认用户的痛点吗？
这个答案是肯定的！最小可行产品的验证过程是一个验证前期假设，验证痛点的过程。前期进行很多次访谈交流寻找痛点，但并没有真正拿成型的产品设计方案与客户交流，前期的痛点是方向性的，不具体的，也有可能是没有找对的痛点。
我们前期花费了较长时间探索用户的痛点，但我们的认识只是方向性的。为了让用户能深入场景，我们进行了申请预算的专家评审答辩会。用户也渐渐默认了我们的想法，这个产品在给他们做资源申请汇报的时候有用。但真的就只是我们所想的那个痛点吗？具体是什么环节痛？哪些节点痛？这个似乎在刚开始MVP探索过程中没有好好洞察与分析。让用户参与设计，与用户交流是个较为长的过程，用户参与度高了后，可能会渐渐迷失自己，被我们强加的想法所禁锢，最后以设计的角度来说明问题。
在这个时候遇到一个心理负担，会觉得是前期工作做的不到位，但是实际工作中，特别是第一次开始做新品探索，难免有做不好的时候，很难一次就把握清楚用户的痛点，具体是哪个环节痛。所以，在后续的探索工作中一定要不断持续进行洞察分析，验证前期的假设，并且对用户痛点进行深入细节的探索。MVP探索过程是与用户一起相处时间最长的时候，拿实际的设计方案交流，比只拜访交流一次能得到更多有实际意义的信息。
探索过程中不去进一步洞察分析用户痛点，也会使后期的原型设计难以定稿。原型设计修改很多次，每次都说定稿了，再次拿出来审查的时候，又发现有问题，在后续分析过程中发现，用户的痛点并不是我们想的那么一个点，还存在其他节点痛。这样会反复修改原型，也错失了与用户直接交流的最佳机会，再次找用户取确认原型设计会比较困难。（距离用户现场较远，远程交流效果较差。）
问题4：在不断修改最小可行产品并与用户碰撞交流过程中会得到很多信息，我们该关注什么，信息该怎么总结分析？
到客户现场后会多次与用户交流，这个期间会获取很多信息，我们希望得到两个答案:
- 我们设计的产品方案对用户来说是否有价值，价值多大；
- 我们设计的界面有什么问题，哪些地方需要改进。为了后期设计返工，希望能尽早给用户展示产品设计的界面及发现问题。但这个过程中，我们应该关注什么？
4.1 产品的价值判断，用购买欲望、价格及预期使用率来判断；详细了解用户痛苦节点
在上一个问题中也提到需要关注用户痛点，并且细化用户在哪些行为节点上痛，我们可以制作用户行为链条，标注出痛的节点。但这个痛有多痛，产品价值有多大？往往用户不会直接说出真实的看法来。这时候可以用购买意愿、价格意愿预期使用率来进行测试。
有时候用户说很好，但是愿意购买吗？我们出的价格能接受吗？这时候会发现用户可能会愿意购买但勉强，可能愿意购买但不愿意高价购买。但访谈并不是就此结束价值判断点，用户的意愿如果与我们预期不符，需要在这个矛盾点里寻找原因，用户在考虑的是什么，为什么不愿意以我们预期的价格购买？用户刚开始可能会说一些冠冕堂皇的理由，但需要跟用户一起来分析探讨，逐步挖掘出真正的原因。
还有一个是用户对产品预期的使用率，由于是B端产品，如果我们设定的用户认为这个产品会买但是是下属来用，这时候与我们之前的假设就不一致了，因为我们做这个产品是给管理者用的，不是给他的下属用的，这个过程中需要关注用户为什么会这样，用户平时的工作习惯是什么，平时与下属之间的沟通交流方式是什么，产品的哪些原因导致出现这样的情况。
4.2 关注用户行为特征，弱化产品设计点
之前的访谈中，当我们认为产品已经验证是有价值的后，我们会关注产品设计问题，然而，这个过程中，我把重心过多地放在了产品设计问题，而较少关注用户的行为习惯与痛点。这样带来的后果：1、问到了一个设计问题及建设，但团队内部设计遇到下一个问题时，又不清楚怎么做比较好，完全依赖用户；2、用户在访谈的时候给出的问题及建议，并不一定就是真正的问题及好的建议，有时候用户说的不一定是实际的问题，我们需要寻找用户的行为习惯及痛点（细节的麻烦点），与用户一起分析，对应再来看设计问题点。
案例：有次在用户那里待了2周时间与用户一起探讨设计问题，希望跟用户一起进行参与式设计，与用户不断交流产品设计，询问有什么问题，不断改进后最终达成一致，产品这样设计就可以了，但是回公司后，内部讨论时，还会发现很多问题，这时候并不知的用户是怎么想的，又在想，问问用户。但是用户哪会天天陪你做这些事？设计也不是用户的事，用户并不具备专业的设计能力，用户长期参与设计后，他也会变得不是“纯粹”的用户了。
这个过程中我们需要多关注用户的行为习惯、思维模式及具体的痛点，用户平时是怎么做的，具体遇到什么问题点，所以，在我们访谈完用户总结分析的时候，除了用户说的问题点外，更应该标注用户的行为习惯及在行为中遇到什么麻烦点，这样会对应用户所认为的产品问题点。用户行为习惯的描述应该是全面的，详细的，这样能给设计师一个画面丰富场景描述，遇到一个设计点能分析如何设计更好。
4.3 访谈结束后文档整理
每次访谈结束后，第一时间内整理好访谈的内容为文字，如果有相关成员没有参与，最好当天或者第二天跟所有相关成员讨论访谈的内容。这个过程主要是与大家同步用户信息及共同分析用户的行为与表述的问题，分析过后还会发现一些不明确的点，需要再继续访谈用户。
访谈过程中及时与相关人员交流问题点，能高效处理问题，为后期汇报、讨论、结果落地等，多次访谈结束后，需要整理为阅读性较强的文档。需要整理文档内容有：
- 用户操作行为链条及痛点标注
- 用户行为习惯思维方式特征及对应产品问题
- 购买意愿
- 使用产品意愿
在探索过程中遇到过很多问题点，当感觉前行艰难，与预期不一致的时候，一定要思考原因及解决办法。
头图素材来源：https://community.uservoice.com
UXRen社区力推用研入门课程（讲师：杨蓉）
【在线视频课】用研新人的成长捷径（5小时+）
B端架构先行，UML 里的边界概念在B 端是重点。不过终于有地方探讨这个子领域了
sunny的UML概念，我觉得其实就是B端看重的“业务导向”。在企业里面，很多时候是“事决定人”，而不是“人决定事”。
B端产品调研的重点应该是以前的模式而不是当下的诉求。
以前的模式和当下的诉求分别指什么？以前的模式在当下没有了？