简介：本资源是一套面向产品经理、交互设计师及前端开发初学者的B2B2C在线平台高保真原型设计文件，聚焦威客类服务撮合场景，解决多角色（需求方企业、服务提供商、终端消费者）协同流程可视化与交互验证难题。压缩包共430个文件，含293张界面PNG图（主用于页面状态与流程展示）、25个HTML+22个CSS+49个JS文件（支撑可点击、跳转与基础交互的静态原型运行）、27张JPG素材及13个GIF动效示意，辅以Axure浏览器插件（.crx）提升本地预览体验，整体仅2.58MB，轻量易用。已有643人学习下载，适合快速理解B2B2C平台核心模块——如任务发布/竞标系统、服务商档案页、订单履约路径、评价闭环等，并直接复用页面结构、组件逻辑与UX动线设计。
1. 一个平台的B2B2C原型图：不是画完就交差，而是把三方角色、四类动线、五处权责边界全钉死在界面上
“B2B2C原型图”这个词，最近在某高校电商系统课设评审、某公司中台产品立项会、某SaaS服务商客户提案里高频出现——但它常被误当成“B2C加个后台管理”的简化版。真实情况是：当一个平台同时承载供应商（B1）、平台运营方（B2）、终端消费者（C）三类角色，且B1与C之间存在商品/服务交付、履约协同、分账结算等强耦合动作时，任何漏掉「B1-B2权限隔离」或「B2-C数据可见性策略」的原型，上线后必然触发三方投诉闭环。我去年参与的模拟项目X就因此返工三次：供应商能看见其他商家的订单毛利，消费者下单后平台无法向B1自动触发库存扣减指令，而B2运营侧连基础的分账流水对账页都缺失。这篇笔记不讲抽象模型，只拆解如何用Axure/Figma/墨刀这类工具，在一张可交互原型图里，把B1的入驻审核流、B2的商品池治理规则、C的跨商家比价路径、以及三者共用的售后协同面板，全部用组件状态+变量逻辑+条件跳转显式表达出来。适合正在做平台型产品设计、需要向技术团队传递清晰协作契约的从业者，也适合刚接触多角色系统的新手——你不需要懂代码，但必须学会用原型语言写“系统契约”。
2. 从角色建模到页面骨架：用三层结构锚定B2B2C的核心界面域
B2B2C不是B2B和B2C的拼接，而是三类角色在统一平台上的权限-数据-流程三角约束关系。画原型前，必须先用三层结构框定所有页面归属，否则后续交互逻辑必然混乱。
2.1 角色-能力-页面映射表：拒绝“一个后台管所有”
很多原型翻车，源于把B1（供应商）和B2（平台方）混在同一个管理后台。正确做法是按角色能力切分独立入口，并用变量控制可见性。下表是模拟项目X最终采用的映射逻辑（实际项目需根据业务规则调整）：
| 角色 | 核心能力 | 对应页面域（原型中独立页面组） | 数据可见性约束（原型需标注） |
|---|---|---|---|
| B1 | 商品上架、库存管理、订单履约 | 【B1工作台】→ 商品中心、库存看板、履约单 | 仅可见自身商品数据；不可见其他B1的店铺信息 |
| B2 | 类目治理、商家审核、分账配置 | 【B2中枢】→ 商家中心、类目管理、财务分账 | 可查所有B1数据；但修改B1库存需二次确认弹窗 |
| C | 跨商家比价、混合下单、统一售后 | 【C前台】→ 首页、商品列表、购物车、订单中心 | 仅显示B2授权展示的商品信息；订单页隐藏B1真实联系方式 |
提示：在Axure中，用「全局变量」定义
roleType（值为b1/b2/c），所有页面加载时读取该变量，通过「设置元件可见性」控制不同角色看到的导航栏、操作按钮、数据表格列。Figma则用「Variant」组件配合「Property」开关实现类似效果。
2.2 四类关键动线必须独立建模：不能靠文字描述代替可点击路径
B2B2C的复杂性藏在角色间的流转动作里。原型中必须为以下四类动线建立完整可点击链路（非静态线框），每条链路至少包含3个以上带状态变化的页面：
- B1入驻动线：注册 → 提交资质 → B2人工审核 → 合同签署 → 店铺开通（含资质上传失败的重试分支）
- B1-B2商品协同动线：B1上架商品 → B2类目审核驳回 → B1修改类目 → B2二次审核 → 商品进入B2统一商品池
- C端跨商家下单动线：C搜索关键词 → 展示多B1商品（带“同款比价”标签）→ 加入购物车（支持混选A/B两家商品）→ 结算页显示分单逻辑（自动生成2张子订单）
- 三方售后协同动线：C发起退货 → 系统自动分配至对应B1 → B1确认收货 → B2财务页生成分账调整单 → C收到退款（含B1承担比例说明）
2.3 用「状态机」替代静态页面：让原型真正反映业务规则
B2B2C中大量页面存在多状态切换（如订单页有“待支付/已支付/B1备货中/B2发货中/已完成/已退款”等12种状态）。若原型只画一种状态，开发必做错。正确做法是：
- 在Axure中，为每个状态创建独立页面（如
Order_Detail_Paid、Order_Detail_Shipping） - 用「动态面板」包裹核心区域，设置不同状态下的内容（如“备货中”显示B1仓库地址，“发货中”显示物流单号输入框）
- 所有状态跳转必须绑定真实触发条件（如点击“确认收货”按钮 → 判断当前角色是否为C → 满足则跳转至
Order_Detail_Completed）
参数说明：Axure中动态面板的State名称必须与业务术语一致（如
state_shipped而非state_3），方便开发直接映射到后端状态码。Figma用户可用「Smart Animate」配合「Component Properties」实现状态切换动画，但需额外标注各状态对应的后端事件（如order_shipped_event）。
3. 关键交互细节：把“平台规则”翻译成用户可感知的操作反馈
原型的价值不在美观，而在能否让B1、B2、C三方用户一眼理解“我能做什么、不能做什么、为什么这样设计”。以下细节必须显式表达，否则开发会按直觉实现，埋下权责纠纷隐患。
3.1 B1与B2的权限隔离：用视觉降级+操作拦截双保险
B1绝不能误操作B2专属功能（如修改平台佣金率），B2也不能越权查看B1敏感数据（如成本价）。原型中需体现两层防护：
- 视觉降级：B1登录后，B2专属菜单项（如“分账配置”）显示为灰色文字+禁用图标，鼠标悬停提示“仅平台管理员可操作”
- 操作拦截：当B1尝试访问B2页面URL时，原型需跳转至403错误页（含返回B1工作台按钮），而非静默加载空白页
// Axure伪代码示例：B1访问B2页面时的拦截逻辑 OnPageLoad: If [[roleType]] == "b1" Then Set Variable [[redirectUrl]] = "B1_Dashboard" Open Link in Current Window: [[redirectUrl]] End If逻辑说明：此逻辑必须在原型每个B2专属页面的
OnPageLoad事件中重复设置，确保URL直连也无法绕过。不要依赖前端路由守卫——原型阶段就要把权限意识刻进交互链路。
3.2 C端跨商家购物车：用实时计算替代静态展示
C在购物车中混选A商家的手机壳和B商家的充电线时，结算页必须实时显示：
- 子订单1（A商家）：含运费、预计送达时间、售后入口
- 子订单2（B商家）：含运费、预计送达时间、售后入口
- 合并支付按钮（调用统一支付网关）
- 关键细节：当C删除A商家商品时，子订单1自动消失，合并支付按钮文案变为“去B商家结算”
// Figma中实现逻辑（需在交付文档中注明） - 购物车容器：设置Auto Layout + Vertical Stack - 每个子订单卡片：作为独立Component，含“商家头像+商品列表+运费+操作按钮” - 删除商品交互：触发“Remove Item”事件 → 动态移除对应子订单卡片 → 重新计算剩余子订单数 → 更新合并支付按钮文案参数说明：Figma中需用
Variant属性定义按钮文案（pay_all/pay_single），开发根据子订单数量调用对应文案。避免用“暂不支持混单”等模糊提示——B2B2C的核心价值就是支持混单。
3.3 B2的类目治理面板：让规则可配置、可追溯
B2对B1上架商品的审核，本质是对类目规则的执行。原型中【类目管理】页必须包含：
- 规则配置区（如“手机壳类目需提供3C认证编号”）
- B1提交记录列表（含“审核中/通过/驳回”状态）
- 驳回原因模板库（点击“驳回”按钮后，弹出预设选项：“资质不全”“类目错放”“图片违规”）
血泪经验：某次评审中，B2运营提出“希望驳回时能手填原因”，我们当场在原型中增加文本框——结果开发实现时未做长度限制，导致数据库字段溢出。教训是：所有可编辑输入框，原型必须标注最大字符数（如“驳回原因（≤200字）”）和必填标识。
4. 避坑指南：B2B2C原型中5个高频翻车点及自救方案
画B2B2C原型最易陷入“看起来都对，一上线就炸”的陷阱。以下是我在模拟项目X和某跨平台系统中踩过的5个具体坑，按“现象→原因→解决”结构整理，每一条都对应真实返工记录。
4.1 现象：B1在商品编辑页修改价格后，C端首页搜索结果未实时更新
原因：原型中未定义“B1保存价格”动作与“C端商品卡片刷新”的关联逻辑，开发默认用缓存策略（TTL=1小时），导致价格变更延迟生效。
解决：在B1商品编辑页的“保存”按钮交互中，明确添加「触发C端商品卡片刷新事件」说明，并标注刷新范围（如“仅更新当前商品ID对应的所有展示位”）。在Axure中可用注释框写：“调用API /api/goods/refresh?id=xxx，前端监听event:goods_updated”。
4.2 现象：C提交订单后，B1后台未收到通知，B2客服无法定位问题
原因：原型中订单成功页只写了“下单成功”，未设计B1/B2的异步通知机制（如站内信、邮件模板、短信占位符）。
解决：在订单成功页底部增加「通知日志」区域（仅原型可见），列出三条必发通知：
- 给B1：站内信标题“新订单#20240501001待处理”，正文含C收货地址、商品清单
- 给B2：邮件模板占位符“{order_id}已生成，B1处理超时将自动升级”
- 给C：短信占位符“【平台名】您的订单{order_id}已提交，预计{time}前发货”
4.3 现象：B2在财务分账页修改佣金率后，历史订单分账未保持原值
原因：原型中未区分“全局佣金率”和“订单快照佣金率”，开发按最新率重新计算所有历史订单，引发B1投诉。
解决：在B2分账配置页增加「生效时间」选择器（默认“立即生效”，可选“下月1日生效”），并在订单详情页的分账明细区标注“按下单时佣金率计算”。原型中用灰色小字注明：“历史订单佣金率以订单创建时间为准，不随配置变更”。
4.4 现象：C在订单页点击“联系商家”，弹出的是B2客服电话而非B1真实联系方式
原因：原型中“联系商家”按钮未绑定角色判断逻辑，开发按B2客服中心统一处理。
解决：在C订单页的“联系商家”按钮交互中，添加条件分支：
- 若订单归属B1，则跳转至B1客服页面（含B1预留电话/在线客服入口）
- 若订单含多个B1，则显示“分别联系：A商家（电话XXX）、B商家（在线客服）”
- 所有联系方式字段在原型中用
[[b1_contact]]变量表示，强制要求开发从B1资料库读取。
4.5 现象：B1上传资质文件后，B2审核页显示“文件已损坏”，实际文件正常
原因：原型中未定义文件上传的格式/大小校验规则，开发自行限制为PNG/JPG且≤2MB，但B1需上传PDF版营业执照。
解决：在B1资质上传组件旁，用红色星号标注强制要求：
- 支持格式：PDF、JPG、PNG（不可删减）
- 单文件≤10MB（非2MB）
- 必传文件：营业执照（PDF）、法人身份证（JPG）、品牌授权书（PDF）
- 上传失败提示语必须与校验规则一一对应（如“仅支持PDF/JPG/PNG格式，请检查文件后缀”）
5. 进阶验证法：用三张对照表把原型从“能看”升级为“能签”
画完原型不等于完成交付。B2B2C项目涉及多方权责，必须用可验证的对照表，让B1、B2、C三方代表在评审会上逐条确认，避免“我以为你知道”式的沟通黑洞。以下是我在模拟项目X中坚持使用的三张表，每张表都成为后续开发验收的基准。
5.1 角色操作权限对照表：让B1/B2/C三方签字确认“我能做什么”
此表需打印张贴在评审现场，由三方代表逐行勾选。表格结构如下（仅展示部分字段，实际需覆盖所有页面）：
| 页面名称 | 操作按钮 | B1可见 | B1可操作 | B2可见 | B2可操作 | C可见 | C可操作 | 权限依据（引用合同条款） |
|---|---|---|---|---|---|---|---|---|
| 商品编辑页 | 保存 | ✓ | ✓ | ✗ | ✗ | ✗ | ✗ | 附件3.2.1 |
| 订单详情页 | 申请退货 | ✗ | ✗ | ✗ | ✗ | ✓ | ✓ | 附件4.5.3 |
| 分账配置页 | 修改佣金率 | ✗ | ✗ | ✓ | ✓ | ✗ | ✗ | 附件5.1.0 |
| 售后协同页 | 确认收货 | ✓ | ✓ | ✗ | ✗ | ✗ | ✗ | 附件4.7.2 |
执行要点：每行右侧留签字栏，B1/B2/C三方代表必须亲笔签名。曾有B1代表在“确认收货”行勾选“B1可操作”后反悔，我们当场调出合同附件4.7.2条款，对方无异议。没有签字的权限表，等于没签合同。
5.2 数据流向与可见性表：堵死“谁能看到什么数据”的灰色地带
B2B2C最易起纠纷的点是数据泄露。此表用箭头明确数据从哪来、经哪处理、到哪展示、谁可见。例如：
| 数据项 | 来源角色 | 处理环节 | 目标页面 | 展示形式 | B1可见 | B2可见 | C可见 | 脱敏规则 |
|---|---|---|---|---|---|---|---|---|
| C收货地址 | C | B2订单中心聚合 | B1履约单页 | 完整地址 | ✓ | ✓ | ✗ | — |
| B1成本价 | B1 | B2商品池治理 | B2类目管理页 | 显示为“保密” | ✓ | ✗ | ✗ | 后端字段加密存储 |
| 订单分账明细 | B2 | 财务分账引擎计算 | C订单详情页 | “平台收取X元” | ✗ | ✓ | ✓ | 隐藏B1实收金额 |
| B1店铺评分 | C | B2评价系统聚合 | C商品列表页 | ★★★★☆ | ✗ | ✓ | ✓ | 不显示原始评价内容 |
玄学提醒：表格中“脱敏规则”列必须写具体技术动作（如“前端渲染时替换为‘*’”“后端API返回字段置空”），禁止写“按需脱敏”“视情况处理”等模糊表述。某次因写“视情况处理”，开发默认不脱敏，导致B1成本价在C端暴露。
5.3 关键状态流转表：把“系统怎么变”变成可测试的检查清单
B2B2C的状态机极其复杂，仅靠原型页面难以覆盖所有分支。此表列出所有核心状态及触发条件，供测试用例编写：
| 当前状态 | 触发动作 | 执行角色 | 下一状态 | 系统动作（原型需体现） | 通知对象 | 通知方式 |
|---|---|---|---|---|---|---|
| 待支付 | C点击支付 | C | 已支付 | 跳转支付成功页；生成子订单 | B1,B2 | 站内信 |
| 已支付 | B1点击“开始备货” | B1 | 备货中 | 展示B1仓库地址；倒计时72小时 | B2 | 邮件 |
| 备货中 | B1点击“发货” | B1 | 发货中 | 弹出物流单号输入框；生成运单号 | C | 短信 |
| 发货中 | 物流信息回传 | 系统 | 已签收 | C订单页显示“已签收”；触发分账结算 | B1,B2 | 站内信 |
| 已签收 | C点击“申请退货” | C | 退货中 | B1履约单页新增退货单；冻结对应分账金额 | B1 | 站内信 |
后悔药：这张表必须作为原型交付物的一部分，且每行“系统动作”需对应到具体原型页面和交互事件（如“跳转支付成功页”指向
Payment_Success页面）。测试时，QA按此表逐条验证，漏一条即打回重画。
最后说句实在话：画B2B2C原型，画得再炫酷，不如把B1的资质上传失败提示语写准、把B2的佣金率生效时间标清、把C的跨商家购物车合并逻辑钉死。我现在的习惯是，每次打开Axure前先问自己三个问题：这个按钮B1点了会怎样？B2改了配置会影响哪些历史数据？C看到这个提示会不会打客服电话？答案不清晰，就不动鼠标。希望帮到你。
本文还有配套的精品资源，点击获取
