KISS原则：SaaS制品设计最重要的原则（中）-天涯论坛

219mze 发表于 2024-8-7 17:24:06

KISS原则：SaaS制品设计最重要的原则（中）

在上篇中，咱们分享了KISS原则中的结构层二化，这篇文案，咱们继续分享继续分享掌控层的“三化”，并带有案例讲解，期盼能帮到大众。

<img src="https://q8.itc.cn/q_70/images03/20240622/8effaeac3db143c88df10645f2b803d5.jpeg" style="width: 50%; margin-bottom: 20px;">
上篇KISS原则：SaaS制品设计最重要的原则（上），重点分享的是结构层“二化”（菜单路径场景化与实体关系解耦化）。
今天则继续分享掌控层的“三化”（功能要素抽象化、制品规则透明化、制品能力配置化）。
<img src="https://q5.itc.cn/q_70/images03/20240622/76d1bebc5ef841c7b70f5b5557231e37.png" style="width: 50%; margin-bottom: 20px;">
1、掌控层：功能要素抽象化 
菜单路径场景化，处理的是路径问题，保证用户不迷路，有效直达目的地。
实体关系解耦化，是经过系统内在对象之间相关关系的设计与架构，保准制品的扩展性与体验。
那功能要素抽象化，便是处理到达目的地后，经过设计对应实体与属性之间的相关、组合，帮忙用户有效完成其角色所需的任务。
这儿有两个关键词：有效、完成，而这两个词在页面结构呈现上，考验的都是制品经理的抽象能力。
1.1、案例 
例如做为一名考勤HR，基于企业制定的年假规则，期望能够有效完成配置，并保证员工年假余额正确。
倘若供给以下三个方法，你会怎样选取？
方法一（如下图所示）：假期余额重点抽象成为了四个核心要素：发放方式、发放日期、发放额度、有效期。
<img src="https://q8.itc.cn/q_70/images03/20240622/0d5341906fd64d01b585d2dada5d7267.png" style="width: 50%; margin-bottom: 20px;">
方法二：假期余额重点抽象成为了六个核心要素：发放方式、发放时间、发放额度（分工龄/司龄）、特殊发放规则、发放上限、有效期
<img src="https://q3.itc.cn/q_70/images03/20240622/e721988f0b1a4be8a966588a5973752f.png" style="width: 50%; margin-bottom: 20px;">
方法三：假期余额重点抽象成为了八个核心要素：发放周期、周期起始时间、发放频次、是不是区分法定年假/福利年假、法定年假（发放方式）、福利年假（发放方式）、发放上限、有效期
<img src="https://q0.itc.cn/q_70/images03/20240622/926c276d48564216adbb6706079efc43.png" style="width: 50%; margin-bottom: 20px;">
倘若咱们不解析，单纯以直观感受来看，倘若你是用户，哪个方法能够让你更有效地完成任务？
是的，我猜是第三套方法。
1.2、解析 
<img src="https://q8.itc.cn/q_70/images03/20240622/78e1f72b41994e1a95940ff94ae00077.png" style="width: 50%; margin-bottom: 20px;">
如上图所示，方法三的抽象、解耦更彻底，对应支持的场景就成倍数增多，更利于有效完成你的业务规则的适配。
例如方法1、二，都只抽象了两个要素（即发放方式与发放时间），倘若是一个3*2的组合的话，支持场景最多便是6个；
方法三却抽象了三个要素（即发放周期、发放频次、发放时间），那就能够变成422的组合，可支持场景最多变成为了16个。
再例如方法1、二，在【发放类型、发放要求、发放额度】三个核心要素的抽象上，均采用一一对应的单一方式（即发放的是司龄年假，就只能用司龄做要求，对应设置发放阶梯）。即倘若每一个要素有2个选取，则最多支持场景是4个（要求与类型完全1:1，再跟两种发放额度进行组合）
方法三却优先抽象了一个要素（司龄与工龄是不是合并发放），同期，发放类型、发放要求、发放额度之间，亦采取了自由组合的方式，并不限定类型与要求的1:1。
结果支持场景数量就变成：司龄与工龄是否合并发放发放类型发放要求发放额度 = 2324 = 48个场景。
总结一句话：方法1、二与方法三的支持场景数，在两个核心的维度上的对比是6:16以及4:48。
1.3、疑问 
我猜你可能会说，做为制品经理，亦必须思虑开发成本，方法三确实足够抽象与灵活，但却增多了开发的繁杂度，对应增多了开发成本。
是的，无可否认。
但同期你亦必须思考两个点：
第1，业务发展。做为一款SaaS制品通用性是核心，伴同业务的发展，区别行业、规模的企业的加入，其对年假的诉求必定会显现极重差异。倘若不支持，你怎么办？
第二，制品迭代。制品都不是规划出来，而是迭代出来的。倘若设计之初的设计，不足抽象、解耦，不保准灵活性，后续扩展成本将会更高，乃至只能重构处理。
倘若你在设计之初，尽可能把其底层要素进行足够的拆分、解耦、抽象，能够每一个要素先只支持1-2个核心场景，后续逐步按照需求迭代研发，并不影响你的设计。
换句话说，咱们把抽象设计与开发，就像商场的买跟卖同样，做了彻底的解耦。设计时尽可能抽象与全面；开发时，则可分期落地，逐步迭代就可。
例如方法三的设计。第1版本完全能够是：周期只支持2个（年跟半年）、频率只支持1个（按周期起始时间）、发放时间支持2个（指按时间、入职时间）、法定与福利年假不区分（即1个）、发放额度支持4个（按工龄发放、按司龄发放、按工龄与司龄之和发放、按工龄与司龄最大值发放）。
这个版本，基本就等同于方法1、二所支持的场景。
1.4、经验 
那怎样才可做出方法三这般，足够抽象，足够有效，足够简单的制品方法呢？
第1，先发散与拆解。可借助思维导图（或Axure均可），把对应模块所有要素进行尽可能细致、全面的完全拆解。
<img src="https://q7.itc.cn/q_70/images03/20240622/9a0f678f935a4a4da637a1deee37a0be.png" style="width: 50%; margin-bottom: 20px;">
原则1：依然是MECE原则。即尽可能保准要素之间独立、穷尽。
例如案例三便是把【发放类型】（法定年假或司龄年假）、【发放要求】（按照工龄还是司龄）完全独立，而不是法定年假的要求只能是【工龄】，司龄年假的要求就只是【司龄】，否则就不足穷尽。
原则2：一个要素尽可能只负责一个维度。不要用一个要素去掌控两个（及两个以上）维度的事情，能够把它拆解成两个（及两个以上）要素。
例如案例三便是把【周期】、【周期起始时间】、【频率】完全独立，每一个要素负责自己的维度，而方法一/二，则是将3个要素，耦合成2个要素（发放方式与时间），让【周期】变成为了一个不独立的要素。
思路：可从时间、空间、结构、因果、过程等方向进行拆解与抽象。
例如事前、事中，事后，便是从时间维度拆解；
首页、列表页、详情页，便是从空间维度拆解；
发放周期、发放频率、发放方式、发放类型、发放额度、发放限制，便是从结构维度拆解；
基本规则、发放（或生产）规则、运用规则，便是从过程维度拆解；
第二，组合、封装与合并。
用模板进行组合与封装后，遵循最小闭环原则落地。
经过第1步设计出来的是全面、细致的要素设计，但落地实施时，可基于最小闭环原则进行组合、合并、封装后，拆分版本落地。
它就像你设计了一个繁杂的环绕、交叉、多层的立交桥，因资金、时间等限制性原因，引起你不得不拆分，此时你必须做到的便是：地基基本打牢的同期，先建设南北方向且仅有1层，但最少保准车是能够通行，后续再打通东西方向以及2层、3层等。
同期，倘若感觉抽象的要素过于灵活、细小（为了扩展性），增多了用户运用的繁杂度，则可借助模板的方式处理。
例如区别假期的要素拆解的足够抽象，要素足够细化，但实质主流的假期类型是能够模板化的。例如年假模板、调休假模板等。
最后，附上另一个实战中的例子（我个人比较偏视觉思考的人，因此更爱好用Axure画图的方式，而不是Xmin思维导图），供参考。
<img src="https://q5.itc.cn/q_70/images03/20240622/9fb655653bf14912baab256de7b1173e.png" style="width: 50%; margin-bottom: 20px;">
2、掌控层：制品规则透明化 
规则是To B制品（含SaaS）不可或缺的部分，区别行业、区别规模、区别周期的企业客户，对应的业务需求必定会有所差异。
它好似看不见，却又无时不在影响着用户体验。
例如做为一名薪酬管理员，TA可能会问：

