通过深入探讨如何将复杂的功能和规则抽象成简洁易用的设计,本文带您领略抽象能力的丰富性和广泛应用,从班次异常规则到排班规则设计,揭示如何通过高阶抽象思维提升设计的灵活性和扩展性,为B端产品设计提供持久的解决方案。
![](http://p2.img.360kuai.com/t110df81bbc96cd9d92651bb201.jpg)
上篇《功能设计:如何将复杂的功能抽象成简洁易用的设计?》探讨了在功能设计中运用抽象能力的方法,并通过班次设计的两个案例展示了其应用。
虽然这些案例展示了抽象能力的重要性,但个人认为它们不足以全面体现抽象能力的丰富性和应用范围。
因此,计划在接下来的文章中,先插入一期内容,然后再继续探讨实体设计和产品架构等主题。
一般来说,功能设计的抽象可以分为两类:一类是我们最常见的对功能本身的抽象(比如班次、排班、加班、假期等),另一类是常被我们忽略的对功能规则的抽象(如班次规则、排班规则等)。
前者是之前反复重点分享的内容,后者则是本文想补充分享的内容。
案例1:如何设计班次异常规则,保持考勤灵活性?
场景:客户A考勤规则是:员工每月有3次迟到或早退机会,每次不超过30分钟。超出30分钟,扣款标准如下:迟到或早退1-10分钟,扣10元;11-30分钟,扣20元;31-60分钟,扣50元。迟到或早退超过1小时但不超过4小时,按旷工0.5天计算;超过4小时的,按旷工1天计算。
1. 方案1:通过扣款规则自定义阶梯实现扣款逻辑统一由扣款规则,按异常类型(即迟到/早退/缺卡/旷工)进行阶梯式扣款规则的配置。
![](http://p0.img.360kuai.com/t110df81bbc92bcd135f2d784bf.webp)
扣款逻辑由考勤项目关联对应自定义字段,通过公式单独配置字段的计算逻辑实现。
![](http://p0.img.360kuai.com/t110df81bbc603b726673a53c82.webp)
![](http://p2.img.360kuai.com/t110df81bbc0664066759abe2a8.webp)
方案1是一阶抽象(即只抽象扣款规则本身),而方案2是二维抽象(即对扣款规则本身抽象的同时,还对规则的规则进行抽象)。
![](http://p2.img.360kuai.com/t110df81bbca8d68b37f51d41a4.jpg)
方案1由于规则简单,易于理解和实施,但缺乏应对复杂情况的能力,且难以适应未来可能的变化(即无法有效扩展)。方案2虽然初始理解和使用成本较高,但其设计考虑了多种情况和未来的扩展性,能够更好地应对复杂的工作场景和变化的需求。
比如员工每月有3次15分钟内的免费迟到机会。第4次及以后,1-15分钟按15分钟扣款,超过15分钟按实际迟到时间计算扣款。例如,迟到30分钟,则按30分钟除以工作日480分钟,即0.5小时旷工扣款,扣除相应的计薪天数。
或员工每月有3次10分钟以内的迟到或早退免责机会。超过3次,每分钟迟到或早退将按2元扣款。若单次迟到或早退超过2小时,将按每小时旷工计算扣款。
方案1就无法扩展支持上述复杂场景,而方案2却可以。
案例2:如何设计排班规则,让排班灵活且合规?
场景:客户B是一家门店连锁企业,面临一线员工多为兼职和小时工,工作时长依客人数量和用餐时长而定,按实际工作时长支付工资。
方案1:单一排班规则抽象,仅进行合规限制- 划线排班(下图一):默认每天00:00-24:00之间,允许店长自由给员工安排工作时长,且无论时长数,最终都统计为1天。
- 排班规则(下图二):可直接按每日、每周、每月限制/提醒排班时长、排休天数等;
![](http://p1.img.360kuai.com/t110df81bbcc5e4eaffb5638326.jpg)
![](http://p0.img.360kuai.com/t110df81bbcdd856de00ab73f13.jpg)
- 划线排班配置规则(下图一):可配置划线排班时,每天的开始与结束时间、每天的统计天数、休息时数、打卡范围、是否加班等;
- 排班规则配置规则:可单独配置每个排班属性的规则(下图二),再将N个配置规则灵活组合后(下图三),作用于对应排班员工。
![](http://p1.img.360kuai.com/t110df81bbc51d891a5eab0fa53.jpg)
![](http://p2.img.360kuai.com/t110df81bbcdc683070b5befc8c.jpg)
![](http://p1.img.360kuai.com/t110df81bbcde75640936baf051.jpg)
方案1是一阶抽象(即只抽象功能本身的规则),采取“可见即可得”和“能默认就默认”的方式,对使用者和设计者来说,都是直来直往,容易理解。不过它有“致命”的不足之处,不够抽象而导致灵活性与扩展性不足。
方案2是二阶抽象(既抽象功能本身规则,又抽象对功能规则的配置规则),采取“极度抽象,保持配置化”的方式,对使用者的使用有要求,却足够灵活,所支持的场景数与扩展性更强。它的“不足”之处是用户使用的理解成本和研发成本相对高。
![](http://p1.img.360kuai.com/t110df81bbc96265855c86cb913.jpg)
比如划线排班时,门店员工上班时间大多是6:00-22:00(默认00:00-24:00体验不佳),且可能上半天或全天(默认1天不合理),方案1就不能灵活满足,也不便于扩展,而方案2就可以灵活满足。
同理,排班的合规性校验规则也类同。
方案1的排班规则是一个整体(即排班方案与排班规则是1对N的关系),无法有效区分工作日/节假日等限制时长,也无法灵活配置以及扩展。比如只限制工作日的排班时长,或新增一个每月连续排休天数限制等。
方案2的排班规则是N个排班规则配置项的组合(即排班规则与排班规则配置项是N对N的关系),用户自由组合规则项即可实现需求。同时,如果有新增项时,可快捷增加对应的【对象】即可。
![](http://p0.img.360kuai.com/t110df81bbc10c4f79d3aba7f64.jpg)
三、经验分享
1. 收集多样化的案例对于功能设计至关重要。丰富的场景不仅有助于揭示需求的多样性,还能引导设计者进行更深入的抽象思考。特别是对于那些缺乏想象力和架构能力的人来说,每个场景都是具体的学习材料,场景间的差异能激发更高级别的抽象设计。
2. 即使最终选择一阶抽象方案,也应经历二阶抽象的设计过程。一阶抽象直观、易于理解和实施,但缺乏灵活性和扩展性。相比之下,二阶抽象虽然不那么直观,却能提供更高的灵活性和可扩展性,为未来的变化和复杂需求留下空间。
3. 切忌追求需求上线的速度,而放弃产品的扩展性。B端产品设计是一场马拉松,考验的是持续性和耐力。急于求成地将长期策略转变为短期冲刺,把马拉松比赛变成短跑,结局就是陷入反复重构的“魔怔”里。
四、写在最后
本文是【抽象能力:SaaS产品经理的核心能力】主题的第三篇,前两篇是:
后续会继续这个主题,分享实体设计、产品架构、产品规划等。敬请期待,也非常欢迎留言交流。
专栏作家
邢小作,微信公众号:邢小作之家,人人都是产品经理专栏作家。一枚在线教育的产品,关注互联网教育,喜欢研究用户心理。
本文原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自 Unsplash,基于CC0协议
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。
友情提示
本站部分转载文章,皆来自互联网,仅供参考及分享,并不用于任何商业用途;版权归原作者所有,如涉及作品内容、版权和其他问题,请与本网联系,我们将在第一时间删除内容!
联系邮箱:1042463605@qq.com