标签： 产品感悟

业务建构–>流程建设–>产品建构–>数字化实现（技术建构、IT建构），业务飞轮转起来之后，业务动作产生数据，业务的现状和约束也决定产品形态，激进的产品策略无疑是对用户和市场的 YY，削足适履之举更是令人贻笑大方。

用户的自我成长，你们省省心吧！

用户首先不是人，而是不同场景下的效用组合，我在下雨天不想开车、不想乘坐公共交通时候，这时网约车产品大概率是我的最优选择。我在想吃辣的，但又不想吃火锅那么大阵仗的时候，我可能是火锅串串店的的用户。

用户是不能被教育的，用户是自己随着约束和环境自我成长的，而不是被产品和技术教育的，产品、技术、市场、营销、政策等都可能成为是用户的外界约束和条件。这些共同决定了用户的行为演进和选择的变化，也就是我们口中的“教育用户”、“用户成长”。

过往产品实战中，偶然接触到团队大数据部门的一次奇葩想法，为了某个数据产品呈现在屏幕上的结果更加规整、更加具备所谓的“可用性”（希望数据刻意的去符合常识，比如一个时间周期指标通常结果是在“天”维度，如果突然出现一个超过月的特征数据，就被认为数据不太可用、不符合常规），而反向希望业务去刻意规避某种业务行为。这是不是太滑稽了！拿着业务的果，去动业务的因。如果没有因，根本也就看不到所谓的果，又何来去对因的要求。

且不说上面这个低级的逻辑谬误。

再来说，对于数据我们到底想要什么？

答案绝对不是让数据隐藏、剔除、过滤掉不应该舍弃的信息，这部分信息当然要区分，不排除有些是噪音数据，但是另外还有很大一部分正是真正重要的数据——也就是风险数据、离散数据，这让积累的数据具备“业务系统”的遍历性。就像50年、100年一遇的大雨、大雪、大风，你一定不会认为这部分数据应该剔除掉。

上面这些数据是对真实业务的反应，我们绝不应该规避这些数据。这些业务行为过去既然会发生，哪怕概率很小、很偶然，也不等于未来不发生。抛弃这些，未来谈数据支撑无疑是盲人摸象。

你们又会说，数据可以驱动业务优化啊！

数据是以特定视角，呈现业务结果。结果相关的复杂的关联因素集合，再加上数据分析部门本位上不能替代业务视角看待问题，非业务部门也很难和业务部门做到风险共担，不是一条绳上的蚂蚱，难免意识和想法、行为的分道扬镳。

那些一句“我为业务好”的人，不过是一句口嗨。如果有一个团队对业务、数据、策略都负责，比如：全能运营战士，情况也许会好上许多。数据呈现结果，组织发现问题/改善点，业务部门最终自己驱动业务优化。

为了数据治理而治理业务？豆腐脑儿吧！

数据洁癖催生数据优化，数据优化反向治理业务。这是最大的笑话！所谓的数据治理、技术治理，自然是聚焦在为服务业务发展的前提下，而非为了数据治理而治理业务。没有业务发展，当然用不上数据、技术，除非数据、技术本身就是经营上的“业务产品”，比如当下很多的大模型产品。如果不是，那业务发展需要到技术，技术支撑业务发展，此时业务就像“大脑”，全身的骨骼、肌肉都是可以被调配、组合的硬件/技术资源。大脑自然会因其指令不能得到实现，而催生意识的变化和调整，继而产生匹配的行为。

2023年还在上一个团队，当时有一个产品设计，大胆抄袭了企业微信，把它的日程待办搬了过来。

业务背景如下：

为了给采购人员提供工具支撑采购业务跟进，第一采购订单创建之后的审核、报出、确认，方便采购人员跟进自己负责订单的审核情况、报出情况、供应商回复确认情况，确保订单的有效及时报出。也清晰看到已经完成订单的占比情况；

第二是发货的跟进，关注迟迟待发货的订单、等待门店收货的发货单，可以及时催供应商发货、跟进门店收货，监控门店异常收货。

功能层面终于上了心心念念的日历看板，采购业务产品本身也有较强的时效性诉求，特别是如今零售流通行业对于供应链效率要求越来越高的时代。

