都说B端原型难，其实不是难在控件多、页面复杂，而是难在它必须同时说清楚四件事：页面怎么排、操作按什么规则走、异常状态怎么兜底、跨页面数据怎么联动。少交代任何一层，评审时就多出几个“按经验补全”的坑，最后在开发或测试阶段集中爆发。本文用“结构、规则、状态、闭环”四层框架，带你拆解数据看板、查询列表、详情编辑、流程审批和权限配置五类高频后台页面，轻松入门B端后台设计~

一、先建立四层原型框架

很多团队拿到需求，第一步就是拖入导航栏、表格和按钮，花半天拖出一个“看起来很像后台”的界面。像，不等于想清楚了——摆出大厨的架势，不代表菜真的好吃。更稳妥的做法，是先用四层框架把信息理清楚，再决定页面长什么样：结构、规则、状态、闭环。

1、结构：用户先看什么，再做什么

拿查询列表举例，用户的核心任务不是“把数据都看一遍”，而是先缩小范围、再定位目标、最后执行操作。筛选区、结果区、操作区、分页区的层级都要服务这条路径。画结构前，先回答三个问题：

• 用户进入页面后，最先需要确认什么？

• 完成当前任务所需的主要操作是什么？

• 哪些信息可以折叠、下钻或放到二级页面？

重要信息放更显眼的位置，但“重要”由业务任务说了算，不是组件尺寸说了算。

2、规则：什么条件触发什么结果

按钮能点，不等于交互定义完整。B端操作几乎都带条件：特定状态才能编辑、同类记录才能批量处理、日期不能超出业务允许区间。原型至少要说清楚：

• 谁可以操作；

• 在什么条件下可以操作；

• 操作会影响哪些数据；

• 系统如何反馈结果；

• 是否需要二次确认。

规则可以写在批注、交互说明或流程图里，颗粒度取决于业务制度，不必为了“高保真”把所有逻辑塞进一个页面。

3、状态：不要只画成功结果

真实系统不会永远有数据、永远加载成功、永远提交通过。能拿去评审的B端原型，至少要覆盖初始、处理中、成功、失败、空数据、无权限这些状态。状态表达也不能只靠颜色。审批的黄、异常的红，设计者看着直观，但开发得知道哪个黄是审批中、哪个红是真报错——文字和图标更靠谱。

4、闭环：操作后，前后页面发生了什么

从列表进编辑页，保存后返回详情页，字段更新了吗？列表状态、更新时间和操作入口同步了吗？审批通过后，待办数量、流程记录和业务状态一起变了吗？只画“点击后跳转”，等于没表达业务闭环。触发条件、目标页面、反馈方式和数据变化要连起来检查。

这里推荐一款好用的B端设计工具，摹客，它是一套专注于B端产品设计开发的协作设计平台，包含了原型设计软件，UI设计工具和协作交付平台等模块。其原型设计工具摹客RP，是一款在线原型设计工具，功能强大而全面，能快速构建交互式原型。此外，摹客RP使用方便，学习曲线低，新手产品经理也可以快速上手。摹客RP官方网站还有丰富的B端原型模板例子，一键导入即可编辑，不用从头开始画原型，大大提升了原型效率。使用地址：https://www.mockplus.cn/rp

二、数据看板

数据看板不是图表陈列墙，它先回答“当前发生了什么”，再帮用户判断“哪里值得继续看”。1、先确定从概览到下钻的结构常见看板结构：

1. 页面标题、数据范围与更新时间；

2. 时间、组织或业务范围筛选；

3. 关键指标卡；

4. 趋势图、分布图或对比图；

5. 异常提示和下钻入口。

关键指标优先展示与业务问题直接相关的数据：运营看板盯新增、活跃和转化，管理看板更关心目标完成和异常区域。原型要标出指标优先级，而不是把所有指标做成一样大的方块。图表还要承担定位作用：发现区域异常，能不能点击下钻？下钻页继承哪些时间、组织条件？都要交代清楚。2、把指标口径写进原型“订单数”“活跃客户”“完成率”，听上去都是熟面孔，实际统计方式可能五花八门。原型至少要说明：

• 统计对象是什么；

• 时间范围如何计算；

• 是否去重；

• 是否排除取消、删除或测试数据；

• 数据更新频率与最近更新时间。

口径不一定要展示给终端用户，但评审稿里必须找得到。否则同一张图，产品、开发和数据团队能解读出三个版本。3、覆盖数据未就绪的状态看板要覆盖加载中、无数据、部分失败等状态。无数据不等于系统出错——可能筛选范围没记录，也可能数据还没接入，提示和下一步完全不同。部分指标失败时别让整页消失，要明确哪些模块不可用、能否重试、其他数据能否继续看。

三、查询列表：把查询条件与结果变化连起来

表格是后台高频场景，看着只是行列铺开，实际连着查询、排序、分页、选择和批量操作。1、先定义查询链路筛选条件变了，是立即查询还是点“查询”提交？切换筛选项会不会重置页码？清空条件恢复默认排序吗？这些都得写明白。远程数据还要补充：

• 查询参数如何传递；

• 翻页后是否保留筛选和排序；

• 每页条数改变后回到哪一页；

• 排序由当前页前端处理，还是由服务端对全部结果排序；

• 多个排序条件是否可以同时生效。

数据量大时只对当前页做前端排序，用户看到的就不是全量顺序。排序方式不是技术细节，而是产品规则的一部分。2、按任务安排表格字段字段不是越多越完整。优先保留能识别对象、判断状态、执行操作的信息；低频字段放详情页或做成可配置列，别把全部字段压进一张表。操作列要结合记录状态：已归档只能看、处理中不能删、无权限不给编辑入口。不可用操作是隐藏还是禁用，要统一口径并写明原因。

