B2B2C电商平台原型图设计全流程：三端权限与订单链路拆解

简介：面向在线商务平台设计的高保真原型资源包，以B2B2C企业-平台-消费者模式为业务框架，完整覆盖威客网/微客网一类撮合交易平台的核心界面与交互流程，适合产品经理、UX设计师及原型设计学习者借鉴参考。资源包内含430个文件，以Axure导出的HTML页面为主，配套css样式表、js交互脚本、png/jpg/gif图片素材，以及Axure Chrome插件crx，可在线直接预览或二次编辑；整体体量仅2.58MB，轻量紧凑，便于按模块拆解学习。资源已有642人学习，高保真页面还原了需求发布、竞标接单、订单管理、支付评价等关键环节，既能帮助理解B2B2C业务的闭环逻辑，也为快速搭建同类平台原型提供了可复用的视觉与交互范本。 说实话，刚接到"做一套B2B2C平台原型图"这个需求的时候，我没太当回事。商城原型我画过不少，首页、列表、详情、购物车、订单、个人中心，闭着眼都能铺出来。真动起手才发现，B2B2C远不是"套一套商城模板"那么简单，它等于同时画三套系统：用户端、商家端、平台运营端，还要把三套系统之间的角色权限、数据流转、资金分账全部串起来。这篇文章就是把我从立项到交付的完整过程拆开聊，讲讲B2B2C原型图怎么画、哪些地方最容易翻车、每一步为什么这么设计。准备做平台型产品，或者在电商团队里负责原型的同行，可以直接拿来当参考。

1. B2B2C原型图和普通商城原型到底差在哪

B2B2C拆开看是Business to Business to Consumer，平台是第一个B，商家是第二个B，消费者是C。而B2C里，平台自己就是货主或唯一供货方，后台是内部系统，不需要面向外部商家开放。B2B2C不一样，平台不卖货，货在商家手里。平台要做的，是把交易场搭起来、把规则立起来，然后让商家自己来开店、上架、发货、服务。角色一多，原型就从一个后台加一个前台，变成三套系统并行：用户端负责体验和转化，商家端负责经营和履约，平台运营端负责入驻审核、商品管控、佣金结算和活动配置。

1.1 三种角色、两条链路、一张关系网

动笔画原型之前，先别急着画首页。我习惯先做一张全局关系图，把三个角色之间的交易链路和资金链路标清楚。正向链路是：商家在商家端发布商品，平台运营审核通过，商品出现在用户端，用户下单支付，平台按规则分账，把货款和佣金分开结算，商家收到订单安排发货，用户收货评价。逆向链路是：用户申请退款退货，商家在第一轮处理，如果超时未处理或双方有争议，用户升级到平台介入，客服判责后，财务按结果从对应资金池扣回或补款。

这两条链路想清楚之后，再开始拆页面。原型图全案的首页，我建议就放这张关系图加一条说明：每个端解决什么问题，数据从哪里来，钱往哪里走。这张图就是后面所有页面的"导航地图"，评审的时候也是最高效的沟通入口。

1.2 权限设计是原型图的第一个硬骨头

多角色带来的第一个实际问题，是同一个页面不同角色看到的内容完全不一样。拿订单详情页举例，用户看到的是商品图、订单金额、物流轨迹和退款按钮；商家看到的是买家昵称、收货地址、电话、买家备注和发货操作；平台运营看到的是订单实付金额、商家佣金、支付流水号和风控标记；客服介入时还要看到双方沟通记录和售后证据。

如果还是按"一个页面画一张图"的思路，B2B2C根本做不下去。正确做法是在原型工具里画同一页面的多个角色视图，或者用一张字段权限矩阵标清楚：哪些字段用户可见、哪些字段商家可见、哪些字段只有运营能改。宁可图丑一点，也要把每个角色能看什么、能改什么标死。我提供一个小模板，可以直接放到原型文档里：