曾经一度也在纠结满足这个业务诉求到底用一种什么呈现才好，那种带有巨强时间属性的产品（比如：机票、酒店这种严格分布在时间线上产品）放在日历的维度是天然成立的，因为用户有心理预期就是对于基于时间的需求（我要哪天住酒店，我要哪天飞，我要哪天出去旅游）。

而这次对于采购链路的跟单过程也采用日历看板模式，则是将原来的一维信息升维处理，需要用户大脑对于一维信息的处理过程，在经过简单的组装之后二维呈现在看板上，让用户获取信息时大脑减少思考过程，达到的结果就是让用户觉得自然的发生。用户的业务数据采集过程，完成了对于业务闭环的数据沉淀，然后自然的享受数据带来的价值，提升驾驭感，这个时候用户不再只是数据的投喂工角色、同时也是数据的驾驭者。

这次产品引用的主要是：日历看板+待办，日历看板由用户投喂的订单、发货数据编织而成，待办由系统自动策略+用户添加组成，提醒落位到不同的日历天，用户需要做的就是在平铺的时间线上进行常规的数据投喂，然后让一切自然发生，处理当天待办、识别分析异常、采取业务动作。

产品设计过程中思路、交互、甚至视觉方案借鉴参考有什么大碍呢？

当然，我们构建产品的过程并不能从它处作为起点，最多只是参考信息而已。自己产品的构建过程一定是从自己的业务、用户、商业目标中生长构建出来的，我们要满足的是自己用户的目标、业务目标、商业目标。

上述的方案其实只完成了第一步，即底层跟办的数据、逻辑模型搭建，最多算是到达了框架层而已，表现层的空间还有很大，产品也在持续的优化演进之中。

常见的迭代结束后甚至于迭代内容处于验收末期时，开发资源就会被快速的被项目撤走。从项目的角度来说，加快资源日历的流转，看起来是可以提高“研发效率”的。简单的理解思路就是，快马加鞭，削短空闲时间。以为只要自己奔跑，就能超过时间。

部分研发人员，也会迫不及待的想进入下一个迭代的冲刺。对于这样的研发表示情感不得不鼓励，但并不赞赏。他们迫切的coding结束，提测，等待测试来发现未尽的细节。

如果是以上的情况，那么事实的通常会是，资源被快速抽离进入下一个迭代的进程之后，逐渐暴露出来：提测质量不佳、实现点缺失、关联系统影响改动遗漏、验收时间被拖延。表面看起来开发端在赶紧时间交付代码，但是如果质量不佳，不好的影响非常大：

1、新的迭代起了头，不得不被搁置。需要一气呵成的代码逻辑，被不断打断之后难免出现纰漏
2、开发自身的情绪和信心波动，由于没有完整的自测和深入的代码完毕后的复盘，面对排山倒海的缺陷甚至都怀疑人生了
3、测试、产品、开发沟通成本剧增，由于编码前的一些必要信息对齐缺失，暴露在测试阶段将会大幅度提升沟通成本，关于功能、实现逻辑等
4、产品正常的节奏、测试的节奏收到不可控的影响，引发各个环节的时间被强制挤压，整体质量下降
5、验收交付之后，由于资源早已投入下一个迭代，对于线上的质量问题，还要协调开发资源而不得不打算正在进行的开发工作
以上这些如果在项目资源规划层面没有正确的识别和评估，导致的结果必然是：研发节奏紊乱、团队信心波动，甚至于团队内部冲突。并且出现迭代总是不能如期保质保量交付，用户体验受挫。

通常能够做到对迭代正确的评估、认识、管理推进，已经是非常不错的了，这中间需要项目、产品、研发、技术的高度一致和碰撞，信息的不断对齐。同时充分相信团队成员，给予团队负责范围内的自主权利。一群人，最可怕的就是一条心搞一件事了。能做到以上，我认为就是一个好的项目管理者了，现实中能达到御己御人地步的可能也寥寥无几。更别提发布后的快速响应阶段，快速响应阶段应该成为一种常态，纳入到项目管理的资源规划范畴。

——————————
实例一则：
紧张的时间规划，版本上线后，产品、开发迅速抽离进入下一阶段的紧张验收和问题处理阶段后。上线项目，导致资源匮乏，缺乏跟进，最优势的资源被撤离后，暴露出来的是连贯性上的迅速脱节。毫无抗风险能力、容错空间，承担的后果就是不得不陷入低效冗杂的沟通、调整、修复过程，最终让整体的效果大打折扣，业务因此也会受到影响。