为何员工年假余额是5天，而不是6天？ 为何员工打卡了，却依然表示旷工？ 为何员工申请了加班，亦打卡了，但却无生成调休？ 为何外出申请10:00-18:00，外出时长却是0？ 为何请假半天是3.5小时，而不是4小时？等等。

这一切问题都跟制品规则关联，用户一旦不睬解规则，就容易产生心情，增多客诉量，阻碍开发效率，加深用户对企业品牌的负向印象。
怎么办？
2.1、案例 
例如做为一名企业的考勤HR，按照企业考勤制度给员工发放年假是基本工作，你期望对员工的年假余额的源自有清晰的规则，避免员工有年假疑问（尤其是离职/裁员时）没法有效解释，从而引起用工纠纷。
基于这般一个视角，咱们一块看下面三个方法。
方法1：年假余额记录化。第1页面表示员工每一个假期的余额，第二页面则采用记录的方式，记录每次年假余额变化（发放/调整/运用）的记录。
方法2：年假余额透明化。第1页面一样是表示员工每一个假期的余额，第二页面则采用余额规则透明化的方式，表示每次年假余额的发放、运用、生效等详情。
方法3：年假余额黑盒化。按区别年份表示员工对应年假的余额，且只表示最后的年假总额以及同假期下的区别维度的总额。
<img src="https://q2.itc.cn/q_70/images03/20240622/6f9931cf9c4241b88c3636e587b67244.png" style="width: 50%; margin-bottom: 20px;">
倘若你是考勤HR，你会觉得哪种方案的体验更好？
我猜是：方法2 > 方法1 > 方法3。
2.2、解析 
方法1跟方法2的差距不大，但与方法3的差距显著。
方法1跟2在制品规则（即年假发放/运用规则）透明化的设计上，显著都做了深度思考，保准让用户清楚查看员工年假的“来龙去脉”。
方法2比方法1略胜一筹之处，是两个细节：细节1：采取列表方式，让用户可清晰核算、对比年假余额，快速定位问题；
细节2：年假结果与调节一体化，让用户可对每次的发放、调节、运用额度有核算的锚点。例如员工跟你反馈说：为何我的年假余额是5天，而不是6天？
倘若是方法1的话，你需逐条发放记录去核算，什么时候发了几天，它的有效期是什么时候，什么时候又用了几天，在你往下翻查记录的同期，计算量与记忆量已然把你的“CPU”干烧了。
倘若是方法2的话，你直接在表格里，你可基于每一条发放余额，直接看其发放数、运用数、剩余数、过期状态，同期，可对比所有原始记录，无需记忆与计算太多就可发掘问题。
倘若是方法3的话，你可能就头疼了，它仅有一个总额，且总额还分工龄、司龄以及当前可请、当前可调节年假（折算发放）等等。
因此你必须先认识区别字段的含义，而后自己按照总年假余额，去查看对应的年假规则（怎样发放，什么时候过期，运用了多少天，怎样结转剩余等），再计算最后结果与实质结果的差异。
它不仅不是“Don’t make me think”，而是你让多重“think”，这便是典型制品规则不透明所对制品体验所带来的负向影响。
2.3、经验分享 
倘若你的制品（尤其是SaaS制品）有统计类（例如报表字段与汇总结果）、消费类（例如假期管理、加班管理等）功能，则必定要思虑制品规则的透明设计，它影响用户体验与心情感受的同期，还会产生非常多客诉问题，阻碍你的开发效率。
原则1：倘若有生产、流转、运用、消耗、过期等状态/数据变化过程，则必定要有清晰且透明化的制品设计。例如假期管理，则必要设计假期余额的变化过程（即发放额度、调节额度、运用额度、过期额度），以及所有的请假记录的制品化；
例如加班管理，则必要设计加班余额的变化（即加班时长、调节时长、调休时长、结转加班费时长、过期时长），以及所有加班记录、调休记录的制品化；
例如报表管理，则必要设计字段的定义与公式的制品化（能够是字段管理功能，亦能够是报表头的气泡等）。
例如补助管理，则必要外化表示所有补助明细（例如每日补助金额与每一个补助项）。原则2：倘若有用户操作类行径，则必定要外化所有操作记录，以及后台记录所有日志。例如管理员新建、调节、删除假期规则，或手动调节假期余额、有效期等；
例如管理员调节员工的出勤状态；
例如员工打卡时，进出打卡页面时间、途径、手机、方式等，以及打卡记录。我遇到几次离谱的“经历”，倘若无这些设计的话，可能会带给企业不小的损失。例如有员工供给了一张截图，是其5月9日已审批请假的记录证明，TA用这张图跟HR争辩，当天明明已请假，系统却是旷工，说是系统的Bug引起。实质状况是该员工有的是5月6号的审批请假，经过PS方式，把9改成6当做9号审批；
例如员工截图给HR说6月7日已打卡，且系统提醒打卡成功，是系统Bug引起当前考勤反常，期盼让咱们给个解释。实质状况却是员工当天进入了打卡页面，压根没打卡，至于那张照片，是其之前保留了6月5日的打卡成功页面，把对应日期PS为6月7号。日前的PS手段与技术，确实已然比较成熟，倘若不是有日志与记录辅佐，真的能够达到以假乱真的地区，让极少许员工在与企业有纠纷时，把最后的“罪责”强加给SaaS制品服务商。
3、掌控层：制品能力配置化
SaaS制品的底色是标准化和续费，它是客户规模化的前提，是企业盈利的基线。
区别行业、区别规模、区别周期的企业客户，标准化SaaS制品的贴合度区别，有些企业可到95%，有些企业可到85%，有些企业则只能满足70%。显然，制品与需求贴合度越低，新签率就低，续费流失率就高。
以我日前所负责的系统中的一个模块的需求量来讲，过去2年处理了900多条需求，此刻待处理需求还有5219条（90%以上是恰当需求）。
因此标准化成为了SaaS企业的生命线，而长尾个性需求的处理方法成为了成长上限（即谁能够更更低成本有效处理长尾需求，谁就能够在市场竞争中获利）。
倘若要处理制品标准化与需求个性化的矛盾，通常会有两个制品路径：