1.3 商家端到底要独立到什么程度

判断商家端是否足够独立，我有一条标准：如果把平台运营这个角色完全拿掉，商家光靠商家后台能不能完成从开店到收款的全过程。能满足这条，商家端才是一套完整的SaaS式产品，而不是平台的附属功能。功能切分上，商家端要包含独立的账号与子账号体系、店铺管理、商品管理、订单管理、售后管理、会员管理、营销工具、资金账户、账单与提现，以及和平台沟通的站内消息、申诉入口。平台运营端不需要重复这些经营功能，它的重心在审核、风控、类目与佣金配置、活动管理、数据看板。先把这条边界划清楚，后面就不会出现"商家后台里塞了一堆平台运营操作"这种四不像的设计。

2. 用户端原型：体验向B2C看齐，逻辑要给B2B2C留接口

用户端最容易画，也最容易画错。容易画，是因为页面结构基本可以参照成熟电商App；容易画错，是因为很多设计师会不自觉地把所有页面都做成平台自营口径。比如商品页只写价格不写店铺，购物车不做店铺分组，售后把平台客服当成唯一入口，这些在B2B2C里都是隐患。用户端的原型必须做到让用户感觉"和逛旗舰店差不多"，但在每一个和商家发生关系的节点上，都把店铺归属和平台规则表达清楚。

2.1 首页和店铺页：平台是商场，商家是租户

首页承担流量分发，不用每个区域都体现商家概念。轮播图、今日秒杀、新人专区这些营销位，本质上是平台从商家手里选品、集中投放。原型里把这些模块标为"运营配置位"，预留点击跳转规则就行。真正需要突出商家身份的是店铺页和搜索结果页。店铺页要有店铺名称、评分、粉丝数、关注按钮、店内分类、全部宝贝列表和资质信息；搜索结果页的每条商品卡片，应该在价格下方或标题下角标出店铺名。不要小看这个细节，它决定了用户对"这是一个平台、里面有很多店"的认知能不能建立，也直接影响后续订单和售后的心智。

2.2 商品详情页：价格层级和规格选择必须先于界面

详情页最大的坑在价格。B2B2C里一个商品最终成交价，至少要经过几层计算：商家后台设置的原价，商家参加的店铺促销（满减、第二件半价），平台级促销（跨店满减、平台券），用户侧资产（会员积分抵扣、平台补贴）。这些谁先算、能不能叠加，原型图上不能含糊。我用过最有效的办法，是在商品详情页旁边附一张价格计算规则表：

规格选择器也要画清楚：多规格SKU要支持库存不足置灰，同时明确展示发货店铺、发货地、运费标准。这些信息在B2C里经常被省略，但在B2B2C里，商家不同、发货地不同、运费模板不同，用户下单前看不到，售后问题会成倍增加。

2.3 购物车与支付：多店合并支付这道坎必须跨过去

B2B2C购物车和B2C最大的区别是店铺分组。用户在购物车选了A店和B店各一件商品，结算时怎么办？目前比较成熟的方案是"合并支付、自动拆单"：用户一次性付一笔总金额，支付成功后系统按店铺拆成多个子订单。这样用户支付路径最短，商家和平台也能在后台看到各自的子订单。

原型里购物车页面要有店铺维度分组表头，包括店铺名和进店入口；店铺优惠券展示在店铺分组下，平台券放在购物车底部作用于整个合并订单。提交订单页要区分不同店铺的商品清单和运费，收货地址要允许按店铺分别设置。订单列表页要同时有总订单和子订单的概念，用户按子订单查看物流、确认收货、申请售后。拆单之后平台券怎么分摊到各子订单，也要在页面注释里写清楚，否则财务对账会非常痛苦。

2.4 订单与售后：平台和商家的服务边界要写进状态机