最近切换成全键盘输入法，据说可以锻炼双手防止老年痴呆，赶紧来试试。

猛的一下是真的不习惯，从 2006 年接触第一款手机就是九宫格啊。当年如日中天诺基亚值班机的按键是真的经典，记得第一天到大学宿舍，有个老乡那九宫格的手速简直起飞，还给我们演示在裤兜里面盲打，牛皮大王。

但是体验下来发现全键盘的容错性和精准性是真的调教的好，我用的是微信键盘，感觉已经做到了区域识别，你就在键盘上大概的字母位置点上去之后就可以出来精准的短词或者长句，联想修正能力优秀。

想起来也是挺逗的，当初 qwerty 键盘就是因为技术之初打字太快容易机械故障，所以调整的布局可以降低按键之间点击时间。后来这种按键方式逐渐成为用户共识得以保留。现在我们又要效率和准确，不变的布局在不同的时代焕发新生。

这不就是典型的老瓶装新酒嘛！产品设计里面的很多经典设计早已打穿用户心智，我们在需要做的创新，不一定是改变他们，而是更新他们的内核。

这里有2个维度可以解释这个现象，首先从用户体验设计的层次来看，我们保留经典的已经形成用户心智的表现层、框架层，而去更新迭代突破更往下的资源、能力、战略层的内容，由此可以让用户在熟悉的认知里面感受到强大的生机。

另外从用户体验价值来单看表现层、框架层，如果新价值-旧价值-用户切换成本，还不如旧价值也就确实没有必要，往往仅凭体验的表层实现用户迁移概率也是极低的。

常见的搜索引擎的交互窗口时一个输入框，可以搜索文本、视频、图片、网站、音乐等等。
通常也会有一个分类导航：图片、地图、音乐、视频etc
足够简单的背后代表着足够复杂的逻辑。

不让用户走回头路，及时的发现错误并提示，同时也尽可能减少错误发生的可能。有些意识是用户的潜意识认知，也就是常识范围，我们认为的常识通常不一定会表达出来。
比如：我对一个同事说等你空了我找你核对一个需求；背后大概率对应的是工作时间范围内、工作场合内。不可能是晚上、咖啡馆。这是一种角色框架层的共识信息。

如果产品没有及时识别到共识信息，或者没有再正确的逻辑节点去识别，会造成最终用户体验的逻辑混乱。比如一个交互流程，最开始就应该定义正确的信息，放在最后提交做判断提示。就会让用户非常的不爽，甚至于愤怒，特别是这个共识信息如果是过程的依赖的话，相当于用户要推到重建自己的交易行为。那么这次交易就是失败的，如果是一个开放的场景，我们就失去了这个用户。就算是一个封闭的使用环境，我们也失去了用户对于产品的好感。

为自己的用户考虑，为每一个交易价值的实现和顺畅考虑，可见很重要。

交互即交易！！！#潜意识##ispiik小站#

我们通常听说的故事是人的诚实与善良，诚实不一定表示善良。

诚实是客观存在的，我们看到是这样，其他人看到也是这样，是无差别的。善良不等于不诚实，也不等于诚实，善良是主观的，我们体现出对客体需求、客体感受的理解和共情。基于客体的诉求和情感，进行了相应的信息传递。

产品中竟然也存在类似的体验，我们希望用户不要犯错，却没有提供不去犯错的良好的支撑，而是用僵硬的变形的判断校验进行阻断，就会给人这个诚实的傻子的感觉。

举一例：用户填写一个表单，第一步是一些基础信息，用来定义填写对象和时间；第二步的详情信息中会有依赖第一步填写对象信息值的查询。所以就对第一步填写对象值的强依赖，这个对象值有两种做法，一是让用户自己选择（可选范围是用户有权限的该类型list，很有限，几乎不超过2个）；另一种做法是从用户的登录信息中默认带过来，但是用户登录信息中包含的这类对象值是有不同类型的，这就存在带过来类型不对的问题。

最初的设计会希望用户单独选择，因为这个功能的使用是低频的、同时给出默认值也起不到决定性的效率改善。反而可能带错类型、以及让用户无法感知到，选择的填写对象会和详细信息有关联关系。

曾经我们接收使用方的瞎掰去做了默认带出，这真的是草包行径。