路径一：SaaS+PaaS双平台模式。SaaS制品处理80%的通用需求，剩余20%个性化需求，则由PaaS平台经过低代码、接口化等方式处理。
路径二：SaaS制品的最大可配置化。尽可能做到可处理80%-90%的需求，剩余10%则可周期性放弃（可插拨的插件化模式，可能是处理方法之一）。

路径一，还是路径二？
我猜你可能想选路径一，但现实状况下，却仅有极少许企业会选取路径一，而是更加多选取了路径二。
例如HR SaaS赛道，已然做到必定规模的企业，少说亦有十几家（例如北森、盖雅、肯耐珂萨、薪人薪事、i人事、2号人事等），但仅有北森（独一一家）采用了路径一，其余均是路径二。
从结果层面看，北森确实亦做到了中国HR SaaS的第1名（从市场占有率看），以及作为了第1家上市的中国HR SaaS企业，但其亦付出了“惨重”的代价，近期几年居高不下的产研成本（理想状况是产研成本20%，但其却40%~50%之间，例如2023年其营收7.5亿，3.5亿的开发投入），引起亏损严重，股价上市后就变成为了“骨价”（即骨折的价格）。
这便是通常SaaS企业不敢轻易选取路径一的原由（即产研投入太大），乃至PaaS平台的搭建成本，比SaaS平台本身还大。
因此本文的主题是路径二（即SaaS标准化的制品能力配置化），路径一（即SaaS+PaaS模式）按下不表。
路径二的三个核心设计方向是：功能配置化、规则配置化、数据定制化。