订单流转本身不复杂：待付款、待发货、待收货、已完成、已关闭，基础状态机从B2C搬过来就行。真正需要动脑筋的是退款和售后的归属。建议默认售后流程是：用户在订单详情发起申请，商家在48小时内响应，同意后系统执行退款或退货；商家超时未处理，系统自动同意；商家拒绝，用户可以选择修改申请或者请平台客服介入。客服介入后，页面切到平台运营端的工单视图，记录判责依据和最终结论。

这套状态流转建议用带超时动作的文字说明画清楚，并标注每个节点的自动动作。把它画明白，开发评审时基本不会再问"商家一直不处理怎么办"这类问题。

3. 商家端原型：让入驻商家不培训也能用明白

商家端的核心原则是两个字：兜底。商家不是产品经理，不会理解"这里逻辑需要先选类目才能展示规格"，他们只希望一进来就知道怎么传图、怎么填价格、怎么发货。做得好的商家端，应该让一个从没用过后台的小商家，不看帮助文档也能完成第一个商品上架。

3.1 入驻、店铺装修和商品发布：用表单把平台规则落地

入驻流程里，重点不是表单多不多，而是状态可追踪。商家提交营业执照、法人信息、银行结算账户、行业资质之后，每一步都要在原型里显示当前审核状态：待提交、待初审、待实人认证、已驳回并附原因。驳回后允许商家修改重新提交。

商品发布是商家端最长的表单，也是平台管控商家最有效的位置。我习惯按"类目、基础信息、规格库存、价格、图片详情、提交审核"分步骤引导。关键限制要在表单里就画出来：一级二级类目决定必填项和佣金率，特殊类目强制上传资质，品牌只能从平台维护的品牌库中选择，不让手填。SPU/SKU录入支持多规格自动生成组合，比如颜色乘以尺码生成4个SKU，每个SKU单独维护价格、库存、编码和图片。店铺装修则要模板化，招牌、Banner、公告、商品分组，商家只需传图填字选排序。

3.2 订单与售后工作台：让商家能高效处理日常经营

商家的订单工作台要支持按状态筛选、按时间查询、批量发货、打印面单。发货地址默认取店铺设置的默认发货地，支持多仓配置。售后工作台要区分仅退款、退货退款、换货，不同售后类型的处理倒计时要高亮提醒，避免商家漏掉被平台自动处理。

这里有个容易漏的细节：商家端和平台运营端看到的是同一张订单，但字段权限完全不同，所以商家订单列表需要单独画，不能直接复用用户端订单页。商家能看到用户备注，但看不到平台内部的佣金计算明细；能操作发货，但不能操作强制退款。这些边界在1.2的权限矩阵里定了之后，这里照做即可。

3.3 结算与对账：把商家最关心的钱画明白

结算页面是商家最敏感的模块，字段必须精确。一张账单至少要包含：子订单实付金额、平台佣金、营销扣款、退款扣回、运费补贴、本期应结、本期已结。建议提供按天、按月自动生成账单的入口，并且支持下载明细Excel。资金账户模块要画清余额、冻结、可提现、提现记录四个区块。提现申请提交后，在平台财务审批前允许商家撤销。把这几块画清楚，商家才敢放心把生意放到你平台上。

4. 平台运营端原型：审核流与规则配置是平台的核心价值

如果说用户端代表体验、商家端代表经营，那平台运营端代表的就是掌控力。运营端不用做复杂操作，目标是把规则配置好、把流程审核好、把异常数据捞出来。运营端原型里最重要的不是页面漂亮，而是状态机和权限画得够不够死。

4.1 入驻审核与商品审核的状态流转

一个典型的商家入驻审核流程包含：商家提交资料，平台初审资质是否真实有效，平台复审经营范围与类目资质，最后开通店铺。任何一步驳回都要写清原因，审核操作要留痕，支持按审核员和时间段查询记录。商品审核也要过审才能上架，商家量起来之后运营会非常忙，所以原型里必须设计批量审核工具，不能只做一个一个审核的页面。

