功能设计：如何将复杂的功能抽象成简洁易用的设计？

在上一篇文章《需求分析：如何从复杂的需求中抽象出核心问题？》中，我们深入探讨了如何从繁杂的用户需求中提炼出最核心的问题。这一过程是产品设计和开发的基础，但仅仅停留在需求分析阶段还不够。接下来，我们需要将这些核心需求转化为实际的功能设计，并保持设计的简洁性和易用性。

这就引出了我们今天的话题：功能设计中的抽象能力。如何将复杂的功能抽象成简洁易用的设计？在这篇文章中，我们将探讨功能抽象的重要性，以及如何在实际的产品设计中运用这一能力，创造出既满足用户需求又易于使用的功能。

案例1：如何对班次进行抽象设计，可既满足用户需求又易于扩展？

客户A是一家制造企业，实行白班和夜班双周交替的工作制度。

白班时间为早上8:00至晚上20:00，中间有两次休息时间（12:00-13:00与17:00-17:30）；夜班时间为晚上20:00至次日8:00，也有两次休息时间（与白班类同）。

每个班次的班后2.5小时算作加班（即白班加班时间为17:30至20:00，夜班加班时间为次日5:30至8:00），加班工资为正常工资的1.5倍。

此外，休息日如需加班，安排夜班，加班工资为正常工资的2倍。

方案一：通过【是否安排加班】控制是否有班前、班后加班

• 上班时间：允许添加多组，每组由上班时间跟下班时间组合成而成。同时，每组可至少内置添加3组休息时间；
• 班前加班：开启后，根据上班时间，自动算班前加班时间；

• 班后加班：开启后，根据下班时间，自动算班后加班时间。

  
  方案1-案例1.png

方案二：抽象最底层时段，自由组合不同类型的时段。

• 工作时段：抽象为一个对应的时段，可插入任意位置；
• 休息时段：也抽象为一个时段，可插入任意位置（除了首尾）；

• 加班时段：同样抽象为一个时段，可插入任意位置（不仅仅是班前与班后）。

  
  方案2-案例1.png

解析

方案二比方案一显然更抽象、更解耦。比如方案二休息时段、工作时段、加班时段是平级关系，而不是包含关系。同时，加班时段的位置与个数都更加灵活。

案例1的时段关系图.png

对应方案二所支持的场景，也更加丰富。

• 比如下班后先休息30分钟（吃饭时间），然后才加班2.5小时；
• 比如下班后必须先打卡，休息30分钟后，回来后需要再打卡才算开始加班以及结束后打卡；
• 比如上班休息时间，生产任务重时，期望安排员工加班，也按1.5倍工资计算。

案例2：如何抽象设计班次属性，以满足更多需求场景？

案例1的抽象设计主要解决了工作日上班时的固定加班，却没有解决公休日/节假日安排加班的场景。即休息时，因生产任务过重，工厂需统一安排员工加班，按2倍加班费进行补偿。

方案1：单一属性标识班次属性与类别

即在现有班次的基础上，新增一个属性：班次属性（可选工作日、公休日、节假日）。

• 如果配置成【工作日】，则表示当天是正常上班。即出勤后，正常计薪1天；
• 如果配置成【公休日】，则表示当天是安排加班，且是按公休日进行补偿。即出勤后，计为加班，按公休日2倍进行补偿；

• 如果配置成【节假日】，则也表示当天是安排加班，按按节假日进行补偿（一般是3倍工资）。

  
  功能设计-公休日加班-方案1.jpg

方案2：双重属性分别标识班次属性与类别

功能设计-公休日加班-方案2.jpg

即在现有班次的基础上，新增两个属性：班次属性（可选工作日、公休日、节假日）、班次类别（可选加班班次、出勤班次）。

• 如果配置成【工作日】，且是【出勤班次】，则表示当天是正常上班。即出勤后，正常计薪1天；
• 如果配置成【工作日】，且是【出勤班次】，则表示当天是安排加班，且按工作日进行补偿（一般是1.5倍）
• 如果配置成【公休日】，且是【出勤班次】，则表示当天是正常上班，但如果发生班前/班后自主申请加班时，按公休日进行补偿；
• 如果配置成【公休日】，且是【加班班次】，则表示当天是安排加班，，且按公休日进行补偿。同时，如果发生班前/班后自主申请加班时，按公休日进行补偿；
• 节假日与公休日类同，只是加班补偿有差异。

解析

相对方案一来说，方案二所支持的场景数与扩展性更强。即方案二可支持的场景数是：2 x 3 = 6个场景；方案一则是1 x 3 = 3个场景。

比如安排加班，但加班补偿按工作日1.5倍补偿，只有方案二支持；

比如公休日/节假日安排上班，计为正常上班。但如果班前/班后加班，则依然按公休日/节假日进行补偿，也只有方案二支持。

经验时刻

第一，产品抽象设计的前提是对需求本质的抽象。只有对需求的抽象到位，对不同需求场景的抽象，才有可能进行产品设计抽象。

比如案例1，对上班、加班、休息时段设计的抽象前提，是对制造业客户上班与加班需求场景的抽象。

相关案例可见：需求分析：如何从复杂的需求中抽象出核心问题？

第二，在功能抽象过程中，一个关键原则是确保每个属性只表达一个概念。这类似于一个人专注于单一任务时能更高效地完成。

例如，在案例2中，方案一使用【班次属性】来表达加班类型和是否安排加班，而方案二则将【加班类型】和【是否安排加班】分别用【班次属性】和【班次类别】来表达。这样的区分不仅提高了功能的清晰度，也使得用户更容易理解和操作。

相关案例可见：KISS原则：SaaS产品设计最重要的原则（中）

第三，你可以把一款产品想象为某个真实世界的投影，进行类比式思考与设计。

比如一款产品就像你的家，每个房间、每个窗户、每条路线的设计，都会影响客人对你家的整体感受。

一款产品的首页/工作台，就像你家里的客厅，客厅里的内容有吸引力、格局与路线清晰，你才能让客人更愿意逗留；

产品中的每个实体，就像你家里的每个房间，它有自己的场景定位，有自己的职责（比如睡觉、孩子学习或玩、书房灯），也必须与其他房间进行关联，完成动线设计；

每个房间如果进行多元场景化设计，让它可以自定义移动、拆装、组合灯（比如它的床可睡、可玩、可拆卸），那它对场景的支持将变得多元（比如你家的榻榻米屋，平常是孩子玩的地方，客人来了可以收拾当卧室等），这个过程就像你对某个实体的属性进行抽象设计的过程。

第四，善于利用工具，采用可视化的方式进行思考与设计。

我个人更偏好视觉性设计（空间想象力有限），所以在产品抽象设计时，喜欢用工具（如Axure）画图的方式进行思考与设。

比如像上述案例中，简单画一个不同方案的时段关系图（或直接画实体关系图），对比不同方案的优劣。

相关案例可见：KISS原则：SaaS产品设计最重要的原则（上）

第五，采用刻意练习的方式，复盘每次产品抽象设计的过程，形成肌肉记忆。

抽象设计确实比较抽象，就像对它的学习与掌握一样。所以唯一可分享的点就是建议你进行刻意练习。

比如上述案例就是我对自己设计的一次复盘，而写这篇文章的过程，就是一种刻意练习。

刻意练习是痛苦的（因为它需要调用你的脑力，让你的神经元之间进行强行交流），它也是畅快的（因为互不相识的神经元之间会产生火花，让你的大脑活跃，产生多巴胺）。