功能配置化：指功能可准许用户自选运用。例如审批类（区别假期类型的审批，那些开启，那些关闭）、打卡类（那些平台可打卡，那些则不可打卡）、表示类（假期余额、出勤数据、加班数据，是不是对员工/管理员展示）、出勤类（是不是准许出差、外勤等）、报表类（报表是不是准许管理、订阅，以及字段是不是可自定义）；规则配置化：指制品规则可根据业务需求灵活配置（与实体关系解耦化、功能要素抽象化息息关联）。例如加班规则、打卡规则、补助规则、扣款规则、外出/出差规则等，可自定义进行配置；数据定制化：指统计数据、报表、字段等可按照实质需求完成自定义，以此处理个性化需求。例如自定义报表、自定义统计图表或自定义严重迟到/早退的时长，或日均出勤时长是不是包括外勤、带薪假时长等，或全勤是不是包括出差/外勤、带薪请假等；因此SaaS制品能力配置化的本质是乐高积木的模式，它供给的是一个有限集合的自由组合，让用户在既有的“积木”下，搭建出比较符合需求的“玩具”。
3.1、案例 
例如你做为一名考勤HR，期望SaaS制品可搭建出符合需求的报表，以此完成对数据的统计与分析工作。
方法1：自定义报表与字段。初始内置5张基本表，以及常用字段。如需更加多报表或字段，则可经过自定义的方式配置。

