电商 App 产品规划实战：功能结构、交互流程、账号体系与 PRD 模板

一、先画结构，再画页面

新手最常见的错误是「打开 Axure 就开始画首页」。首页画得再漂亮，也会在第三个迭代被推翻，因为你还没有结构。

正确的顺序是：先定义指标 → 再画流程 → 再定页面 → 最后写字段与异常。指标决定你关注什么，流程决定页面顺序，页面决定需要哪些字段。

• 指标阶段要回答：这个业务靠什么赚钱？哪个数字变好说明我们做对了？
• 流程阶段要回答：用户从哪来、卡在哪、怎么走完？逆向流程（取消、退款、售后）是什么？
• 页面阶段才轮到布局与视觉。此时页面数量的答案会自然浮现，而不是拍脑袋。

二、五段式功能结构

综合类电商的信息架构在行业里已经收敛，直接复用即可，不要自创：

判断结构对不对，只看一件事：新同学能不能在 10 分钟内说出「我要改的东西属于哪一段」。说不出来就是结构有问题。

三、七个最容易踩的坑

• 坑 1：优惠分摊没定义就开发。券是订单级的，退款是商品级的。不定分摊算法，部分退款必然出现多退少退。
• 坑 2：把库存只挂在商品上。库存必须挂在 SKU 上，且要区分「可售 = 总库存 − 已预占」。
• 坑 3：购物车不做合并键。合并键应为「商品 ID + 规格」，否则同一商品会出现多行，用户以为买了两次。
• 坑 4：提交订单不锁按钮。用户连点两下就生成两笔订单，这是最常见的生产事故之一。
• 坑 5：售后入口藏太深。逆向流程没设计好，客服工单量会吃掉你全部的人力。
• 坑 6：指标口径不统一。「GMV」在运营、财务、产品嘴里是三个数，开会永远对不齐。
• 坑 7：动效只为好看。无目的的动画会拖慢低端机，最终伤害的是转化率。

四、数据分析先做哪几个指标

不要一上来就堆 30 个图表。先做一条能推导动作的指标链：

GMV = UV × 转化率 × 客单价

• UV 掉了 → 查渠道投放与内容质量，看获客成本。
• 转化率掉了 → 看漏斗，定位是详情加购还是结算提交的问题。
• 客单价掉了 → 看品类结构与促销形式，组合购与满减梯度是否失效。

三个因子各有对应的页面与动作，这就是「指标能推导动作」的含义。看不到动作的指标，先别做。

五、动效设计：只做三件事

• 说明状态变化：加购后商品飞入购物车，告诉用户「东西去哪了」。
• 引导注意力：秒杀倒计时、库存告急的颜色与轻微呼吸效果。
• 提供操作反馈：按钮按压形变、开关弹性回弹、Toast 提示。

实现上坚持三条工程纪律：只动 transform / opacity / filter；同屏粒子设上限；提供一键降级（省流模式 / 尊重系统「减少动态效果」）。

六、PRD 模板清单（可直接套用）

• 模块目标：一句话说清这个模块解决什么问题、对哪个指标负责。
• 用户故事：作为……我希望……以便……（至少 3 条，覆盖新老用户）。
• 功能清单：编号 + 描述 + 优先级（P0/P1/P2）。
• 业务规则：金额、库存、优惠、状态的全部判定条件。
• 数据字段：字段名 / 类型 / 说明，含枚举值。
• 状态流转：用状态机图或文字链表达所有分支。
• 异常边界：网络、库存、时间、权限、并发五类全过一遍。
• 埋点事件：事件名 / 触发时机 / 参数。
• 核心指标：本模块关注的 2~3 个指标及口径。
• 验收标准：正向 / 边界 / 异常 / 兼容 / 性能五类句式。

这份「六段结构」在本原型的每一页产品备注里都有完整示例，可以直接照着改。

七、账号与安全：登录、注册与找回密码

账号体系是最容易「看着做完了、其实埋着雷」的模块。判断做得对不对，只看一句话：能逛的别拦，会产生主数据的必须拦。

