简介面向在线商务平台设计的高保真原型资源包以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里一个商品最终成交价至少要经过几层计算商家后台设置的原价商家参加的店铺促销满减、第二件半价平台级促销跨店满减、平台券用户侧资产会员积分抵扣、平台补贴。这些谁先算、能不能叠加原型图上不能含糊。我用过最有效的办法是在商品详情页旁边附一张价格计算规则表促销类型作用范围叠加关系计算顺序商家原价单品基础价格1店铺满减本店商品与平台满减互斥2平台跨店满减全平台商品与店铺满减互斥2店铺券本店商品与平台券互斥3平台券全平台商品与店铺券互斥3平台补贴活动商品可叠加4规格选择器也要画清楚多规格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 类目、品牌与佣金率平台的定价权藏在基础配置里平台靠什么赚钱主要是佣金、广告位和技术服务费。其中佣金率配置是运营端原型必须优先画清的基础模块。类目是树状结构每一级都可以配置佣金率同一商品的类目归属决定最终抽佣比例。原型里要有一张可维护的类目佣金表类目上级类目佣金率备注数码家电一级类目5%统一费率手机通讯数码家电4%可覆盖上级食品生鲜一级类目8%需资质生鲜果蔬食品生鲜10%可覆盖上级品牌库单独维护商家发布时只能选已入库品牌。品牌和类目之间还有约束关系比如某些品牌只能出现在特定次级类目。把这些基础配置规划好后续财务清算才能算得清楚。4.3 活动管理与平台补贴谁出钱必须对得上账运营端承担活动配置创建活动满减、秒杀、新人券、选择参加活动的商品池、设置活动时间、配置平台补贴比例。这里最容易踩坑的是补贴归属。同样是用户付了一个更低价但钱是平台出的还是商家出的对账逻辑完全不一样。原型设计里活动设置页面必须增加补贴承担方字段选项是平台补贴、商家让利或共同承担并且配一张试算表输入原价和补贴比例后自动算出用户实付、商家实收、平台支出各是多少。活动结束后的结算账单里补贴金额单独分行展示财务才能对得上账。不然活动越成功月底对账越痛苦。5. 这套B2B2C原型图画完之后我踩过的几个坑画到第二版时我差点想把文件删了重来。现在回头看有几个坑如果一开始就绕开至少能省一半时间。直接列给你希望对你有用。5.1 先画权限矩阵再画页面顺序不能反返工最严重的一次是商家端和用户端页面都画了大半角色权限矩阵一梳理发现订单详情页至少要出四种视图用户视图、商家视图、平台运营视图、平台客服视图。每个视图字段都不一样之前画的页面等于推倒一半。正确顺序是先和业务方把角色定义清楚画出权限矩阵再动页面设计。别让页面设计走在权限设计前面不然返工是必然的。5.2 异常流程画得越丑开发评审越顺第一版原型图我画得非常干净页面都漂亮结果评审时被开发连问十几个问题商家超时未处理售后自动同意之后用户又申请平台介入怎么办支付中途关掉页面订单显示待支付但库存已经扣了要不要释放拆单后其中一个子订单退款平台券怎么分摊这些问题答不上来评审会最后变成需求澄清会。后来我专门用一个版本补异常流程库存超卖、并发扣减、退款金额超过实付、商家资金冻结、平台补贴超预算每个场景画一个状态迁移文字图放在关联页面下方作为补充说明。这些图确实不美观但开发看完很少再追问评审效率高了很多。5.3 注释和字段说明比高保真更重要对B2B2C这种多角色系统高保真实在没那么重要。开发关心的不是图好不好看而是每个字段从哪来、到哪去、谁有权限改。所以后来我要求自己在每个关键交互节点都写注释下拉选项的数据来源、按钮的权限范围、字段的长度限制、接口失败时的兜底提示。注释写清楚之后前端照着画界面后端照着定义接口测试照着写用例整条链路的效率提升非常明显。最后再分享一个小习惯B2B2C原型图不要试图一次性画完三个端。我现在的节奏是先用户端主干流程再商家端核心经营流程最后运营端审核和结算配置。三个端各画完一轮再统一做跨端联调评审。这样每一轮交付都有可评审的成果需求变更也不会一次波及全部页面。本文还有配套的精品资源点击获取