方法2：自定义报表与字段。初始内置2张基本表以及常用字段，且支持自定义报表与字段。

方法3：自定义报表，但不可自定义字段。内置十几个报表，且不支持编辑内置报表。
倘若你是考勤HR，你会觉得哪种方法的体验更好？
我猜是：方法2 > 方法1 > 方法3。
3.2、解析 
方法1跟2的差距微乎其微，后者略微胜出的点是：自定义字段功能属于免费功能，而前者是付费能力。
至于方法3则差距显著，内置报表太多且不可编辑，对用户的干扰太多。同期，不准许自定义字段，则缺失了统计字段的灵活性与透明度。例如客户A说：咱们对严重迟到、早退的定义，是超过60分钟，而不是只记录迟到分钟数；
客户B说：咱们必须月报里，能够统计员工每月所上班次的次数，并给予对应补助金额；
客户C说：咱们线下的报表仅有20个字段，且正好符合A4纸打印，对应的次序、字段都需一一对应，需线下打印后，让对应分部负责人签字确认；
客户D说：咱们的报表必须表示每日的工作时长、加班时长、请假时长等，且必须放到同一个格子里。同期，还需区分两张区别报表：员工每月加班大于95小时，以及少于95小时，以便于政府稽查。
等等方法1跟2显然能够满足更加多需求场景，而方法3就显出捉襟见肘。
或许你会有疑问说：方法1跟2处理场景多且体验好，但对应开发成本亦高，怎样权衡？
我还是那句话：以终为始，全面设计；以始为终，最小闭环。倘若你起始时就采用方法3的方式，等你回头想支持灵活自定义时，除了重构，别无他法，最后成本远超初始版+重构版。
3.3、经验分享 
原则1：所有员工端的功能，必定尽可能开关配置化（即让管理员可配置开启或关闭）。例如员工打卡类：是不是可外勤打卡、是不是表示打卡时间、是不是提醒打卡、是不是表示安排加班等；
例如员工假期类：是不是限制余额、是不是表示有效期、是不是表示年假周期、按天还是按小时表示、是不是请假时表示累计请假数；
例如加班类：是不是表示加班时长、是不是加班加班赔偿、是不是表示加班明细等；
例如考勤数据类：是不是表示员工的考勤数据、是不是永久表示、是不是表示请假、加班等；
例如排班类：是不是准许排班、是不是可选所有班次、是不是限制排班周期、是不是需审批、是不是需锁定等；这般的教训实在是血淋淋，每次员工端的功能更新，但凡无开关掌控，上线那几天，客诉量翻倍，被迫紧急弄了不少白名单特殊处理。

