今天则继续分享控制层的“三化”（功能要素抽象化、产品规则透明化、产品能力配置化）。
菜单路径场景化，解决的是路径问题，确保用户不迷路，高效直达目的地。
实体关系解耦化，是通过系统内在对象之间关联关系的设计与架构，保证产品的扩展性与体验。
那功能要素抽象化，就是解决到达目的地后，通过设计对应实体与属性之间的关联、组合，帮助用户高效完成其角色所需的任务。
这里有两个关键词：高效、完成，而这两个词在页面结构呈现上，考验的都是产品经理的抽象能力。
比如作为一名考勤HR，基于企业制定的年假规则，期望可以高效完成配置，并确保员工年假余额正确。
如果提供以下三个方案，你会如何选择？
方案一（如下图所示）：假期余额主要抽象成了四个核心要素：发放方式、发放日期、发放额度、有效期。
方案二：假期余额主要抽象成了六个核心要素：发放方式、发放时间、发放额度（分工龄/司龄）、特殊发放规则、发放上限、有效期
方案三：假期余额主要抽象成了八个核心要素：发放周期、周期开始时间、发放频次、是否区分法定年假/福利年假、法定年假（发放方式）、福利年假（发放方式）、发放上限、有效期
如果我们不解析，单纯以直观感受来看，如果你是用户，哪个方案可以让你更高效地完成任务？
是的，我猜是第三套方案。
如上图所示，方案三的抽象、解耦更彻底，对应支持的场景就成倍数增加，更利于高效完成你的业务规则的适配。
比如方案一、二，都只抽象了两个要素（即发放方式与发放时间），如果是一个3*2的组合的话，支持场景最多就是6个；
方案三却抽象了三个要素（即发放周期、发放频次、发放时间），那就可以变成422的组合，可支持场景最多变成了16个。
再比如方案一、二，在【发放类型、发放条件、发放额度】三个核心要素的抽象上，均采用一一对应的单一方式（即发放的是司龄年假，就只能用司龄做条件，对应设置发放阶梯）。即如果每个要素有2个选择，则最多支持场景是4个（条件与类型完全1:1，再跟两种发放额度进行组合）
方案三却优先抽象了一个要素（司龄与工龄是否合并发放），同时，发放类型、发放条件、发放额度之间，也采取了自由组合的方式，并不限定类型与条件的1:1。
结果支持场景数量就变成：司龄与工龄是否合并发放发放类型发放条件发放额度 = 2324 = 48个场景。
总结一句话：方案一、二与方案三的支持场景数，在两个核心的维度上的对比是6:16以及4:48。
我猜你可能会说，作为产品经理，也需要考虑研发成本，方案三确实足够抽象与灵活，但却增加了研发的复杂度，对应增加了研发成本。
是的，无可否认。
但同时你也需要思考两个点：
第一，业务发展。作为一款SaaS产品通用性是核心，伴随业务的发展，不同行业、规模的企业的加入，其对年假的诉求一定会出现极大差异。如果不支持，你怎么办？
第二，产品迭代。产品都不是规划出来，而是迭代出来的。如果设计之初的设计，不够抽象、解耦，不保证灵活性，后续扩展成本将会更高，甚至只能重构解决。
如果你在设计之初，尽可能把其底层要素进行足够的拆分、解耦、抽象，可以每个要素先只支持1-2个核心场景，后续逐步根据需求迭代开发，并不影响你的设计。
换句话说，我们把抽象设计与研发，就像商业的买跟卖一样，做了彻底的解耦。设计时尽可能抽象与全面；研发时，则可分期落地，逐步迭代即可。
比如方案三的设计。第一版本完全可以是：周期只支持2个（年跟半年）、频率只支持1个（按周期开始时间）、发放时间支持2个（指定时间、入职时间）、法定与福利年假不区分（即1个）、发放额度支持4个（按工龄发放、按司龄发放、按工龄与司龄之和发放、按工龄与司龄最大值发放）。
这个版本，基本就等同于方案一、二所支持的场景。
那如何才能做出方案三这样，足够抽象，足够高效，足够简单的产品方案呢？
第一，先发散与拆解。可借助思维导图（或Axure均可），把对应模块所有要素进行尽可能细致、全面的完全拆解。
原则1：依然是MECE原则。即尽量保证要素之间独立、穷尽。
比如案例三就是把【发放类型】（法定年假或司龄年假）、【发放条件】（根据工龄还是司龄）完全独立，而不是法定年假的条件只能是【工龄】，司龄年假的条件就只是【司龄】，否则就不够穷尽。
原则2：一个要素尽量只负责一个维度。不要用一个要素去控制两个（及两个以上）维度的事情，可以把它拆解成两个（及两个以上）要素。
比如案例三就是把【周期】、【周期开始时间】、【频率】完全独立，每个要素负责自己的维度，而方案一/二，则是将3个要素，耦合成2个要素（发放方式与时间），让【周期】变成了一个不独立的要素。
思路：可从时间、空间、结构、因果、过程等方向进行拆解与抽象。
比如事前、事中，事后，就是从时间维度拆解；
首页、列表页、详情页，就是从空间维度拆解；
发放周期、发放频率、发放方式、发放类型、发放额度、发放限制，就是从结构维度拆解；
基本规则、发放（或生产）规则、使用规则，就是从过程维度拆解；
第二，组合、封装与合并。
用模板进行组合与封装后，遵循最小闭环原则落地。
经过第一步设计出来的是全面、细致的要素设计，但落地实施时，可基于最小闭环原则进行组合、合并、封装后，拆分版本落地。
它就像你设计了一个复杂的环绕、交叉、多层的立交桥，因资金、时间等限制性因素，导致你不得不拆分，此时你需要做到的就是：地基基础打牢的同时，先建设南北方向且只有1层，但至少保证车是可以通行，后续再打通东西方向以及2层、3层等。
同时，如果感觉抽象的要素过于灵活、细小（为了扩展性），增加了用户使用的复杂度，则可借助模板的方式解决。
比如不同假期的要素拆解的足够抽象，要素足够细化，但实际主流的假期类型是可以模板化的。比如年假模板、调休假模板等。
最后，附上另一个实战中的例子（我个人比较偏视觉思考的人，所以更喜欢用Axure画图的方式，而不是Xmin思维导图），供参考。
规则是To B产品（含SaaS）不可或缺的部分，不同行业、不同规模、不同阶段的企业客户，对应的业务需求一定会有所差异。
它好像看不见，却又无时不在影响着用户体验。
比如作为一名薪酬管理员，TA可能会问：
为什么员工年假余额是5天，而不是6天？ 为什么员工打卡了，却依然显示旷工？ 为什么员工申请了加班，也打卡了，但却没有生成调休？ 为什么外出申请10:00-18:00，外出时长却是0？ 为什么请假半天是3.5小时，而不是4小时？ 等等。
这一切问题都跟产品规则相关，用户一旦不理解规则，就容易产生情绪，增加客诉量，阻碍研发效率，加深用户对企业品牌的负向印象。
怎么办？
比如作为一名企业的考勤HR，根据企业考勤制度给员工发放年假是基础工作，你期望对员工的年假余额的来源有清晰的规则，避免员工有年假疑问（尤其是离职/裁员时）无法有效解释，从而导致用工纠纷。
基于这样一个视角，咱们一起看下面三个方案。
方案1：年假余额记录化。第一页面显示员工每个假期的余额，第二页面则采用记录的方式，记录每次年假余额变化（发放/调整/使用）的记录。
方案2：年假余额透明化。第一页面同样是显示员工每个假期的余额，第二页面则采用余额规则透明化的方式，显示每次年假余额的发放、使用、生效等详情。
方案3：年假余额黑盒化。按不同年份显示员工对应年假的余额，且只显示最终的年假总额以及同假期下的不同维度的总额。
如果你是考勤HR，你会觉得哪种方案的体验更好？
我猜是：方案2 > 方案1 > 方案3。
方案1跟方案2的差距不大，但与方案3的差距明显。
方案1跟2在产品规则（即年假发放/使用规则）透明化的设计上，明显都做了深度思考，保证让用户清楚查看员工年假的“来龙去脉”。
方案2比方案1略胜一筹之处，是两个细节：
比如员工跟你反馈说：为什么我的年假余额是5天，而不是6天？
如果是方案1的话，你需逐条发放记录去核算，什么时候发了几天，它的有效期是什么时候，什么时候又用了几天，在你往下翻查记录的同时，计算量与记忆量已经把你的“CPU”干烧了。
如果是方案2的话，你直接在表格里，你可基于每一条发放余额，直接看其发放数、使用数、剩余数、过期状态，同时，可对比所有原始记录，无需记忆与计算太多即可发现问题。
如果是方案3的话，你可能就头疼了，它只有一个总额，且总额还分工龄、司龄以及当前可请、当前可调整年假（折算发放）等等。
所以你需要先了解不同字段的含义，然后自己根据总年假余额，去查看对应的年假规则（如何发放，什么时候过期，使用了多少天，如何结转剩余等），再计算最终结果与实际结果的差异。
它不仅不是“Don’t make me think”，而是你让多重“think”，这就是典型产品规则不透明所对产品体验所带来的负向影响。
如果你的产品（尤其是SaaS产品）有统计类（比如报表字段与汇总结果）、消费类（比如假期管理、加班管理等）功能，则一定要考虑产品规则的透明设计，它影响用户体验与情绪感受的同时，还会产生很多客诉问题，阻碍你的研发效率。
原则1：如果有生产、流转、使用、消耗、过期等状态/数据变化过程，则一定要有清晰且透明化的产品设计。
原则2：如果有用户操作类行为，则一定要外化所有操作记录，以及后台记录所有日志。
我遇到几次离谱的“经历”，如果没有这些设计的话，可能会带给企业不小的损失。
目前的PS手段与技术，确实已经比较成熟，如果不是有日志与记录辅佐，真的可以达到以假乱真的地方，让极少数员工在与企业有纠纷时，把最终的“罪责”强加给SaaS产品服务商。
SaaS产品的底色是标准化和续费，它是客户规模化的前提，是企业盈利的基线。
不同行业、不同规模、不同阶段的企业客户，标准化SaaS产品的贴合度不同，有些企业可到95%，有些企业可到85%，有些企业则只能满足70%。显然，产品与需求贴合度越低，新签率就低，续费流失率就高。
以我目前所负责的系统中的一个模块的需求量来说，过去2年解决了900多条需求，现在待解决需求还有5219条（90%以上是合理需求）。
所以标准化成了SaaS企业的生命线，而长尾个性需求的解决方案成了成长上限（即谁可以更更低成本有效解决长尾需求，谁就可以在市场竞争中获利）。
如果要解决产品标准化与需求个性化的矛盾，一般会有两个产品路径：
路径一，还是路径二？
我猜你可能想选路径一，但现实情况下，却只有极少数企业会选择路径一，而是更多选择了路径二。
比如HR SaaS赛道，已经做到一定规模的企业，少说也有十几家（比如北森、盖雅、肯耐珂萨、薪人薪事、i人事、2号人事等），但只有北森（唯一一家）采用了路径一，其余均是路径二。
从结果层面看，北森确实也做到了中国HR SaaS的第一名（从市场占有率看），以及成为了第一家上市的中国HR SaaS企业，但其也付出了“惨重”的代价，最近几年居高不下的产研成本（理想情况是产研成本20%，但其却40%~50%之间，比如2023年其营收7.5亿，3.5亿的研发投入），导致亏损严重，股价上市后就变成了“骨价”（即骨折的价格）。
这就是一般SaaS企业不敢轻易选择路径一的原因（即产研投入太大），甚至PaaS平台的搭建成本，比SaaS平台本身还大。
所以本文的主题是路径二（即SaaS标准化的产品能力配置化），路径一（即SaaS+PaaS模式）按下不表。
路径二的三个核心设计方向是：功能配置化、规则配置化、数据定制化。
所以SaaS产品能力配置化的本质是乐高积木的模式，它提供的是一个有限集合的自由组合，让用户在既有的“积木”下，搭建出比较符合需求的“玩具”。
比如你作为一名考勤HR，期望SaaS产品可搭建出符合需求的报表，以此完成对数据的统计与分析工作。
方案1：自定义报表与字段。初始内置5张基础表，以及常用字段。如需更多报表或字段，则可通过自定义的方式配置。
方案2：自定义报表与字段。初始内置2张基础表以及常用字段，且支持自定义报表与字段。
方案3：自定义报表，但不可自定义字段。内置十几个报表，且不支持编辑内置报表。
如果你是考勤HR，你会觉得哪种方案的体验更好？
我猜是：方案2 > 方案1 > 方案3。
方案1跟2的差距微乎其微，后者略微胜出的点是：自定义字段功能属于免费功能，而前者是付费能力。
至于方案3则差距明显，内置报表过多且不可编辑，对用户的干扰太多。同时，不允许自定义字段，则缺失了统计字段的灵活性与透明度。
方案1跟2显然可以满足更多需求场景，而方案3就显得捉襟见肘。
或许你会有疑问说：方案1跟2解决场景多且体验好，但对应研发成本也高，如何权衡？
我还是那句话：以终为始，全面设计；以始为终，最小闭环。如果你开始时就采用方案3的方式，等你回头想支持灵活自定义时，除了重构，别无他法，最终成本远超初始版+重构版。
原则1：所有员工端的功能，一定尽量开关配置化（即让管理员可配置开启或关闭）。
这样的教训实在是血淋淋，每次员工端的功能更新，但凡没有开关控制，上线那几天，客诉量翻倍，被迫紧急弄了不少白名单特殊处理。
原则2：所有报表统计类功能，一定尽量自定义配置化。它包含报表本身在自定义（即新建/编辑/删除），字段列的顺序调整，以及自定义字段。
我们所说的自定义字段是指有限集合内的自定义（即提供数十或数百个已知字段或条件、公式，让用户自行进行组合），而不是完全自定义。
典型如上述案例的方案1跟方案2。
原则3：所有产品规则类的设计，一定要抽象化与配置化。
抽象化可见上述【功能要素抽象化】，浅聊一下配置化。
以加班规则为例（如下图）。
所以你会发现规则的抽象化与配置化设计的本质，就是对客户需求场景的回应，如果你不够抽象、不够可配置化，自然就影响客户对你产品的体验认知。
KISS设计原则是SaaS产品设计最重要的原则，它的核心价值是让设计简洁，让操作傻瓜式，以此提升用户体验的同时，减少客诉问题，提升产研效率。
今天主要分享的是“三层八化”中的控制层。即：
1、功能要素抽象化：聚焦某个功能模块，采取提炼、抽象、拆分的方式，将每个要素独立和组合的方式，保证功能的灵活性与扩展性，同时，提升解决需求的场景数。
以HR SaaS产品的假期规则为例，分享了三个案例，以及对应的两个思路与三个原则。即
第一，先发散再收敛。
第二，组合、封装与合并。即用模板进行组合与封装后，遵循最小闭环原则落地
2、产品规则透明化：聚焦解决产品规则的问题，让复杂、隐藏规则和逻辑对用户透明，提升体验，减少客诉。
以年假假期额度的管理为例，分享了三个案例，以及对应两个设计原则。
3、产品能力配置化：解决产品功能与用户需求的匹配度问题，让用户拥有控制感。
以报表设计为例，分析了三个案例，以及对应的三个配置化设计方向。
第一，功能配置化。即所有员工端的功能，一定尽量开关配置化（即让管理员可配置开启或关闭）
第二，规则配置化。即所有产品规则类的设计，一定要抽象化与配置化。
第三，数据定制化。即所有报表统计类功能，一定尽量自定义配置化。
Time，下篇见（分享最后的表现层）。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。