状态流转建议写清楚：待提交、待初审、待复审、通过、驳回、冻结、注销。每个状态对应运营端列表里的一个筛选Tab。商品审核除了通过和驳回，还要支持下架、强制下架、锁定编辑。锁定通常用于类目资质过期或平台抽检发现问题，高危操作必须二次弹窗确认，并写操作日志。

4.2 类目、品牌与佣金率：平台的定价权藏在基础配置里

平台靠什么赚钱？主要是佣金、广告位和技术服务费。其中佣金率配置是运营端原型必须优先画清的基础模块。类目是树状结构，每一级都可以配置佣金率，同一商品的类目归属决定最终抽佣比例。原型里要有一张可维护的类目佣金表：

品牌库单独维护，商家发布时只能选已入库品牌。品牌和类目之间还有约束关系，比如某些品牌只能出现在特定次级类目。把这些基础配置规划好，后续财务清算才能算得清楚。

4.3 活动管理与平台补贴：谁出钱必须对得上账

运营端承担活动配置：创建活动（满减、秒杀、新人券）、选择参加活动的商品池、设置活动时间、配置平台补贴比例。这里最容易踩坑的是补贴归属。同样是用户付了一个更低价，但钱是平台出的还是商家出的，对账逻辑完全不一样。

原型设计里，活动设置页面必须增加"补贴承担方"字段，选项是平台补贴、商家让利或共同承担，并且配一张试算表：输入原价和补贴比例后，自动算出用户实付、商家实收、平台支出各是多少。活动结束后的结算账单里，补贴金额单独分行展示，财务才能对得上账。不然活动越成功，月底对账越痛苦。

5. 这套B2B2C原型图画完之后，我踩过的几个坑

画到第二版时，我差点想把文件删了重来。现在回头看，有几个坑如果一开始就绕开，至少能省一半时间。直接列给你，希望对你有用。

5.1 先画权限矩阵，再画页面，顺序不能反

返工最严重的一次，是商家端和用户端页面都画了大半，角色权限矩阵一梳理，发现订单详情页至少要出四种视图：用户视图、商家视图、平台运营视图、平台客服视图。每个视图字段都不一样，之前画的页面等于推倒一半。正确顺序是：先和业务方把角色定义清楚，画出权限矩阵，再动页面设计。别让页面设计走在权限设计前面，不然返工是必然的。

5.2 异常流程画得越丑，开发评审越顺

第一版原型图我画得非常干净，页面都漂亮，结果评审时被开发连问十几个问题：商家超时未处理售后自动同意之后，用户又申请平台介入怎么办？支付中途关掉页面，订单显示待支付但库存已经扣了，要不要释放？拆单后其中一个子订单退款，平台券怎么分摊？这些问题答不上来，评审会最后变成需求澄清会。

后来我专门用一个版本补异常流程：库存超卖、并发扣减、退款金额超过实付、商家资金冻结、平台补贴超预算，每个场景画一个状态迁移文字图，放在关联页面下方作为补充说明。这些图确实不美观，但开发看完很少再追问，评审效率高了很多。

5.3 注释和字段说明比高保真更重要

对B2B2C这种多角色系统，高保真实在没那么重要。开发关心的不是图好不好看，而是每个字段从哪来、到哪去、谁有权限改。所以后来我要求自己，在每个关键交互节点都写注释：下拉选项的数据来源、按钮的权限范围、字段的长度限制、接口失败时的兜底提示。注释写清楚之后，前端照着画界面，后端照着定义接口，测试照着写用例，整条链路的效率提升非常明显。

最后再分享一个小习惯：B2B2C原型图不要试图一次性画完三个端。我现在的节奏是先用户端主干流程，再商家端核心经营流程，最后运营端审核和结算配置。三个端各画完一轮，再统一做跨端联调评审。这样每一轮交付都有可评审的成果，需求变更也不会一次波及全部页面。

本文还有配套的精品资源，点击获取