原则2：所有报表统计类功能，必定尽可能自定义配置化。它包括报表本身在自定义（即新建/编辑/删除），字段列的次序调节，以及自定义字段。
咱们所说的自定义字段指的是有限集合内的自定义（即供给数十或数百个已知字段或要求、公式，让用户自动进行组合），而不是完全自定义。
典型如以上案例的方法1跟方法2。
原则3：所有制品规则类的设计，一定要抽象化与配置化。
抽象化可见以上【功能要素抽象化】，浅聊一下配置化。
以加班规则为例（如下图）。例如8:00-17:00上班，班后固定加班3小时（即上班8:00-20:00，同期3小时给加班赔偿），则仅有方法三的【固定加班】可处理；
8:00-17:00上班，12:00-13:00休憩吃饭，但有时赶工，休憩时间上班（给加班费），或有些工人需提前上班来调试设备1小时（给加班费），则仅有方法二跟三的【班次内休憩时间准许加班】以及【上班班前X分钟加班】能处理；
工作日加班时间不可少于1小时且不可多于3小时，而休憩日则不可少于4小时，且不可多于11小时，则仅有方法一跟二的【班前/班后最少加班X小时】以及【当日累计加班最少X小时】能处理；
工人加班时间不固定，有时8:00-17:00，有时9:00-18:00，或10:00-18:00，但中间加班都需扣除1小时的吃饭休憩时长，则仅有方法一跟二的【按休憩时长扣除】能处理；因此你会发掘规则的抽象化与配置化设计的本质，便是对客户需求场景的回复，倘若你不足抽象、不足可配置化，自然就影响客户对你制品的体验认知。
总结一下 
KISS设计原则是SaaS制品设计最重要的原则，它的核心价值是让设计简洁，让操作傻瓜式，以此提高用户体验的同期，减少客诉问题，提高产研效率。
今天重点分享的是“三层八化”中的掌控层。即：
1、功能要素抽象化：聚焦某个功能模块，采取提炼、抽象、拆分的方式，将每一个要素独立和组合的方式，保准功能的灵活性与扩展性，同期，提高处理需求的场景数。
以HR SaaS制品的假期规则为例，分享了三个案例，以及对应的两个思路与三个原则。即
第1，先发散再收敛。

原则1：MECE原则。即尽可能保准要素之间独立、穷尽。
原则2：一个要素尽可能只负责一个维度。

第二，组合、封装与合并。即用模板进行组合与封装后，遵循最小闭环原则落地
2、制品规则透明化：聚焦处理制品规则的问题，让繁杂、隐匿规则和规律对用户透明，提高体验，减少客诉。
以年假假期额度的管理为例，分享了三个案例，以及对应两个设计原则。原则1：倘若有生产、流转、运用、消耗、过期等状态/数据变化过程，则必定要有清晰且透明化的制品设计；
原则2：倘若有用户操作类行径，则必定要外化所有操作记录，以及后台记录所有日志。3、制品能力配置化：处理制品功能与用户需求的匹配度问题，让用户持有掌控感。
以报表设计为例，分析了三个案例，以及对应的三个配置化设计方向。
第1，功能配置化。即所有员工端的功能，必定尽可能开关配置化（即让管理员可配置开启或关闭）
第二，规则配置化。即所有制品规则类的设计，必定要抽象化与配置化。
第三，数据定制化。即所有报表统计类功能，必定尽可能自定义配置化。
Time，下篇见（分享最后的表现层）。
专栏作家
邢小作，微X公众号：邢小作之家，人人都是制品经理专栏作家。一枚在线教育的制品，关注互联网教育，爱好科研用户心理。
本文原创发布于人人都是制品经理。未经许可，禁止转载。
题图来自 Pixabay，基于CC0协议<a style="color: black;">返回外链论坛：www.fok120.com，查看更加多</a>

责任编辑：网友投稿

zrd123 发表于 2024-9-7 09:30:04

一看到楼主的气势，我就觉得楼主同在社区里灌水。

qzmjef 发表于 2024-9-30 04:18:00

祝福你、祝你幸福、早日实现等。

b1gc8v 发表于 2024-10-1 15:49:00

楼主听话，多发外链好处多，快到碗里来！外链论坛 http://www.fok120.com/

4zhvml8 发表于 2024-10-8 08:23:00

一看到楼主的气势，我就觉得楼主同在社区里灌水。

7wu1wm0 发表于 2024-11-10 08:35:13

你的见解独到，让我受益匪浅，非常感谢。

页: [1]

天涯论坛's Archiver

KISS原则：SaaS制品设计最重要的原则（中）