B端项目最常见的范围误差，不是少画了几张页面，而是需求里根本没有写清角色、权限、数据范围、业务状态和异常恢复。设计团队如果直接根据页面清单开工，视觉稿可能很快完成，开发阶段却会不断发现规则缺口。
因此，B端UI/UX设计的真实交付对象不是“后台页面”，而是一套让业务、产品、设计和研发可以共同执行的界面规则。ISO 9241-210将以人为中心的设计视为贯穿交互系统生命周期的活动，这一点在复杂企业软件中尤其重要。
01 B端设计和普通界面设计，差别不在视觉风格
消费类产品通常围绕少数高频任务优化，B端系统则需要同时处理组织结构、岗位职责、审批链、数据权限、批量操作和长期使用效率。同一个“客户详情页”，销售、主管、财务和管理员看到的字段与操作可能完全不同。
比较维度 | 消费类产品常见情况 | B端系统常见情况 |
|---|---|---|
主要目标 | 降低首次使用门槛、提升转化和留存 | 提高任务效率、减少业务错误并保证规则执行 |
用户结构 | 角色较少，权限差异有限 | 多角色、多组织、多层级权限并存 |
操作频率 | 单次任务短、低频或碎片化 | 长时间使用、高频录入、查询和批量处理 |
数据表达 | 内容卡片和简单列表较多 | 复杂表格、筛选、统计、关联对象和审计记录 |
状态数量 | 正常、空、加载、失败等基础状态 | 业务状态、审批状态、同步状态、异常和恢复路径 |
成功标准 | 注册、购买、互动、留存 | 完成时长、错误率、培训成本、数据质量与处理能力 |
所以，B端设计不能从“需要多少页”开始，而应先回答：系统里有哪些业务对象，谁在什么条件下处理它们，信息如何变化，发生错误时怎样恢复。
02 完整B端UI/UX服务的12个模块
模块 | 主要工作 | 常见交付 |
|---|---|---|
1. 业务目标与范围 | 明确系统目标、关键指标、版本边界和约束 | 项目Brief、范围表、优先级和风险清单 |
2. 领域与业务对象 | 梳理客户、订单、合同、任务、设备等对象及关系 | 对象关系图、术语表、关键规则 |
3. 用户角色与任务 | 识别岗位、工作场景、频率和目标 | 角色地图、任务清单、场景说明 |
4. 权限与数据边界 | 定义可见、可编辑、可审批、可导出和数据范围 | 角色权限矩阵、字段权限和越权反馈 |
5. 流程、状态与异常 | 覆盖主流程、审批、失败、中断、撤销和恢复 | 流程图、状态机、异常清单 |
6. 信息架构与导航 | 组织模块、层级、全局入口和跨对象跳转 | 架构图、导航模型、页面清单 |
7. 线框图与交互原型 | 验证任务顺序、信息层级、操作反馈和规则 | 低保真、高保真原型与交互说明 |
8. UI与数据可视化 | 建立视觉层级、表格、图表、密度和语义色 | 关键页方向、全量界面、适配稿 |
9. 设计系统与组件 | 沉淀Token、基础组件、业务组件和模式 | 组件库、状态、规范和版本说明 |
10. 可访问性与多终端 | 考虑键盘、焦点、对比、缩放与响应式 | 检查清单、响应式规则、修正记录 |
11. 可用性验证 | 用任务测试发现理解、效率和错误问题 | 测试计划、问题等级、迭代建议 |
12. 研发协作与验收 | 交付标注、答疑、设计走查和上线核对 | 交付包、走查记录、验收清单 |
这些模块不一定由一家供应商全部承担，但每一项都必须有人负责。最危险的状态不是“项目没做用户研究”，而是团队默认别人已经做过。
03 四个最容易被漏掉的核心范围
角色不是一张用户画像，而是一组可执行边界
B端角色需要明确岗位、组织层级、目标、操作频率、数据范围和审批责任。仅写“管理员、普通用户”通常不足以支持真实业务。
权限层面 | 必须确认的问题 |
|---|---|
模块可见性 | 该角色能否进入模块，还是只能通过任务入口访问 |
记录范围 | 能看本人、团队、部门、区域还是全部数据 |
字段权限 | 敏感字段是否隐藏、脱敏、只读或按条件开放 |
操作权限 | 新增、编辑、审批、导出、删除、转交分别由谁执行 |
状态权限 | 在草稿、待审、已完成、已关闭等状态能做什么 |
越权反馈 | 隐藏、禁用、解释原因、申请权限还是联系管理员 |
状态数量常常比页面数量更接近真实工作量
同一个页面可能存在加载、空数据、部分数据、无权限、接口失败、数据冲突、锁定、只读、编辑、批量处理和保存成功等十几种状态。报价只统计“页面”时，这些状态往往在开发阶段才被发现。
复杂表格需要同时设计阅读、操作和响应式
表格不是把字段横向排开。设计需要决定关键标识、列优先级、筛选与排序、批量选择、固定列、编辑方式、错误提示、导出和小屏处理。SAP Fiori建议在窄屏保留识别项和关键属性，将低优先级信息移入展开区域，而不是简单把所有列压缩到不可读。
设计系统必须包含业务模式，而不仅是按钮和输入框
成熟B端系统通常还需要审批、任务、权限、导入、批量处理、数据状态和异常恢复等业务组件。组件库如果只整理基础视觉样式，仍然无法减少后续页面差异。
04 三种常见服务范围怎么选
服务层级 | 适合情况 | 通常包含 | 主要风险 |
|---|---|---|---|
纯UI执行 | 流程、原型和规则已经稳定，只需要视觉统一 | 视觉方向、界面视觉、基础组件和交付 | 上游原型若有缺口，UI阶段很难补救 |
完整UX/UI | 新模块、改版或核心流程需要重新梳理 | 范围、流程、原型、UI、组件和开发走查 | 需要产品、业务和研发持续参与 |
系统级体验改造 | 多角色、多模块、历史系统或设计不一致严重 | 研究、领域建模、权限、全局架构、设计系统和分阶段落地 | 周期较长，需要治理负责人和明确版本策略 |
05 每个阶段应该交付什么、如何验收
阶段 | 关键交付物 | 验收重点 |
|---|---|---|
范围与诊断 | 目标、角色、模块、问题、约束和计划 | 所有参与方对目标、边界和优先级理解一致 |
业务与流程 | 对象、权限、流程、状态和异常 | 规则可执行，关键例外和责任人明确 |
原型 | 关键任务、页面结构、交互和说明 | 核心用户能完成任务，开发能理解规则 |
UI与组件 | 全量界面、状态、组件、响应式和标注 | 视觉一致、状态完整、组件可复用 |
测试与修正 | 任务脚本、发现、问题等级和修正结果 | 高风险问题关闭，剩余问题有明确处理计划 |
研发交付 | 源文件、组件、资源、说明和走查记录 | 开发可访问、可复现、可追踪，差异被记录 |
验收不要只看设计稿“是否好看”。更有效的方式是用关键任务验收：某个角色能否在规定条件下找到信息、完成操作、理解结果，并在失败后恢复。
06 哪些工作通常不应该默认包含
- 完整业务咨询、组织流程再造或产品经理长期驻场；
- 后端规则、数据库、接口和技术架构设计；
- 正式安全测试、渗透测试、法规审查和隐私法律意见；
- 大规模用户招募、线下调研、差旅和第三方研究费用；
- 全部文案撰写、数据治理、图表口径定义和历史数据清洗；
- 前端开发、组件代码、上线运维和持续运营；
- 需求确认后新增模块、角色、端别或整体方向重做。
这些内容可以加入项目，但必须在报价和合同中单独写明责任、费用、周期和验收方式。
07 合成情景：一个CRM改版为什么不能直接重画
某销售管理系统最初提出“界面老旧，希望把40个页面重新设计”。初步梳理后发现，真正问题是销售、主管和财务对客户归属、折扣审批和回款状态理解不一致；同一字段在三个模块中使用不同名称，异常订单也没有恢复路径。
如果直接重画40页，视觉会更统一，但规则冲突仍会被保留下来。更合理的顺序是先建立客户、商机、合同和回款的对象关系，再定义角色权限与状态，选取三个高频流程完成原型验证，最后扩展到全量界面和组件库。
08 如何准备需求，才能获得可比较的报价
需要提供 | 最低有效信息 |
|---|---|
业务背景 | 系统服务什么业务、当前处于新建还是改版 |
用户与角色 | 主要岗位、组织层级、使用频率和数据范围 |
核心任务 | 最重要的3–5个流程及现有问题 |
系统范围 | 模块、端别、已有页面、计划版本和不做内容 |
现有资料 | PRD、流程、截图、数据、组件库和技术框架 |
协作方式 | 决策人、产品与研发接口人、评审频率和反馈时限 |
时间与预算 | 上线节点、预算区间、是否分阶段和是否需要驻场 |
询价时要求不同供应商按同一结构回复：阶段、工作、交付物、修改、研发协作、客户责任、不包含项和变更规则。只有范围一致，价格才有比较意义。
常见问题
1. B端UI/UX设计一定要做用户研究吗？
不一定做大规模研究，但至少要使用业务访谈、现有数据、客服或运营记录验证关键假设。复杂角色、高风险操作和团队分歧明显时，不宜完全跳过。
2. 已经有PRD，还需要流程和原型吗？
PRD通常说明需求和规则，但不一定完整表达用户操作顺序、反馈和异常。是否需要原型取决于PRD成熟度和开发风险，而不是文件是否存在。
3. 设计系统应该在项目开始还是结束时做？
先建立必要的基础Token和核心组件，在关键流程验证后逐步扩展。过早追求“大而全”容易沉淀错误模式，过晚整理又会造成界面不一致。
4. B端系统必须做移动端吗？
不一定。应根据真实工作场景决定。审批、查看和告警可能适合移动端，复杂录入和数据分析则可能仍以桌面端为主。
5. 开发走查一般包含几轮？
应按里程碑约定，例如核心组件、核心流程、全量页面和上线前各一次。比“包含两轮”更重要的是写清覆盖范围和问题关闭机制。
6. 怎样判断服务范围是否完整？
随机选择一个高风险任务，检查是否能找到角色、权限、前置条件、操作步骤、数据、正常结果、异常、恢复、组件和验收说明。任何一项缺失都可能成为后续风险。
结论：先把责任地图画清，再决定设计多少
采购B端UI/UX服务时，最有价值的问题不是“包含多少页”，而是“业务规则、权限、状态、组件和研发协作分别由谁负责”。范围清晰后，项目才能按阶段验收，报价也才能真正比较。
项目范围评估
准备改版B端系统、CRM、ERP或SaaS平台时，可整理核心角色、主要流程、现有截图和上线计划，提交给界达设计进行范围诊断与分阶段建议
