用户是谁
⌄分销代发上下游经营体系下的买家、商家、平台。
业务角色：一条链路上至少五方，关注点各不相同
大 B上游商家 · 供货与履约
1688 平台撮合与规则
小 b分销商 · 找货、铺货、经营
ISV / ERP服务商 · 搬运与工具
C 买最终消费者 · 下单与体验
主要链路：连续任务，横跨平台与工具
获取货源与选品在 1688 找货
→
铺货至下游店铺经 ISV 搬运
→
下游编辑与经营改价、上架、运营
→
下游出单C 买下单
→
回上游采购 / 拍单发货商家直发 C 买
→
下游客服与售后退货、退款
工具特点：一条生意链路横跨 1688、下游电商平台及 ERP / ISV 等工具；平台与服务商共同承接体验，用户要完成的是连续任务，但各环节由不同工具支持。
小b的两种类型
粗铺型
重视商品覆盖与铺货效率
- 批量寻找符合要求的商品
- 选品后通常直接批量铺货
- 较少逐个进行商品信息二次加工
关注点：选品效率、批量操作、铺货效率
精铺型
重视单品质量与持续经营
- 更关注商品的潜力与匹配度
- 上架前会进行较多二次编辑
- 上架后持续投入运营和维护
关注点：选品准确性、试错成本、经营质量
粗铺型 / 精铺型是用于解释经营差异的典型模式，不是互斥的正式用户分类；此处未引用用户占比或访谈数量。
从操作动线、用户状态到产品场域：三个层级的体验优化
——体验设计阶段的产品实践
通过深入用户场景、动线及痛点分析，识别业务中的关键卡点问题，不止于体验设计，也从“用户分层、动线分层、场域分层”等提出并推动产品优化方案的迭代及体验标准沉淀。
操作动线层 · Part 1以终为始，突破业务逻辑的体验升级。绑店流程优化 →
用户状态层 · Part 2冗长旧链路分人群向极致体验的跃升。铺货动线重构 →
产品场域层 · Part 3围绕分销经营特征组织独立产品场域。代发场域迭代 →
Part 1绑店流程优化：突破业务逻辑的体验升级
结论：拉通上下游三方生态，推动业务策略优化，构建一站式绑店中台，借力AI实现全流程引导与答疑。
原问题
过于平台视角：
- 原步骤长是因为上下游均需分别订购并授权 ISV 应用，给用户的体感是在卖工具。
- 新老用户面对统一的绑店流程，且流程过于冗长。
- 新用户缺少必要指引，流程容易中断。
- 熟悉流程的老用户也需要重复经过不必要的步骤。
我的判断
回归用户视角：
- 用「添加店铺」替换「选择工具」，拉通上下游业务方探索缩减订购授权的可行性。
- 新用户的主要障碍是理解和完成流程，需要关键步骤提示与必要解释。
- 老用户已熟悉操作，重点是更快完成绑定，减少重复步骤。
方案变化
有效缩短用户动线
回归用户视角，以店铺维度切入，更贴近用户场景
业务逻辑变更：上游工具全部免费授权（不限期）
上线后效果
3 分钟内
新用户 · 优化后完成绑店（通常）
1 分钟内
老用户 · 优化后完成绑店（原约 3–5 分钟）
45%
绑店成功率提升（67% → 97%）
Part 2铺货动线优化：把数十步操作整合为五步以内的连贯主流程
结论：优化对象不只是某个页面，而是用户从发起铺货到完成任务的整段操作；通过抽象和统一铺货动线，降低跨入口重复理解和操作的成本。
原问题
- 原铺货链路包含数十步操作，部分场景下会中断。
- 用户从不同入口执行铺货时，需要重复理解或衔接步骤；身份 / 店铺状态处理与核心任务之间不够连贯。
优化前（示意）：入口分散、链路冗长，部分场景会中断，用户需要自己理解下一步。
不同入口各自链路规则不一致
→
登录 / 绑店状态需自行处理前置动作未承接
→
数十步分散操作多次重复理解与衔接
→
可能中断需重新衔接
→
完成铺货耗时不确定
我的判断
- 问题不只是页面操作多，而是铺货这项任务没有形成简单、稳定、跨入口可复用的心智路径。
- 用户应只需理解一套核心铺货流程；登录、绑店等前置状态应由流程根据当前状态承接，而不是让用户自己猜下一步。
- 统一的流程与交互组件，可以同时降低操作成本、维持用户在不同入口间的一致认知。
- 新用户的主要障碍是理解和完成流程，需要关键步骤提示与必要解释。
- 老用户已熟悉操作，重点是更快完成铺货，减少重复步骤。
方案变化：核心铺货路径
用户理解铺货动作的核心主路径（已上线）：
触发铺货任意入口发起
→
选择店铺已绑定店铺
→
开始铺货提交搬运
→
等待铺货完成结果回执
前置状态由流程承接，用户不需要自己判断：
未登录先引导登录，再回到铺货路径
未绑店先引导绑店，再继续铺货
已绑店直接展示店铺选择
从商品列表、商品卡、详情页、收藏夹、选品中心等不同入口发起时，复用同一套铺货组件与路径；PC 与 APP 的交互保持一致，避免认知被端型割裂。
APP端
PC端
上线后效果
7 步
新用户 · 至少仅 7 步（需先经过绑店链路，绑店成功后与老用户一致）
2 步
老用户 · 2 步完成（仅需确认店铺一个动作）
Part 3代发场域迭代：让产品形态匹配分销代发的经营方式
结论：分销代发并不是传统批发业务上增加一个「一件代发」标签或铺货按钮就能解决的需求；它的用户、经营目标与工作链路都有结构性差异，因此需要围绕分销任务组织独立的产品场域。
原问题
- 1688 传统批发场域围绕大批量采购、起订量和供货关系发展而来。
- 分销代发用户以零库存、小批量、高频次地将商品搬运到下游渠道经营为主，节奏更快，也更关注商品在下游出单的潜力。
- 如果只在传统批发页面增加代发标签、一个铺货按钮或零散模块，商品池、搜索排序、页面结构和工具能力仍按批发逻辑组织，用户在关键环节仍会遇到不匹配。
我的判断
- 当业务模式本身存在结构性差异，解决方案就不应只停留在页面或组件层，而需要有与该业务逻辑相匹配的产品场域。
- 分销代发场域应围绕「帮助小 b 找到并经营适合下游销售的商品」来组织商品、搜推、铺货、商品表达及运营工具，而不是简单复用传统批发的产品逻辑。
方案变化：独立代发场域的三个方面
商品与搜推从「便宜 / 起订」转向「适合代发 / 有下游出单潜力」
选品与铺货让列表成为高效的选品与铺货操作位置
运营与生态工具让运营与生态工具围绕分销经营衔接
优化前
- 沿用传统批发逻辑：以起订价、采购量为主要导向。
- 商品池未按经营方式区分，用户需自行筛选是否适合代发。
- 反复进入详情页才能发起铺货；需逐个处理 SKU 选择。
- 商品主图同时堆砌批发属性与代发信息，信息表达混杂。
- 运营与营销内容主要强调低价。
- ISV、插件等工具能力分散在二级路径，不易被当前任务触达。
- 各 ISV 页面风格与交互不一致，链路体验断裂。
优化后
- 代发场域商品池：按一件代发、包邮、七天无理由、密文面单、BSR 等条件筛选（具体条件以实际规则为准）。
- 搜索与排序：更关注下游出单潜力与代发质量，而非只看低价。
- 列表层直接支持一键铺货与批量铺货；表格选品让决策在一张列表上完成。
- 简化不必要的 SKU 选择；商品详情轻量化。
- 主图面向最终 C 买的阅读场景；批发 / 代发资质等信息交由标签或卡片承载。
- 运营内容围绕「帮小 b 选到适合经营的货」组织。
- ISV / 插件能力就近集成到商品卡、列表与详情等主要入口附近。
- 以平台视角输出跨平台体验规范：统一底线，同时尊重服务商的实现边界与特色功能。
页面截图
APP端
PC端
上线后效果
8 万+
代发场域 DAU · 日均
22 万+
代发场域 PV · 日均
已上线能力
代发场域信息架构
从「批发场域加功能」转为独立的代发产品场域，落地实际页面。
商品池与搜推逻辑
按代发经营方式筛选与排序。
选品与铺货能力
表格选品、列表一键铺货 / 批量铺货、轻量化商品详情。
商品主图表达
面向 C 买阅读场景；批发与代发信息由标签 / 卡片承载。
运营与生态工具
运营内容与 ISV / 插件工具围绕分销经营协同衔接。
跨平台体验规范
ISV 页面统一体验底线，保留服务商特色。
从操作动线、到用户状态、再到产品场域，我关注的不只是界面如何呈现，而是用户要完成的任务应当怎样被产品组织起来。