3、补齐空列表与批量操作空列表不能只是一张白表，原型要区分四种情况：

• 系统里还没有任何数据；

• 当前筛选条件没有匹配结果；

• 数据加载失败；

• 用户没有查看权限。

对应的下一步分别是新建、清空筛选、重新加载或申请权限，写清楚，开发才不会自由发挥。批量操作要画明白选择范围：勾选的是当前页还是全部结果？翻页后选择保留吗？部分失败是整体回滚还是展示明细？这些直接决定测试用例怎么写。

四、详情与编辑：区分可看、可改与不可改

详情页负责呈现，编辑页负责修改。两者可共享布局，但不能默认共享权限和规则。1、给字段划分三种属性

• 只读信息，例如系统编号、创建时间；

• 可编辑字段，例如名称、联系方式；

• 受权限或状态控制的字段，例如归属组织、审核结果。

划分要落实到控件上：只读字段用纯文本、只读输入框还是禁用控件，看用户要不要复制、要不要理解来源；受权限控制的字段，要注明什么角色、什么状态下能改。2、在输入过程中尽早反馈问题表单要有合理默认值、格式示例和必要提示，校验别全堆到提交后爆发。原型要明确必填项、长度限制、格式要求和错误提示位置。字段联动也要画出来：选某类业务新增哪些字段，切换组织清空哪些选项，改关键字段要不要重新校验。涉及数据丢失或大范围影响的联动，还得给确认或说明，不能闷头改。3、画出提交前后的完整状态编辑流程至少要覆盖六个环节：

1. 初始值加载；

2. 用户修改字段；

3. 本地校验；

4. 提交中；

5. 提交成功或失败；

6. 保存后详情及列表更新。

提交中按钮要不要禁用？失败后已填内容保不保留？改到一半直接关页面，要不要弹“未保存离开”提示？这些细节都要在原型里表达。保存成功也不等于流程结束：详情页显示最新信息，列表的关键字段和更新时间要同步。数据还要审核的话，就展示“待审核”，而不是直接显示成最终生效。

五、流程审批：不能只画“通过”按钮

审批页面的主角不是按钮，是任务怎么沿节点流转。只画详情加“通过”“驳回”，会漏掉大量决定系统行为的规则。1、同时画业务对象与流程进度审批人一边看申请内容，一边判断自己卡在哪个节点。页面要包含：

• 申请摘要与关键字段；

• 申请人、提交时间等上下文；

• 当前审批节点和流程进度；

• 历史操作记录；

• 当前用户可执行的操作；

• 审批意见或附件区域。

流程进度要表达节点顺序、当前状态和历史结果。状态别只靠颜色区分，要有“审批中”“已通过”“已驳回”这样的文字语义，颜色会骗人，文字不会。2、按业务制度定义分支待提交、审批中、通过、驳回、撤回、转交、失败……常见状态不少，但不用全上，以真实制度为准。重点回答这几个问题：

• 驳回是退回上一节点，还是退回申请人；

• 修改后重新提交是否重走全部流程；

• 发起人何时可以撤回；

• 转交后原审批人是否仍可处理；

• 多人审批是任一通过、全部通过，还是按顺序处理；

• 审批对象发生变化后，当前审批是否失效。

这些规则适合先用流程图理一遍，再映射到页面操作，比硬画省事得多。3、检查跨页面数据变化审批通过，至少影响待办、已办、申请详情、业务对象状态和通知；驳回后，申请人从哪看原因、在哪修改、重新提交后怎么展示，也要闭环。操作失败了，页面不能直接跳到“已处理”。要保留当前任务、给出失败反馈、说明能不能重试，审批原型才算真正闭环。

六、权限配置：勾选框背后是访问边界

权限设计常被简化成一棵菜单树：管理员勾一勾，保存。但B端权限不只决定能不能看到功能，还决定能看到哪些数据、能执行哪些操作——勾选框背后是访问边界。1、先分清四类对象基于角色的权限管理，核心是用户、角色与权限。原型里要分别表达：

• 用户：谁在使用系统；

• 角色：一组职责或访问能力；

• 权限项：可以访问的资源或执行的操作；

• 授权结果：某个用户最终获得了什么权限。

别把角色名称直接当成权限。一个用户能不能挂多个角色？权限叠加按并集、优先级还是别的规则？答案取决于业务制度，不能留给评审者现场补全。2、分开表达功能权限与数据范围功能权限回答能做什么（查看、创建、编辑、删除、导出），数据范围回答能对哪些数据做（仅本人、本部门、指定组织或全部）。混在一组勾选框里，越权风险很难被发现。更清晰的做法是分开设置功能授权和数据范围，再给出可理解的授权结果摘要。比如某角色有“查看客户”权限，但数据范围只限本部门——管理员应看到最终效果再确认，而不是自己推演。3、覆盖继承、半选和保存反馈树形权限常有父子级：勾选父级是否自动选全部子级？取消子级后父级怎么显示？新增子权限，已有角色会不会自动获得？都要写清楚。权限修改是立即生效还是重新登录后生效，按实际规则标注。保存失败要保留勾选状态并提示原因，别让管理员含着泪重新配一遍。最后检查无权限状态如何呈现：菜单隐藏、按钮禁用、页面拦截还是列表为空？配置页和实际使用页的表现必须一致，不然管理员以为配好了，用户那边还是另一个世界。

B端原型不需要把所有后台规则都做成可运行系统，但关键判断必须有据可查。搭好“结构、规则、状态、闭环”的框架，再配上一把顺手的工具，你就会发现，B端原型入门，原来这么简单！

Powered by Froala Editor