快缩短网址 · 项目复盘：从0到1构建B端后台系统的深度思考
项目地址：suo.run

---

从业以来，我长期深耕于前端领域，聚焦C端用户体验，鲜少涉足后台系统。过去几年，仅参与过三四个B端项目，经验尚浅。而近期，我完整主导了一个从零起步的后台管理系统——“PGD后台”，终于得以深入B端产品的肌理。此番实践，感触颇深，遂借“快缩短网址”之名，梳理思路、沉淀经验，愿与诸君共勉。

本文将从流程视角切入，系统回顾该项目的关键节点与核心洞察，力求为同类B端项目提供可借鉴的路径。

---

一、项目背景

产品定位
打造一个集后台管理与内部孵化项目数据统计分析于一体的综合平台——PGD后台管理系统。

目标用户
- 母公司质量合作伙伴
- 外部合作渠道方
- 孵化项目的实际运营团队

核心痛点
关键业务数据（用户行为、交易记录、商品信息）长期散落于多个第三方平台，缺乏统一入口，导致管理割裂、分析低效，难以形成闭环决策能力。

产品愿景
通过构建可视化、在线化的管理平台，显著降低运营门槛与合作壁垒，减少对高成本核心资源的依赖，从而提升渠道入驻效率与商品质量管控水平，最终沉淀平台影响力，强化品牌势能。

---

二、项目生命周期全景

相较于C端项目强调体验与转化，B端系统更注重流程严谨性、权限逻辑与数据一致性。本项目生命周期可划分为六大阶段：

1. 启动Ⅰ：产品需求挖掘
2. 启动Ⅱ：功能需求细化
3. 实施：规划立项与方案评审
4. 执行：需求落地、交互设计、测试验证
5. 交付：开发联调、验收上线
6. 收尾：发布监控、复盘迭代

每一阶段环环相扣，尤以前期“双启动”阶段最为关键——它决定了系统架构的合理性与后续扩展的可能性。

---

三、阶段拆解与关键洞察

#### 3.1 启动Ⅰ：产品需求挖掘

虽属产品经理主责范畴，但作为用户体验设计师，若缺席此阶段，极易陷入“为界面而设计”的误区。真正的B端体验，始于对业务流的理解，而非像素的堆砌。

> 建议：UX设计师应尽早介入需求讨论，哪怕仅以观察者身份。理解“为什么做”，远比“怎么做”更重要。



##### 3.1.1 目标用户分层

本项目用户并非单一角色，而是三层嵌套结构：

- 顶层：内部孵化平台运营方（策略制定者）
- 中层：合作渠道商（执行协调者）
- 底层：渠道下属门店人员（一线操作者）

三方诉求迥异：顶层关注数据洞察与风控，中层在意流程效率与权限分配，底层则追求操作极简与反馈即时。设计时需为不同角色配置独立视图与操作路径，避免“一刀切”。

##### 3.1.2 用户目标重构

原平台对终端门店缺乏有效约束力——当门店服务引发投诉，平台只能被动等待渠道商介入，品牌声誉受损却无能为力。

新系统的核心目标之一，即是建立平台对商品、商家、门店的穿透式管理能力。通过数据上报机制、服务评分体系与预警规则，将平台影响力下沉至业务末梢，实现“管得住、看得清、控得准”。

---



#### 3.2 启动Ⅱ：功能需求挖掘

B端产品的功能优先级，从来不由“用户喜好”决定，而由组织架构与决策链路主导。

与C端“用户即买家”不同，B端常出现“使用者≠采购者≠决策者”的三角关系。例如：
- 门店员工是高频使用者，却无采购话语权；
- 渠道商负责买单，但更关心ROI与合规风险；
- 平台方作为决策者，聚焦生态健康与长期价值。

因此，需求排序必须基于价值层级：
✅ 高价值 + 高影响 → 优先落地
⚠️ 高频但低战略意义 → 谨慎投入
❌ 仅满足局部便利 → 果断砍掉

同时，需警惕“伪需求”——某些看似合理的功能，实则源于个别用户的临时痛点，不具备普适性。此时，数据验证与跨角色访谈尤为重要。

---

四、总结：B端设计的底层逻辑

完成此次项目，我深刻体会到：B端不是C端的简化版，而是另一套复杂系统。它不追求“惊艳”，而崇尚“可靠”；不强调“转化”，而重视“可控”。

在“快缩短网址”（suo.run）的实践中，我们始终秉持三个原则：

1. 业务先行：设计服务于流程，而非装饰流程；
2. 角色隔离：权限即体验，不同身份应有专属工作台；
3. 数据驱动：每一个按钮背后，都应有明确的数据出口与反馈闭环。

未来，我们将继续打磨PGD后台，并探索如何将此类B端能力模块化、产品化，反哺更多企业级场景。

路虽远，行则将至。与各位同行者共勉。