目前在产品的现有字段中，只需要用到“且(&)”和“或(|)”2种就能满足需求，未来根据新增字段类型，再决定增加“非(!)”条件。

（3）“且”、“或”用法示例：

A且B =A&B =同时满足A和B规则，即为匹配。

A或B =A|B=只要满足A或B其中一项规则，即为匹配。

另外，在设计过程中，逻辑语言存在一定使用门槛，需要尽可能降低商家在设定时的难度。

三、方案设计

经过讨论，决定基于原有预约资料表单业务增加「自动化事件」。预约资料表单已被大量商家投入业务运营，对于不需管控的商家，默认设定为“不限制”。

商家可以依据运营需要，自行设定自动化事件规则表达式并启用。

（1）单项规则

单项规则时，比如限制身份证是“”开始的规则，可以这样表达：({身份证}[以…开始]{})。

（2）“且”组合规则

多项“且”规则时，比如限制身份证是“”开始，并且不含“”的规则。可以这样表达：({身份证}[以…开始]{})且({身份证}[不含]{})…。

（3）“或”组合规则

多项“或”规则时，比如限制身份证以“”开始，或者以“”开始的规则。可以这样表达：({身份证}[以…开始]{})或({身份证}[以…开始]{})…。

（4）混合组合规则

多项“且”和“或”规则时，比如限制身份证是“”开始，并且不含“”。或者身份证是“”开始，并且不含“”的规则。可以这样表达：({身份证}[以…开始]{})且({身份证}[不含]{})或({身份证}[以…开始]{})且({身份证}[不含]{})。

从上面的讲解可以看出，随着组合规则的增加，设定和阅读规则变成一件极具难度的事情，对于使用者来说，有很高的学习成本。

经过使用者测试发现，基本超过3项后都在“或”组合规则的时候，会对规则阅读和理解产生障碍，接下来问题就是考验实际UI界面展示的时候如何进行交互表达。

在经过市面上5款类似产品设计后，提出了 A/B/C 3种设计方案。通过给定设定任务和阅读任务，对 3 位使用者进行易用性测试，大致的结论如下。

方案A：直接条列式设定规则，对于不同的规则可以根据需要选择“且”和“或”组合方式。方案虽然满足可用性，但是并没有解决使用者在使用上设定和阅读的障碍。

方案B：在方案A的基础上，拆分为规则组，把规则拆分成更小的单元来看待。规则组很好解决了设定的问题，但是对于阅读来说，还是存在不小的问题。比如，在第一个规则组后再使用“且”进行组合，那就变成两个组其实是一个组，在阅读上并不直观。

方案C：在前面总结的问题，最后决定采用规则组内只可使用“且”，规则组间只可使用“或”组合。对于专业人士来说，设置复杂的规则表达式会变得重复。但是对于普通人来说，却是更加直观和直觉。

所以，在规则表达式设定上，采用“方案C”。

预约资料表单在实际使用过程中，会面对业务需要进行表单内容的调整。由于自动化事件是关联在表单之上，会受到表单内容的约束。

当修改预约资料表单的字段影响自动化设定规则时，系统需要进行检查并引导使用者进行操作。针对表单修改影响规则，可以在“?”预览，并可以快速一键排除。如果不确定，可以暂不处理。

又或者点击“马上更新”进入自动化设置页进行调整，对于影响的规则进行突出显示，原则上还是希望能最大程度简化使用者的操作难度，提高操作效率。

四、总结

对于B端产品，特别是对于SaaS产品来说，接收到客户的需求，通常信息是比较片面的。客户只会告诉你需要什么，设计产品的能力不能只站在单个需求上来考虑问题，需要抽离出来看“某一类能力”或“某些业务场景”，结合业务价值一起进行判断。

文章来源：《机械工程与自动化》 网址: http://www.jxgcyzdhzz.cn/zonghexinwen/2022/0315/1313.html