产品一旦发布上线，其“归属权”往往就已经完成了转移，从产品的设计者转向了产品的使用者，即用户从某种意义上成为了产品的所有者，他们对产品的认知和定位、使用和体验、吐槽和赞赏决定了产品后续的生老病死、迭代升级。作为产品的“设计者”对于产品固然是有着清晰、严谨的版本计划的，但这些来自使用侧的反馈往往会冲破“严谨”的版本计划，“迫使”设计者低头，屈服。从这种意义上说，用户是产品的“敌人”，是产品本身的，也是产品经理的。
因为，用户并不总是按照我们产品设计的思路、流程、路径来使用产品
作为产品经理，包括负责用户运营的同学，对于这一点肯定不会陌生，在产品面向用户发布之后，不管是我们主动的正面进行用户访谈收集用户反馈，还是侧面通过数据埋点进行用户行为识别和分析的时候，都会发现这样或者那样的、超出我们“认知”的一些我们在产品设计之初并没有考虑到的，或者考虑到又“忽视”了的，或者考虑到但是因为种种原因并没有“落实”在产品功能或者设计上的问题，这些问题导致了用户在产品的使用上走向了一个岔道。就好比我们给房子修了一条路，但是路标没立好，我们的客人“跑偏了”。
这类问题的出现：一方面是因为我们在进行产品设计的时候并没有对可能使用产品的所有用户进行覆盖，“二八原则”要求我们一定会做取舍，这也是投产比、效率的要求；一方面是因为我们在进行产品设计的过程中不可避免的会有自然的“认知投射”，也就是会不由自主地默认一些信息、一些技能、一些常识是我们的用户已经具备的，不需要特殊关照和处理的（这也是所谓的“下一秒变小白”说法的由来）；再一个方面，是我们在产品设计的过程中，都会安排版本的计划，也就是产品进行迭代的规划，这种会缓解我们对于产品考虑可能不周详的焦虑，相应地也会让我们在进行产品设计的过程中“放松”把控。
因此，用户和产品之间的这种“冲突”在某种意义上是必然。既然是必然的，那我们就可以坦然的接受他，接下来的，就是一起来探讨一下如何尽可能的减少这种冲突。我们通过一个实际业务的案例来分享。
案例：某信贷金融产品的使用
这款产品是面向零售企业客户，特别是其中的小微企业、个体工商户、夫妻店的“账期类”的信用借款产品。零售企业通过向上游供货商进行商品的批量采购，再通过自己的客户辐射能力进行销售，通过销售价格和采购价格之间的价差获得收益。因此，在零售价格变动较小的情况下，适时、适价的采购决定了它的盈利能力，这款金融产品的价值即基于此。客户如果在进货时遇到资金周转困难，可申请短期借款，完成销售之后再进行还款。实现方式上，产品通过H5的方式嵌入到合作平台的APP中，向客户提供服务。
在整个产品上线运营的过程中，出现了一些相对典型的场景认知的不对称，从而引发一些“冲突”。其中：
场景一：KYC信息认证
场景描述：按照信贷产品的KYC要求，对于贷款的申请者，需要正确识别申请人的身份。作为纯线上的产品，对于身份的识别是借助于外部的大数据信息进行的，常见的包括：
1、通信运营商三要素：手机号码、所有人姓名、所有人身份证号码；
2、银行卡的四要素：银行卡号码、持卡人姓名、持卡人身份证号码、银行预留手机号码；
通常的认知里申请人通信运营商的三要素认证肯定是一致的，因为就常识来说，我们去移动、联通或者电信去办理号卡业务，都是需要验证我们的身份信息的，也就是说，我们开通一个手机号码、办理套餐等等都是需要我们提供身份证原件的，而且最近几年随着“活体识别”技术的普及，这个验证也开始广泛运用到这个业务办理的过程中。银行卡四要素的认证也是类似的逻辑，大家回想一下我们去银行办理业务的过程，开户、修改密码、柜台或者自助终端办理业务都是需要出示身份证信息以及进行短信验证码的验证的。正是基于这一点“常识”，在整个业务流程的设计中，产品界面的提示和引导并没有着重强调、提醒客户这个节点对于信息的要求，于是出现了很多校验不通过的情况，比如：老婆一直用的是老公的手机号码导致的通信运营商三要素校验不一致、因为银行卡办理的时间较久并没有预留手机号码而导致的银行卡四要素校验不一致、因为银行卡办理时预留的手机号码已经作废不用导致的银行卡四要素校验不一致等等；
如上所示，在产品设计的前端页面上，采用了相对模糊的提示文字，这种提示、引导严格意义上来说：没有任何提示价值，也就是默认了用户清楚产品的所指。然后这里要求的信息——手机号码本身是一个“开放”的概念，并不限定是本人的手机号，可以是随便一个联系手机号。正是因为默认了客户、申请人具有产品认为应该所有人、起码是目标客户人群应该具有的常识，双方应该是会在一种“默认的语境里交流”，会按照产品设计者的认知方式去使用产品，才导致了前面提到的误解。由于误解导致的信息校验失败，导致用户在流程的过程中最终也未能成功达到目的。另外，因为这个失败是个人信息校验的失败，从风险控制的逻辑来看，存在着第三方在未完全掌握他人信息的情况下，尝试“冒用”身份进行业务办理、“试探”和“攻击”风险控制的可能，进而对于校验不通过的用户再次办理的行为进行控制，最终导致客户没有办法及时的修正自己的“失误”，造成用户流失。
场景二：借据的展示
场景描述：产品向客户提供的是随借随还的借贷产品，也就是借款之后，用户根据自己的资金安排可以随时还款，按日计算利息；同时为了便于出借人自身做资金计划的安排，同时兼顾用户在日常经营方面的资金周转周期，设置了最长的单笔借款期限，也就是每笔借款都设定有一个最晚的还款日。
因此，在产品信息展示方面，为了避免客户错过最后的还款日导致逾期，以及避免“错位”还款（即先还了到期日更远而没有还到期日更近的借款），产品设计了待结清借款的清单，以瀑布页的方式提供信息展示。同时，在清单页面按照借款的先后时间顺序，也就是到期日由近及远的顺序对借款进行排列。这样，用户按照展示的顺序依次来进行还款就可以。对于完成借款的还款之后，结清的借据就会对应的变更状态，并记录到已结清的列表页面中。
用户终究是不会让我们“失望”的。在实际的产品使用过程中，用户在“待结清”的列表清单中按照自己的喜好做了选择，估计是对于某些金额有特别的偏好，或者是对于排序的某个序列位置有特别的偏好，不管是对于数字的迷信也好，或者是出于用户真实地资金周转的安排，只对金额较小的借款进行偿还；反正的结果就是：用户真的“错位”还款了，本应该先还款的借据逾期，产生了罚息。虽然产品本意并没有引导用户去“错位”还款，从而获得更多的利息甚至罚息，但最终的结果是由于产品缺乏更明确地提示和引导，或者对于用户行为的约束，才导致了这样的结果。产品“难辞其咎”。
场景三：转账还款的引导
场景描述：产品向客户提供了两种还款的方式，一种是系统自动执行的以最后还款日到期为触发条件的对客户绑定的银行卡的扣款；一种是客户主动的按照自己意愿发起的通过手机银行、网上银行或者网点柜台等渠道发起的对公转账来进行还款。产品面向客户的产品是在额度范围内的随借随还的产品，用户可以在自己获得的授信额度上限内进行多笔借款（类似借呗，或者信用卡的多次消费），因此对于同样一笔转账款项，系统在进行还款入账的时候就面临着一个难题：这笔转帐款到底是用来还哪一笔借款的呢？
如果按照借款发生的时间顺序依次还款，或者按照借款金额的大小顺序来依次执行还款，都有可能出现还款失败或者“目标”借款还款失败的情况。假设用户当前有两笔借款：
先借的一笔借款金额 200元，已经使用2天，相应需支付利息0.2元；
后借的一笔借款金额是 20,000元，已使用1天，相应需支付利息10元；
客户通过对公转账，转入资金 20,100元；
按照借款发生的时间顺序来进行还款的话，转入的资金会先偿还先借的一笔借款，即本金金额为200元的借款，应还款本息合计200.20元。这笔借款还款完成之后，剩余的金额＜20,000元，是没有办法把每日利息支出较多的一笔借款进行还款了，所导致的结果一方面是该笔借款持续计算应收利息，另一方面是有一笔资金未能还款却产生了“滞用”，这显然不是客户的意图。对此，在产品的设计过程中，对于转账还款的操作，提示了用户在完成转账还款操作后，再返回页面进行确认还款的操作，以便于系统清楚用户的意向，按照“用户意志”来执行还款。
即便在引导页面增加了提示文案和引导，因为转账的操作（需要通过手机银行或者网上银行进行）和还款的操作不是在一个“平台”上进行的，无法完成“环环相扣”的闭环控制。因此，还是有用户操作完转账之后就默认是已经进行了还款，并没有返回页面进行操作，“亏”了钱但是没有还款，导致的结果就是继续计算利息而且还“占用”了资金的流动性。与其他操作不同的，还款的操作是涉及到了钱，更会将体验的“差”在感受上成倍放大。
破解思路：多调研、聚流程、快迭代
上面所举的例子只是产品上线后所遇到的“差异化”使用的一部分。在实际的用户使用产品的过程中，一直都存在着这样或者那样的问题，前面我们也谈到那过，这些问题我们在一开始可能都是没有想到，或者是想到但是没有准备的，因此在心理上首先要承认这种事情一定会发生，是“自然”现象，不要因为这种事情的发生动摇自己是一个优秀“产品人”的信心，产品的路“道阻且长”。其次，在实际的产品工作中，设计务实中，还是会有一些方法可供参考：
1、尽可能的多发现，多调研，广覆盖。这是在进行产品设计“前段”，对于目标用户进行选择、设定后访谈的过程中，对于用户的使用习惯、思维方式、认知背景、目标诉求等等尽可能地多了解，多调研，更多角度、更详实地去了解用户，只有这样才有可能把自己当作用户，从用户的角度出发去设计产品，制定流程和交互，保证产品的可用和易用。
2、聚焦业务流程，包括了用户操作前的引导、操作中的反馈以及操作后的容错。其中：
操作前的引导一方面需要清楚所谓的“常识”等默认的背景知识，使用更明确、更直白、更接地气的语言，来说明需要的信息、期望的操作和预想的反馈；另一方面可以通过更直接的非文字的方式，以富媒体，包括：声音、图片甚至动画的方式，对于复杂的操作进行更直接、高效的引导；
最常见的操作中的反馈就是toast提示、弹窗提示，页面的跳转等，这些都是用户与页面，也就是产品发生交互时产品给出的基础应答样式，更为重要的是，产品可以通过“更深的层次”来参与反馈，也就是系统的业务逻辑。以前文我们提到的“KYC信息认证”的例子，我们可以在用户输入信息之后的当前页面“即时”进行消息的验证，而不是等到用户提交信息之后再进行验证，现在很多产品的登录密码校验的策略已经使用了这样的逻辑：对于密码格式的校验是根据输入的完成来实时处理的，而不需要用户点击“登录”按钮发起登录操作再进行校验。这样的操作中的反馈通过将校验规则前置，更好地照顾了用户的操作体验和产品的使用效率。
操作后的容错，指的是用户即便是按照了“错误”的理解来使用了我们的产品，产品同样还是会提供一条“回环”的路径让用户回到正确的使用方式上来，避免用户产生挫败、被拒绝、乃至被抛弃的负面感受。我们还是以前文我们提到的“KYC信息认证”来举例，我们在前文讨论的时候也提到了，出于风险的考虑和逻辑，对于“试探”和“攻击”可能风险的控制，产品设定了对于识别为“异常”的用户在限定时间内不可以再次进行申请的规则，称为“禁闭期”，对于触犯不同风险控制规则的用户行为也设定了不同的“禁闭期”，简单来说就是“风险行为低的禁闭期短，风险行为高的禁闭期长”。同样地，通过明确的引导提示和告知，被“拒绝”的用户可以在“禁闭期”结束之后再次进行业务办理，只要再次的产品使用符合要求而无需其他额外的操作。通过这样的容错机制，在控制风险的同时也为用户提供了“回环”的路径来完成产品使用的目的。
3、快速迭代，发现问题，及时分析，快速解决，用户和竞争对手的耐心都是有限的。不必等待完美的解决方案，解决问题是第一位的，更好的解决问题的方式方法是我们追求的，但永远不是第一位的，它只有可能会出现在我们充分积累之后下一次解决问题的时候。
结语
追求产品完美和优质用户体验的路上，没有终点。