你想让我们诚实，但是我们更想去做善良的事情！
（这样的思考不止是一个简单的设计，更是对人性的探索，多打磨多实践）

在重庆待的这几年大大小小在外也吃过不少餐厅，有坡坡上的、路边的、商场的、写字楼里的。
用过的筷子也形形色色，黑色、白色、棕色、褐色、红色的，木制、竹制、不锈钢、塑料、骨瓷的，短的、长的、超长的，还有各种刻字的、镶嵌金属制品的、也许还有镶金镶玉的。

但唯有一家餐厅的筷子印象最深——南坪万达广场桃太郎寿司的筷子。特有的几个核心优点：
1、长度适中：比一次性筷子略长，又比家中常用的筷子略短，适中的长度在手里的感觉一点也不突兀。没有有些短筷子在手中看起来那种矮胖错的感觉，也没有那种长筷子在手中像撑杆跳一样的突兀；有点像一把小小的折扇在手中的惬意；
2、重量分配：是粗细渐变的造型，重心刚好保持在 捏筷子的几根手指附近，操作起来不至于很重也不会轻飘；
3、筷尖（此为最优）：桃太郎家的菜品又寿司、拉面、小吃、土豆泥、藻类、料理、生鱼片等，这个操作下来简直通用，很小的、很滑的、需要挑的、需要拨的、戳的、夹的、 捏的，都可以轻松操作。筷子头部较细，还有特殊处理的防滑纹理，并且筷子头部并没有因为粗细渐变的结构导致筷头分开太大，就连拉面里面的鹌鹑蛋都可以轻松驾驭 夹起来 戳起来都很好用。这个在有些餐厅饱受凄苦啊，筷子头分开的缝隙死活让你夹不到那些偏滑溜、偏小、偏细的食物。

还用过一些筷子，比重严重失调，每一次夹动都让我感觉像是在撬动巨大的杠杆，虽然你是杠杆但不要表现的这么明显吧。更别提有些轻飘飘的、或者重的都不像提起的筷子。能够理解桃太郎的筷子放在五星级酒店的饭桌倒也不太合适。不是一种风格、也不是同类的菜系。

总之就餐厅角度来言，这是我目前印象最深的筷子。甚至后来会因为这个体验，再去吃（当然前提是菜品也过得去）。

2021年Q1入职新团队，4月份在一次团队产品评审会议上。各位产品伙伴对于订单的一个流程进行了激烈的讨论，大致问题是：

“关于退货库存返还和退款时机的讨论，线上订单流程很清晰，退货会等顾客寄回实物，收到实物入库之后，运营人员再触发退款流程进行退款。这样确保了真实世界不可逆的数字化。

然而线下门店是临场操作，顾客、商品、收银员，商品还回、交接查验、入库、退款，几个信息单元、行为点密集的发生在很短的时间点上。这个短暂的时间，还要面临事件的多变性，历史的设计逻辑是，收银员从系统上面点击了售后申请、然后返还增加库存、然后退款给客户。

如此一来，会出现有的客户在没有拿到退款之前，对于售后行为的返水，突然想了下，我不售后了。系统就出现了，取消售后。对于单据和库存的交互逻辑来说，已经完成了基于订单轴线的正向销售出库、逆向退货入库，如果要应对客户取消售后需要再次实现基于售后订单的出库，一个订单的数据结构就会如下图所示——一个没有尽头的订单：

所以，对于线上订单的节点容易区分，是线性的信息流推进：客户发起售后意愿–>顾客寄回实物–>收货库存增加–>退还相应金额

对于即时交易的线下订单难以处理，因为是逻辑上有依赖关系的信息并发处理，打乱时序就造成混乱。这种情况：客户发起售后意愿–>收银员接受信息–>顾客归还实物–>收银员退还相应金额–>库存增加

线下的当面交易，把客户接收退款作为流程的不可逆节点，最后执行库存数据的返还。

说说我为什么会离开前公司，一家区域东南亚境外旅游NO.1的批发商，全国峰值10家+分子公司的拟IPO旅游集团，年输送游客50万+人次。

首先，不是旅游行业边界的问题，只是旅游行业太大，而团队钻入的细分空间存在边界，同时团队的认识存在边界，让我感受到无法突破的窒息感。由此也引发了自己对旅游行业、旅游服务商未来方向的一些思考，分享探讨。

继续阅读2020年后的未来旅游服务商，路在何方？