本文包括人与人沟通、机器与机器沟通都要实现确定性；人机交互要实现确定性；通过系统能力为平台人机交互提供确定性；三个应用场景加深理解；保险产品的确定性比任何产品都重要五部分。
以下是正文：
我们开始分享平台设计的用户体验部分，这个是平台建设中，平台的用户体验，是企业全链路精准用户体验管理的子集，平台用户体验，更偏向于互联网产品的体验设计。在没有进入到全链路深度数字化的阶段时，用户体验部分主要包括确定性，用户体验的五个层级，用户故事，WorkShop工作坊、用户体验地图，设计蓝图，平台用户激励系统七部分。
平台产品设计的核心交互，提供的服务，各种产品功能，都要给用户交付确定性。
确定性有多重要呢？可以说人类的几乎所有行为的最终目的都是为了获取确定性，确定的结果，确定的满足等等。例如：女人追求安全感，是对确定性的需求；男人追求事业，是对确定性的需求；人不顾痛苦努力学习是为了给未来一份确定性；每天早起晚归加班熬夜是为了一个月确定的工钱；买保险是为了应对不确定性等等。
人，是最害怕，最逃避不确定性的生物之一，因此，互联网平台的设计，满足人对确定性的需求就是平台的基本诉求。
整篇文章包括人与人沟通、机器与机器沟通都要实现确定性；人机交互要实现确定性；通过系统能力为平台人机交互提供确定性；三个应用场景加深理解；保险产品的确定性比任何产品都重要五部分。
01 机器与机器沟通、人与人的沟通，要达到确定的沟通目的
了解计算机网络的人都知道，计算机的通信永远要得到对方一个确认的信息，才算完成，而不是说发出信息就完事了。这种看似降低一点通讯效率的处理方式，却使得计算机之间的通信非常的可靠。
但是，人与人之间的沟通，通常不是计算机网络通信这样的，一般的场景是说话的人把话说完，就以为完成了通信，大多数情况下是不需要理会对方是否真的接受了表达者传递的信息，并且理解了信息所包含的意义。另外，由于潜意识的存在，听者也不愿意过渡跟踪反馈，从而产生很大的问题。这就是无反馈即是地狱的来源（无反馈即是地狱，反馈本是人沟通的一种形式，而沟通从本质上来说就是信息的传递，无论是开会、聊天、演讲、讨论，我们无时无刻不在向身边的人传达着信息。后面会有详细的篇章进行介绍。）没有反馈就是没有确定沟通结果。
解决上述问题的办法一般有两种：
（1）有效沟通
在沟通的时候，要确认对方是否真的听懂并接受了沟通的内容，要让对方提供确定的反馈。
（2）共情
施展老师在他的《枢纽》一书中提到了外交家顾维钧先生，顾维钧是中国近代历史上最伟大的外交家之一，非常懂得如何与西方打交道，他曾是中国派出参加巴黎和会的代表，和会上就山东问题据理力争，曾说过一句轰动西方的话，“中国的孔子有如西方的耶稣，中国不能失去山东，正如西方不能失去耶路撒冷。”
西方人一直把耶稣的出生地耶路撒冷作为圣地，并且上千年了一直要夺回那个地方。山东是孔子的出生地，它在中国人心中的地位就相当于耶路撒冷在西方人心中的地位。他短短的几句话，就把意思说明白了。对方能听懂，不是因为对山东和孔子有多么熟悉，而是因为熟知耶路撒冷和耶稣。这就是沟通中，共情的能力。
实际上，无论有效沟通或者利用共情能力，都并不是一件简单的事情。与人沟通，切忌啰唆。很多人认为，自己讲的越多，对方接收的信息也越多。
1957年，大家对半导体没有什么了解。罗伯特·诺伊斯要说服谢尔曼·费尔柴尔德投资他们 8 个人（硅谷著名的8叛徒）做半导体，虽然费尔柴尔德自己也算是一个科技行业的老兵， 但是要理解导体和半导体的差别、半导体做的晶体管有什么用途， 还是相当困难的。诺伊斯要想说服他，就需要用一番简短的，费尔柴尔德一听就懂的话来说明。
诺伊斯是这样说的：
这些本质上是沙子和金属导线的基本物质将使未来晶体管材料的成本趋近于零，于是竞争将转向制造工艺。如果费尔柴尔德投资，你将赢得这场竞争。届时，廉价的晶体管将使消费电子产品的成本急剧下降，以至于制造它们比修理它们更便宜。
诺伊斯几句话就道出了即将来到的信息时代的商业特点——值钱的不是材料，而是上面的知识附加值。费尔柴尔德显然听懂了诺伊斯的话，并决定给诺伊斯等 8 个年轻人投资。后来费尔柴尔德回忆自己愿意在62岁的“高龄”做风险投资时说，他是被诺伊斯描述的晶体管的前景打动了。
综合上面两个例子，我们还可以得到一个新的结论，就是说话要看对象。同样的道理，对不同的人说，要用不同的说法。
这就是现实世界中，机器与机器，人与人的交互中，如果要高效的协作，实现彼此的目的，确定的沟通结果必不可少。同样，放在平台产品的设计上，也是同一个道理，只不过交互的对象从之前的机器与机器，人与人之间，变成了人与机器之间的交互。
02 平台设计要给人在人机交互中提供确定性的服务，而不是冰冷的产品
1. 产品思维还是服务思维？
保险公司生产保险产品，并提供保单管理，但是用户需要保险或者保单吗？
其实用户不需要保险，也不需要保单，用户需要的是当风险发生时，自己有能力对冲风险，给未来的生活提供确定的保障，说白了，用户需要的是风险管理服务，请记住，是服务不是产品。
在做平台产品设计的时候，如果我们定义自己不是做产品，而是做服务的话，上面的逻辑就会变成：我需要提供怎样的一种服务让用户有能力对冲风险？
那至少有几种可选方案：
设计不同类型的保险产品，然后卖个用户，当风险发生时，用户理赔，这是典型的传统保险。
针对同一类风险需求的用户，将它们聚集起来，通过风险共但机制，平台进行规则制定、风险防范、风险救助等，这是典型的互助模式，也是保险最早期的形态。
针对不同的用户，开发不同风险管理手段，例如健康风险管理的用户，主要介入用户健康状况的管理，同时提供急救、医疗等其它服务。
以用户得到风险管理服务为目的去提供服务，而不是想着仅仅通过生产保险，然后卖出去，这就是产品与服务的区别。
在平台设计的过程中，如果所有人都在聚焦搭建平台，都在谈产品，都在说卖保险，很容易进入以销售为核心，或者以产品经理为中心的误区，一味地幻想着做一个平台产品来改变世界。但是如果我们的出发点是提供一个服务，就会以用户获得和用户满足为中心来做设计。这两种方式的实现路径和最终目的，是完全不一样的。
2. ATM机提供的确定性
再给大家分享一个在互联网行业被用烂的例子：ATM机。
金融巨人沃尔克有一句名言是“这几十年银行创新唯一做对的是发明了ATM机”。我是非常赞同的。这也是为什么在保险行业平台设计的文章中，选择了ATM的例子。
ATM机提供的确定性就是验证ID之后给现金，围绕ATM机系统能力的设计和建设，所做的一切就是为了保证这个确定性。
简单的反向思考，一个ATM机，设计的非常漂亮，但是动不动就吐钞不正常，每次都吞卡，多扣款，你还会使用吗？
所以如果问ATM机有什么特点？怎么设计？如果按照保险公司传统的方式来设计，一定就会花过多的时间在ATM机的显性特性上。比如这个ATM机长什么样子，是长的还是宽的，界面是红的还是蓝的，是先出卡还是先出钞，等等。这些对吗？也不是全错，但是只是非常表面的一部分。
ATM机的核心服务是取钱。一台ATM机里要放20万的现金，如果一个银行提供100台ATM机的话，就意味着要把2000万的现金放到外面去。 就是说当你在提供核心服务的时候，也分流了企业的核心资源。ATM机是红的还是蓝的，这不是服务的本质，我们是需要回到服务本质来看的。
基于这个服务本质我们需要有几个流程：
（1）第一步，首先需要有一个战略判断，战略部门需要做出一个决策，为什么要提供这个服务？提供这个服务对于企业，对于用户的价值是什么？
这个时候ATM机有两个价值点：
第一个是放在营业网点的旁边，分流取钱的压力，我们看到所有银行的营业网点旁都会有ATM机。
第二个价值点是放在人流密集的地方，可以服务用户，增加企业的曝光，增强用户黏性，提高好感度。
（2）第二步，运营部门要对每一台ATM机有没有实现战略诉求来做价值评估。比如：钱放了很长时间都没有被取掉，那可能说明人流过少，这个点就应该拆撤。这个营业网点旁取现压力过大，一台ATM机不足，那就应该增加一台。
（3）第三步，在运营部门对每个点的战略价值做完数据分析和价值评估之后，需要哪个点存在，我就要保证它的服务可用。
为了保障服务可用，还要做哪些事呢？
最首要的肯定是现金，一台取不出钱的ATM机就是个铁盒子，是毫无意义的，就像无数个App都做得很漂亮，但用户真正需要一个漂亮的界面吗？
不需要。 用户需要的是即时满足，需要的是即时的确定性满足。 我要取现马上给我钱，有源源不断的钱，这个才是最重要的事情。
（4）第四步，维护ATM机还要做很多其他事，比如说硬件管理。 要保障ATM机不能经常死机，打印机要能打印凭条，还得有油墨、纸张，打印机的硬件不能坏掉。
（5）第五步，要有客服管理。 比如机器突然吞卡了，出钞有问题了，用户要投诉，这得有人处理。
所以ATM机是一个最简单的产品，因为它提供的确定性就是出钞。钱是最简单的产品，为什么呢？因为它没有用户区分，不管男女老幼，只要拿到钱，他就是满意的。
除了钱之外的任何一种商品，可能都是有用户区隔的。男性需求、女性需求、老人需求、孩子需求可能都不太一样。所以ATM机是不需要有用户区隔的，只需要能够保证确定性的供给，用户就会满意。
但即使是这样一个最简单的产品，你要能够保证服务，提供完整的系统能力需要七个岗位：战略、运营、现金、密码、硬件、客服、技术。
如果说每次取钱ATM机可以收两块钱，一台ATM机总体回收成本大概是10年，这就是整体的服务成本。这也是为什么很多公司死了，而一些看上去页面很粗糙，做得不怎么好看的网站和App依然有旺盛的生命力。因为稳定出钞，这个是最关键的。
如果你把过多的热情花在了诸如ATM机应该是什么形状的，是红的还是蓝的，可不可以再精美一点，这些显性特性的东西上，对于整体的业务效率和业务结果没什么影响。
所有这一切，从战略、ATM机器的设计、网点的布局、核心资源外置、运营、硬件、维护、客户管理等等，我们统称为银行的系统能力。
03 利用系统能力，给人提供确定性
前面说了，战略、运营、现金、密码、硬件、客服、技术等所有岗位的保障，才有了ATM机的稳定吐钞功能，这就银行的系统能力。
那么什么是系统能力呢？
我想吃西瓜，但是只有一包西瓜子、一盆泥土和不限量的水？怎么办？这就是西瓜藤的系统能力，你提供了水和泥土，西瓜藤就能利用阳光，稳定性的给你提供西瓜。同样，苹果树的系统能力就是利用水、泥土和阳光，确定的生产苹果。
保险公司设计一个平台产品的，从系统能力来讲，挑战也相当之大。关心微信发展史的人都应该知道，微信发布迟于小米的米聊，甚至一开始体量远小于米聊，但是微信2.0追上了米聊，并从此反超，后来的结局我们都知道，几乎全中国人都在用微信，但很少人知道米聊。
除了创始人的格局以外，决定微信超越米聊的另外一个原因是腾讯的系统能力，远高于小米。
张小龙在做微信之前，做了十年的腾讯邮箱，那是全国最大的邮箱服务平台。它有一个很强的功能是超大附件，要有强大的服务器功能保证，超大数据定点传输中负载均衡，系统不崩溃。微信的背后有数十万台服务器支撑微信的数据流量。这样的系统能力建设，对于腾讯这样的公司是天然的。
而创业初期的小米，根本不可能囤积那么多的设备去提升米聊的性能。所以两个前端体验基本一致的产品，你用微信，永远都会觉得很快，而米聊有时会慢、会卡，偶尔会系统崩溃。两个产品的区别在这里就开始拉开了。
回到保险公司平台设计上，定位平台的产品，用户服务量级至少要1亿起吧？
但是无论是像平安、国寿这样的大公司，还是像众安、泰康这样的新型保险公司，都不会囤积数十万计的服务器，仅仅日交易量超过十万，也是国内几乎所有核心系统都无法支撑得了的。如何支撑日活级别亿以上的用户流量，是保险公司平台建设之初要认真考虑的问题。
当然，几乎所有的流量巨头，都是后台能力不足，前端拉着后台跑，宕机重启，重启后再宕机，不断摸爬滚打，试错创新最后积累出来的。从这个角度讲，我们也无需过于担心后台的问题，但一定要重视服务的稳定性和确定性。
04 应用场景
假定前端带动后端的模式是成立的，我再通过介绍几个非常简单的前端场景，从小到大，加深对确定性的了解，分别是最简单的交互“点击”，所有产品都需要的支撑性功能“登录”和平台内容“服务”。
1. 点击要有反馈
无反馈即是地狱中（后面会有详细章节进行介绍）说到，好的产品是能和用户沟通的，沟通过程即是不断交互反馈的过程。在产品设计中，交互反馈号称是最难设计的，怎么做到实时、恰到好处、不漏、不过，核心就在一定要形成“交互反馈”。这个交互反馈就是确定性的一种。
几乎所有的软硬件，都是一个个大大小小的交互构成的，从用户目光转向手机那一刻开始，用户和手机的交互就开始了，然后拿起手机，设备通过faceID交互开机（一个确定性），点击我们的平台App（第二个确定性），就和我们的平台产生了一个交互。
用户点击的一瞬间，会有三种状态：
点击，App提供正确的反馈，打开了App；
点击，App提供了的反馈，例如置灰、模态提示等等，告诉用户当前App正在升级无法使用；
点击，App没有任何反应，再点击，还是没反应，长按，没反应，双击，也没反应……
前两种反馈状态，App提供了确定的交互反馈，告诉用户可以正常打开，或因为升级的原因，暂时无法操作，请等待。第三种状态，就是没有确定性反馈的典型。由于没有任何交互，用户不知道发生了什么，各种猜测带来的不确定感会瞬间放大用户对平台产品质量的怀疑，甚至于卸载掉App，要知道一旦卸载，再次安装几乎不可能。
同样的例子，在App打开后的每一步，都如是，产品反馈设计中一定要做到：
事前事中事后实时、合适的给以交互反馈。
形成反馈闭环优化反馈结果。反馈闭环是任何学习的前提条件。
切记反馈过度。我曾经看到过一个App在网络状态从WiFi切换到4G后，同时模态反馈超过了5次，每种交互方式还不一样，极其痛苦。这说明啥，产品设计团队没有正确的价值观，2C的产品，在价值观的设计上，客户永远是第一顺位的，这时候保障客户体验就是唯一的核心，其它的一切妥协（号称领导要求、安全需要等等）匆忙发版都是价值观的妥协。这种团队不可能长久！
2. 登录要有结果
第二个前端的小例子，是想拿登录注册来说。
登录注册有两种模式：
一种用户安装以后，系统根据设备IMEI码自动分配一个ID，用户无需注册，也可以流畅使用，代表产品就是今日头条。
第二类是用户必须通过注册才能使用，代表产品例如微信。其它各类产品都是出于这两种类型范畴之内，或结合、或加强提升门槛、或选其一。
第一类如今日头条这样登录注册的方式，因为提供的服务是资讯，资讯服务的本质是获取价值信息，并且可以无障碍阅读，除了这个，其它产品所有的功能都是次要的。因此怎么在不打扰用户的情况下，提供无差别、个性化、高效稳定的资讯阅读体验，是整个系统服务的核心。
第二类产品，就像微信这样，你必须通过手机号或者其它可以显性的区分你和他人的社会虚拟账号进行注册。因为微信提供的服务是基于通讯录的IM聊天，也就是，这个服务中必须满足两个硬性指标：稳定的IM聊天能力、像通讯录一样连接熟人的能力。前一个能力无需用户手动注册，但后一个能力，必须要通过为系统提交唯一身份识别的账户。
第一类注册方式下的登录，用户在App上浏览的行为、收藏、评论、点赞等等，都被系统默认的记录到系统自动分配的ID中，你下次登录，依然能找到之前所有的交互行为，这就是确定性，这不过这个确定性大多数是通过机器自动完成的。
第二类注册方式，微信要保障至少两个确定性，第一个是我通过手机号、QQ号注册以后，微信能确定的反馈给我系统中的好友，并且引导用户及时的进行添加。在一个社交平台上，当一个用户的好友数量超过7的时候，他离开这个平台的概率就会大大的降低。
第二个确定性是加了好友之后，好友与好友之间可以稳定快速的聊天，无论是文字、图片，还是后期迭代添加的语言、视频等等，如果系统隔三差五的丢包，好友莫名其妙的丢失，这样的产品，肯定是没有前途的。
那么，我们的保险公司的平台App更偏向于哪一类注册方式呢？
我觉得两个都像。如果你同时提供了像资讯、短视频、视频等这类信息服务，那么你的用户群的需求是快速、高效的内容消费，过于繁杂的注册系统，会过滤掉相当大的一部分人。但同时，作为保险公司App，肯定会有保险的销售和保单的管理，怎么让系统提供准确的保单信息给用户，那就不仅仅需要用户进行手机注册，还要进行身份信息的验证。
这是宏观的表述，我们再说微观方面。
我如果已经注册成功，平台依然强制退出，需要我再次登录，这种微观体验是否合适？
我已经成功登录，但是因为中途接了一个电话，五分钟后，平台把我强制退出，让我重新登录，美其名曰为了我账户的安全，这种微观体验是否合适？
我成功的在登录文本框输入了账号、密码，系统有提示我需要输入验证码，验证码的类型还是“5+8=？”，请问，这种微观体验是否合适？
我成功的在登录文本框输入了账号、密码，点击“确认”按钮以后，系统一直没有反馈，按钮状态也没有发生任何变化，请问，这种微观体验是否合适？
手机号输入逐字校验格式和用户点击确认后再校验格式，那种反馈更好？
每次登陆验证都要loading超过十多秒等等…
像上面这种，不重视微观体感的产品设计，市场上数不胜数。可能有人会问，前面ATM 的例子，不是说无需重视细节，要重视核心吗？
那我问你，你用ATM取款的时候，插卡的卡槽太小不好插入，银行卡放到卡槽门口总是推不进去，取款完备，卡片验证需要十分钟，退卡要等至少十几分钟，它是保障了核心功能的确定性，但是你是选择去银行排队取款还是ATM机？
3. 服务要有闭环
第三个小场景，我们说服务。服务一定要有闭环。什么意思，你去ATM取款，从插卡开始，输入密码（登录验证），选择服务，输入取款金额，取到钱，银行扣款，账户退出，拿回卡，这是一个完整的闭环服务。
确定性的另一个关键指标就是一定要是闭环。对应到保险公司平台设计上，我们以前面分享过的“智能在线问诊”服务为例说明。具体什么是智能在线问诊，请移步查看。
下图是智能问诊早期的方案原型，在线问诊服务，用户从首页入口进入，提交资料，AI病情分析、分配医生、在线问诊、评价/打赏和完善电子病历，这是一个闭环的服务。另外一条线路用户从首页入口进入，提交资料，AI病情分析、分配医生、在线问诊、引导挂号、挂号成功、线下就医、评价/打赏和完善电子病历。
这两个都是完毕的闭环服务，但在现实的操作中，因为不同人的习惯、产品设计、病情不同等等，会跳过其中一个或几个环节。但确定性的提供了问诊服务，解决了用户健康问题或疑问，这才是闭环。
相反的情况是什么？在线问诊没有导医导诊的功能，什么意思，全部由AI和人交互，没有专业的医生对接，也没有针对特殊病情引导用户挂号，进一步就诊，这样的服务，都是不完整的，也解决不了用户的实际需求，充其量只是浪费了企业的带宽、计算资源而已。
05 保险产品的确定性比任何产品都重要
最后稍微说一下保险，一个提供风险对冲的服务，用户对其确定性的需求，应该是所有类型的产品服务中，最高的。
就像银行存贷业务，保证本金的安全，这个确定性要求最高的，如果一旦储户听到银行无法保证本金安全，挤兑不可避免，此时存款保险制度非常重要。
用户购买保险的目的，是在风险发生时，可以获取风险对冲的确定性。但是，目前保险由于设计的过于复杂，导致确定性在用户心中逐步丧失，不确定性逐渐提高，这个对整个行业都是极具危害的。
最后，再次强调一遍，平台、平台的功能、平台的服务、保险产品等等，都要给用户提供确定性！
参考资料：
施展《枢纽》
梁宁《产品思维三十讲》
相关阅读
创新型服务“智能推荐” | 互联网平台建设（十二）
创新型服务“场景串接” | 互联网平台建设（十三）
保险需求的智能分析：智能保顾 | 互联网平台建设（十四）
平台的核心交互与基础角色 | 互联网平台建设系列（十六）
