微步智能共享 SaaS 5.0

版本越多，相似任务的做法越不一样

共享设备后台从 3.0 迭代到 4.0，各模块都能完成业务，类似的操作却逐渐分化。到了 5.0，我把反复出现的任务重新归类，整理为可复用的框架、模式和组件，给后续业务留出扩展空间。

先搭框架，再定模式，最后做组件

第一层决定页面放什么、怎样布局。第二层处理反复出现的工作，比如查询记录、控制显示和填写表单。第三层才细化按钮、表格、输入框和反馈。这样，设计人员可以从一项实际任务逐层找到可用的部件。

先找出后台反复出现的页面

设备、订单和商家各有一套业务规则，操作人员却会反复做相似的事：看概况、查记录、处理详情。每个模块重新安排一次入口，用户就要重新学一次。

我先归纳出六类页面容器，分别承载统计、摘要列表、详情、分步操作、结果反馈和信息填写，再调整水平导航。新业务可以从最接近的页面结构开始设计。

把查找、核对和操作放进同一张列表

在设备管理里，运营人员往往先筛出离线设备，核对型号和状态，再处理某一台。订单、用户和账务列表也有相似的节奏。

我把记录集分成过滤条件、统计与操作区、表格三部分。每个业务可以增减少量控件，查询和处理记录的位置保持一致。

让运营人员决定表格里看什么

排查离线设备和查一笔订单，需要对照的字段不同。我把记录集整理为筛选条件、统计与操作、数据表格三个区域，让位置保持稳定，把变化留给字段。

字段少时可以直接勾选。字段多时，用户可以搜索、分组查看，也能在已选列表里拖动排序。必显字段有清楚的标记，避免调整后丢失识别记录所需的信息。

给模糊搜索加上可选的限定条件

知道订单编号时，输入编号就该找到记录；只知道设备状态和日期时，则需要组合条件。我在同一套搜索模式里安排关键词、单选、多选和日期，让简单查询保留一个输入框，复杂查询再展开高级筛选。

按录入任务组织表单

新增设备时，设备 ID、所属加盟商和套餐分别回答不同的问题。我按基本信息、产品信息和套餐信息分组，把提交操作放在填写路径的末端。字段多的流程再拆成步骤，明确当前位置和下一步。

用户能从页面标题判断自己在哪里

顶部保留子系统切换、面包屑和账户入口，侧边导航承载当前子系统的功能。进入多级详情后，面包屑交代来路；同时打开多个后台页面时，浏览器标签上的页面标题也能帮助辨认。

把表格的阅读习惯写进组件

以订单表为例，用户要沿着名称找记录，再纵向比较金额，最后操作某一行。我把文本设为左对齐、金额设为右对齐，统一状态标签和操作列的位置。

组件同时规定单元格的留白、行高、列间距和固定列。后续页面沿用这些细节，开发和设计就能把讨论集中在具体业务上。

把长图文分成可以扫读的层级

以酒店设备产品介绍为例，我把产品线、具体设备和说明文字分层。三级标题依次使用 28、24、20 像素，正文使用 14 像素，图片注释使用 12 像素。读者可以先扫标题，再停在需要的设备说明上。

让按钮表达操作的轻重

新增设备、导出和批量入库可能出现在同一页，但重要程度不同。我按主要、次要、危险、文字等用途整理按钮，定义四种尺寸，以及默认、悬停、按下、聚焦和禁用状态。

为每一类数据选合适的输入方式

订单需要日期，设备数量需要数字，附件需要上传区域。我把常用控件按输入和选择方式整理，并统一标签、输入区域和辅助提示的位置。文本域给出字数，上传区说明点击、拖入以及文件限制。

操作完成以后，用户在哪里看到反馈

页面内的警告附着在相关内容旁，通知负责告知处理结果，需要用户决定的操作则使用模态弹窗。我分别整理了反馈的位置、标题、说明和操作区域，并区分成功、警告和错误状态。

在版本对比里检查设计系统

新版规范应用到运营看板、设备和订单等页面后，项目对比了 4.0 与 5.0 的体验评分。体验平均分从 2.5 提高到 3.9，满意度从 20% 提高到 56%，相差 36 个百分点。

用下一个业务场景检验系统

这次重构给我留下的判断标准是：遇到一个新场景，团队能否用已有框架和模式做出可实施的页面？只有把组件放回真实工作流程，一致性、业务覆盖范围和维护成本才有具体的检查对象。