主数据的定义很直白：这笔数据一旦产生就必须归属于某个人 —— 订单、地址、优惠券、积分、评价。所以首页、分类、搜索、商品详情、购物车一律不拦登录；结算、订单、个人中心必须拦。拦得越早转化掉得越多，拦得越晚脏数据越多，这条边界是产品决策，不是技术约束。

• 登录方式别贪多。手机号 + 验证码解决「第一次来」，手机号 + 密码解决「天天来」。第三方登录看着热闹，但账号打通（同一个手机号在两处注册算不算同一个人）的治理成本，常常超过它带来的增量。
• 验证码必须配四道闸。60 秒重发、5 分钟失效、同号当日上限、错误次数锁定 —— 少一道，短信费用就会被刷成事故。
• 注册表单按「最少必要」排。手机号 → 验证码 → 密码 → 协议勾选。昵称、性别、生日全部挪到「个人信息」里再补。注册页每多一个字段，完成率就掉一截。
• 换绑手机号必须双向验证。验原号证明「你是主人」，验新号证明「新号收得到」。少验任意一边，都等于把账号直接送人。
• 找回密码不要泄露账号是否存在。「该手机号未注册」这种提示，是给撞库的人送情报。正确做法是统一口径，或者先过验证码再判断。

这条链路在本原型里是完整可点的：登录、注册、找回密码、更换手机号。验证码错误、协议未勾选、原号不符这些分支都能直接试出来。

八、支付与退款：钱的部分最容易出事

支付环节的验收只会盯一件事：钱和订单状态对不对得上。这里不写渠道对接细节，只列产品必须定义清楚的六条规则。

• 下单即锁库存，支付超时自动关单。默认 15~30 分钟，倒计时要在结算页看得见；关单必须把库存和优惠券一起释放，否则会出现「券用了、单没了」。
• 支付必须幂等。用户连点两下、网络重试、页面回退再进，都不能生成第二笔支付。靠的是「订单号 + 支付请求号」去重，不是前端把按钮禁掉。
• 支付结果以服务端回调为准。前端跳回「支付成功」不等于钱到了，所以要有「查询中」的中间态，而不是直接写成功。
• 退款是商品级的，优惠是订单级的。部分退款按商品实付金额比例分摊优惠，这条算法在结算页就得定下来。等出了客诉再补，账永远对不平。
• 退款到账时效要写清。「原路退回，1~7 个工作日」比「已退款」三个字有用得多，能挡掉大量客服咨询。
• 售后入口不能藏。确认收货后 7 天内的入口，订单列表和订单详情各放一次，客服工单量会明显下来。

对应的原型页面：结算页、支付结果、订单详情、售后申请。

九、消息与推送：别把通知做成骚扰

消息模块的目标不是「送达率」，而是打开率不被自己作死。三条通道各管一段，混着用就等着被关通知。

• 站内信管「有记录可查」：物流变更、退款进度、客服回复。它不打扰人，但必须可回溯。
• Push 管「现在不看会亏」：降价提醒、券将过期、秒杀开场。频率上限按天设，且必须允许按类型单独关闭。
• 短信只管「钱和高危动作」：支付验证码、换绑验证、异地登录。拿短信推促销，是花钱把用户推走。

两个最容易漏的一致性：角标数必须和列表未读数一致，不一致用户会觉得系统坏了；免打扰要落到服务端，只在客户端静音等于没做。

原型页面：消息中心、通知与省流设置。

十、常见问题（FAQ）

十一、继续学习

• 完整 PRD 文档与信息架构示例（功能清单 + 优先级）
• 演示入口：按模块挑一个页面开始点
• 商品详情页：SKU 规则与库存预占
• 购物车：合并规则与凑单设计
• 结算页：优惠分摊与支付幂等
• 登录：密码与验证码双通道
• 注册：协议门与手机号唯一性
• 更换手机号：原号 + 新号双向验证
• 消息中心：未读角标与消息分组
• 评价页：标签筛选与评分分布

每个页面右上角的「?」里有该页完整的产品备注 —— 埋点事件、异常边界、验收标准都在里面，可以直接当 PRD 模板改。