这些细节设计SaaS系统务必要统一

满足用户业务流程的需要是B端SaaS系统设计的首要目标，也很容易在一些细节设计上没有C端产品那么严谨。

而且一些庞大的SaaS系统需要多位产品经理协作完成，很容易在一些基础术语命名和细节交互上不一致。

虽然这些细节不会影响系统功能的使用，甚至一些用户对此都不敏感。但是作为逻辑严谨的产品经理，以下这些细节设计一定要在系统层面保持统一，最好作为系统级的产品规范来要求。

一、通用操作按钮命名统一

（1）“增删改”操作按钮

“增删改”我比较习惯的命名方法是新增、编辑和删除。

新增：还有叫添加、创建的比较多。

编辑：通常还可以叫做“修改”

删除按钮一般没有别的名称。

（2） 内容保存和取消按钮

对于内容保存的操作按钮，我比较习惯使用“保存”和“取消”的叫法。有的系统不叫做“取消”，叫“返回”。

（3）二次确认框操作按钮

操作的二次确认框的按钮，常用的有“确认/取消”、“是/否”、“继续/返回”等，个人比较推荐“确认/取消”的组合。

（4）停启用状态及操作按钮

停启用的状态及操作按钮，普遍统一使用的是“启用/停用”。有时候我们会看到有有些系统的状态叫“启用中”、“生效中”、“在用”等。“停用”的状态也叫作“已停用”、“停用中”、“已禁用”等。

（5）查询按钮

我个人偏爱“查询”，还有叫作“搜索”、“检索”、“查找”等。

（6）登录/退出

还有比较常见的是“登入/登出”。

二、数据字段命名统一

（1）日期 vs 时间

XX日期和XX时间的栏位命名，建议采用以下原则：

内容只显示日期的栏位叫“XX日期”：e.g. “就诊日期：2021-3-26”；

日期加时间或者只显示时间的叫“XX时间”：e.g. “就诊时间：2021-3-25 15。

（2）类别、分类和类型

在标准词语的释义上，这三个词各有侧重点，这里我只介绍一下我个人的理解和使用习惯。

类别和分类在词义上就明确的将事物进行归类的意思，相对来说类型只是强调事物的共同点和特性。类别强调将事物按照某种标准进行归类，分类则只要按照某种逻辑进行归类就可以。

我个人使用的话，如果有确定的标准，则用类别；如果不是依照某种标准进行的归类，则用分类；在已有类别和分类之外，需要按照其他特性进行区分，则使用类型。所以我个人基本上是按照类别＞分类＞类型的顺序在使用。

（3）同意/批准/通过、拒绝/驳回/不通过

这些按钮都是在审批流程相关的功能经常用到的。根据需要审批的业务场景，特定的描述可能更加合适。

但我个人倾向还是在术语上进行统一，比如我基本上会使用比较通用且语义上比较柔和的“通过/不通过”。

这样的好处是在做报表和数据分析时，不需要先对这些描述进行对照，直接根据这两个状态值就对整个系统的流程结果进行筛选。

三、专业术语统一

所做的SaaS系统是哪个专业领域，对应的专业术语一定要准确和统一。拿我熟悉的医疗系统举个简单的例子，最常用的“医生”字段，我们不能出现像“大夫”、“专家”、“治疗师”等通俗表达，而且在职称和官方表述中都使用“医师”。所以在系统层面最好统一使用“医师”。

四、页面命名规范统一

页面的命名，建议遵循以下两个原则：

（1）业务功能页面直接以业务本身命名：“西药字典”、“出差申请”，以名词或者动宾结构为宜。

（2）维护界面：单纯的数据维护功能界面叫“xxx维护”，带有其他功能的综合性功能界面可以叫“xxx管理”。

五、基础交互统一

（1）查询：下拉框筛选选项，条件为空时查询全部 or 选择为“全部”选项时查询全部数据。

（2）查询：查询条件是都有单独标题 or 统一使用暗提示。

（3）操作：哪些状态变更操作需要有二次确认框，系统需要有统一的规范，一般包括删除、启用、停用等。

提示语可以采用通用的文案，这样也就不会因为页面其他元素的调整而需要调整提示框文案。例如：请确认是否要删除所选内容？

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！