上周帮朋友看他的电商小程序，打开订单详情页我愣住了——整页从上到下拉了四屏，订单号、商品信息、收货地址、支付方式、物流详情、发票信息、优惠券明细、平台服务费全部平铺在一页上，字号全是14px灰色，没有任何视觉层级。我问他用户找"申请售后"要花多久，他说后台数据显示这个入口的点击率只有2%，大部分用户直接找客服。
订单详情页是电商产品里用户打开频率最高的页面之一——下了单要看、发货了要看、到哪了要看、要退货也要从这里进。但大部分产品和设计团队做这个页面的时候，习惯性地把数据库里的订单字段全部搬上去，堆出一个"信息垃圾场"。真正好的订单详情页不是信息多，而是用户在每种订单状态下，能在3秒内找到他最关心的那一条信息，能在1秒内找到他下一步最可能点的那个按钮。
订单详情页设计四个核心原则
| 1 | 状态决定信息：不同订单状态下，用户关心的信息完全不同。待付款阶段最关心金额和倒计时，待收货阶段最关心物流位置，已完成阶段最关心售后入口 |
| 2 | 操作按钮驱动页面：不是把信息展示完就结束了，每个状态都要有一个明确的主操作按钮（CTA），它是页面的视觉重心 |
| 3 | 信息分级，不是信息罗列：订单详情页最多展示两层信息——首屏核心信息（状态+金额+物流+主按钮），下滑后次要信息（商品详情+支付方式+订单编号+发票），不要所有字段一视同仁 |
| 4 | C端和B端完全两个物种：C端订单详情页追求"一眼看完"，B端订单详情页追求"所有信息可追溯"。用C端的思路做B端，或者反过来，都会翻车 |
一、先搞清楚订单状态机，再谈页面设计
订单详情页设计的第一件事不是画界面，是画状态机。订单在整个生命周期里会经过多个状态节点，每个节点下用户看到的页面内容应该不一样——这句话说起来简单，但很多产品经理和设计师根本没有把"状态×信息×操作"的矩阵画出来就直接开始画UI。
| 订单状态 | 用户最关心什么 | 主操作按钮 | 辅助操作 | 页面焦点信息 |
|---|---|---|---|---|
| 待付款 | 还有多久过期、总共多少钱 | 立即支付 | 取消订单 | 金额+倒计时+支付方式 |
| 待发货 | 什么时候发货、地址对不对 | 提醒发货 | 修改地址/申请退款 | 预计发货时间+收货地址 |
| 待收货 | 快递到哪了、什么时候到 | 查看物流 | 确认收货/申请退款 | 物流进度条+预计送达时间 |
| 已完成 | 有问题找谁、能不能退 | 去评价 | 申请售后/再次购买 | 售后入口+商品快照 |
| 已取消/退款中 | 钱退了吗、什么时候到账 | 查看退款进度 | 联系客服 | 退款金额+预计到账时间+退款路径 |
很多团队在这里犯的错
把所有状态共用一个页面模板，然后用"if状态=待付款 show支付按钮"的逻辑来控制显示隐藏。这样做开发成本最低，但页面的信息优先级完全错了——已完成状态的页面首屏还在展示支付方式和优惠券，用户想找售后入口得滑到第三屏。正确的做法是：每个状态独立设计信息架构，哪些信息提到首屏、哪些收到折叠区、哪些干脆不展示，完全由状态决定。
二、从顶部往下拆，每个区域放什么、为什么这么放
拿一个标准的C端电商订单详情页，从上到下拆成七个区域，每个区域的设计逻辑不是"数据库里有什么就放什么"，而是"用户在这个状态下打开页面，他最想看到什么"。
| 区域 | 位置 | 放什么 | 设计要点 |
|---|---|---|---|
| 状态横幅 | 页面最顶部 | 订单状态文案 + 状态图标 + 预计时间 | 状态文案不要只写"待发货"，写成"商家预计8月8日前发货"。用颜色区分状态：待付款橙、待发货蓝、待收货绿、已完成灰 |
| 物流/进度区 | 状态横幅下方 | 物流节点时间线 + 当前位置（地图可选） | 已发货状态才展示，其他状态不展示。物流进度条用节点+连接线的方式，已完成节点绿色、当前节点蓝色、未开始节点灰色 |
| 收货地址 | 物流区下方 | 收件人+电话（脱敏）+完整地址 | 待发货状态下提供"修改地址"入口，已发货状态下地址只读。电话中间四位打星号 |
| 商品清单 | 地址下方 | 商品缩略图+名称+规格+单价+数量+小计 | 每个商品可点击跳转商品详情页（已完成状态下跳转"商品快照"，防止商品信息变更后对不上）。多个商品时用列表，单个商品用大卡片 |
| 价格明细 | 商品清单下方 | 商品总价+运费+优惠券+实付款 | 实付款用大字号+加粗+品牌色，其余明细用小字号灰色。优惠券项可展开查看详情 |
| 订单信息 | 价格下方（可折叠） | 订单编号+下单时间+支付方式+支付时间 | 默认折叠，点"查看更多"展开。订单编号旁边放"复制"按钮。这些信息用户极少需要看，不要占首屏空间 |
| 底部操作栏 | 页面底部固定 | 主操作按钮+辅助操作按钮 | 固定在屏幕底部，不随页面滚动。主按钮用品牌色实心大按钮，辅助按钮用灰色边框小按钮。一个状态最多放2个操作按钮，超过2个的把低频操作收进"更多" |
物流进度条的设计细节
不要用纯文字堆物流信息。用节点+时间线的方式，每个物流节点左边一个圆点（已完成绿色、当前蓝色脉冲、未开始灰色），右边是时间和描述。超过3个节点时默认只展示最近3条，其余折叠。复制物流单号的按钮放在物流区右上角。
收货地址的安全脱敏
收件人姓名只显示姓+星号（如"张**"），手机号中间四位星号（138****5678），详细地址完整显示。这个脱敏规则在产品设计阶段就要定好，不要等上线后被用户投诉了再改。
三、主操作按钮放在哪，是订单详情页最重要的交互决策
打开淘宝、京东、美团、拼多多四个APP的订单详情页，看看底部操作栏的设计，差别非常大——这种差别不是审美偏好，是商业模式和用户场景决定的。
| APP | 待付款主按钮 | 待收货主按钮 | 按钮布局方式 | 值得注意的设计 |
|---|---|---|---|---|
| 淘宝 | 去支付（实心橙红） | 查看物流+确认收货 | 底部固定双按钮 | 待收货状态下确认收货是弱按钮（灰色边框），防误触 |
| 京东 | 去支付（实心红） | 查看物流+确认收货 | 底部固定双按钮+更多菜单 | 京东把申请售后、退款等低频操作收进"更多"按钮，底部只留两个 |
| 美团外卖 | 去支付（实心黄） | 配送地图占半屏+催单 | 配送中：地图卡片+底部催单按钮 | 外卖订单的核心信息是配送位置，所以地图卡片占半屏，这是正确的信息优先级 |
| 拼多多 | 去支付（实心红） | 查看物流+确认收货 | 底部固定双按钮 | 售后入口在三级菜单里（我的→订单→详情→更多→申请售后），路径太深是刻意为之，降低售后发起率 |
按钮设计的三个铁律
第一，一个状态最多2个操作按钮，超过2个的把第三优先级操作收进"更多"（···）。底部操作栏超过3个按钮时，用户的决策时间会显著增加，误触率也会上去。第二，主操作和危险操作必须视觉隔离——"去支付"用实心品牌色，"取消订单"用灰色文字按钮，两者中间至少留16px间距。第三，已完成状态不要空着底部操作栏，放"再次购买"或"去评价"，这个位置是黄金流量入口，空着等于浪费。
四、C端和B端订单详情页，看起来像其实是两个物种
很多人觉得订单详情页不就是展示订单信息吗，C端和B端能有多大区别？实际上区别大到应该用两套完全不同的设计思路。
| 对比维度 | C端（淘宝/京东/美团） | B端（ERP后台/商家后台/企业采购） |
|---|---|---|
| 用户目标 | 快速查看物流/退款/售后，停留时间短 | 核对订单信息/审批/对账/导出，停留时间长 |
| 信息密度 | 精简，一屏展示完核心信息 | 完整，所有字段都要可见、可搜索、可导出 |
| 操作按钮 | 底部固定1-2个按钮，操作即走 | 顶部或侧边多个操作按钮（审核/发货/退款/打印/导出） |
| 信息展示方式 | 卡片+分区，视觉层次强 | 表单+表格为主，信息密度高，可左右对比 |
| 状态数量 | 5-8个状态 | 15-30个状态（含子状态：待审核/审核中/已驳回/部分发货/已签收待结算等） |
| 页面布局 | 单列垂直滚动，移动端优先 | PC端为主，左右分栏（左侧订单信息，右侧操作日志/审批流） |
| 数据字段 | 15-25个字段 | 40-80个字段，含内部编码、成本价、供应商信息、审批记录等 |
B端订单详情页的特殊需求
B端页面需要展示"操作日志"——谁在什么时间做了什么操作（创建订单→主管审批→财务审核→仓库发货→客户签收），每一条日志带时间戳和操作人。还需要支持"打印订单""导出PDF""关联合同/发票"等功能，这些在C端完全不需要。
B端信息架构推荐做法
用Tab切换代替一页全堆：基本信息Tab、商品明细Tab、财务信息Tab、操作日志Tab、附件Tab。每个Tab独立加载，既解决了信息密度问题，也提升了页面加载速度。
五、最常见的五个设计错误，90%的团队都犯过
错误一：所有状态共用一个页面模板
已取消的订单页面还在展示物流进度条和"确认收货"按钮的灰色禁用态。用户看到灰色按钮的第一反应是"为什么不能点？是不是出了什么问题？"——这种困惑本身就在消耗用户信任。不同状态下，页面展示的模块和按钮应该是完全不同的组合，而不是同一个模板用if-else控制显隐。
错误二：售后入口藏太深
拼多多把售后藏在三级菜单是业务策略（降低售后率），但如果你做的不是拼多多这种体量的平台，刻意隐藏售后入口只会增加客服压力和用户差评。已完成状态的订单详情页，"申请售后"和"联系客服"两个入口至少有一个要放在首屏可见的位置。
错误三：商品信息没有做"快照"
用户下单后，商家修改了商品标题、价格或主图，然后用户打开订单详情页点商品链接，看到的已经是修改后的商品信息了——价格对不上、图片不一样，直接引发纠纷。订单详情页里的商品信息必须读取下单时刻的快照数据，而不是实时查询商品表。已完成状态的订单详情页，点击商品应该跳转"订单快照页"而非商品详情页。
错误四：倒计时结束但没有任何提示
待付款订单30分钟不支付自动取消。但很多产品的订单详情页上，倒计时归零后页面只是静悄悄地变成"已取消"，用户如果刚好在倒计时最后几秒打开页面，看到的是上一秒还有支付按钮、下一秒按钮消失了——非常迷惑。倒计时归零时需要给一个明确的过渡状态（如弹窗提示"订单已超时，已自动取消"），或者至少状态横幅有明显的动画过渡。
错误五：操作按钮不给反馈
用户点了"取消订单"，按钮变成灰色但没有loading状态、没有Toast提示、页面没有跳转——用户不知道操作成功了没有，又点了一下，结果触发了两次请求。所有操作按钮点击后必须立即给反馈：按钮变为loading态（转圈+禁用），请求完成后给Toast提示结果（"订单已取消"），然后页面状态自动刷新。
六、从设计稿到开发落地，有哪些地方需要跟前端明确对齐
订单详情页不是一个纯UI问题，后端数据结构、状态机逻辑、异常情况处理都会直接影响前端展示。设计师如果只画了正常状态的页面，开发拿到后只能自己脑补异常状态，上线后就会出现各种边缘情况的展示问题。
空状态和加载态
页面首次加载时的骨架屏、数据为空时的空状态插图、网络异常时的重试按钮——这三个状态的设计稿必须和正常状态一起交付。特别是物流信息为空时（刚发货还没揽收），不要显示空白，而是显示"等待快递员揽收"。
数据超长截断规则
收货地址超过30字怎么显示？商品名称超过50字怎么截断？备注信息超过100字是折叠还是滚动？这些截断规则要在设计阶段定好，而不是等开发来问。地址超长用省略号+点击展开，商品名超长用两行截断。
价格精度和格式
价格保留几位小数？要不要千分位逗号？¥符号放左边还是右边？这些细节影响用户对金额的感知。金额用¥符号+千分位+两位小数（¥1,299.00），优惠金额前面加负号（-¥50.00），退款金额用红色。
多商品订单的分组展示
一个订单买了5个商品，但其中3个已发货、2个还在备货，怎么展示？按包裹分组的做法：在商品清单区按物流包裹拆分成多个小组，每组上方显示该包裹的物流状态和单号。
说到系统化落地，很多电商团队在搭建订单体系时遇到的一个实际问题是：订单详情页的前端展示逻辑和后台状态机紧密耦合，改一个状态要前端后端一起改，迭代很慢。如果用UC建站系统的WP底层+AI管理层架构，订单详情页作为独立模板部署，状态机和前端展示逻辑分离，修改页面布局和视觉不需要动后端代码。对于需要同时管理多个品牌独立站、每个站订单详情页风格不同的团队来说，这种模板独立部署的方式比传统电商SaaS灵活得多——改一个站的订单详情页不会影响其他站。
七、从0到1画一个订单详情页，完整的执行步骤
不要一上来就打开Figma画界面。按下面这个顺序走，能少返工至少两轮。
步骤一：画出完整的状态机图
用流程图工具画出所有订单状态和状态之间的流转条件。标准C端电商至少包含：待付款→待发货→待收货→已完成，加上分支：已取消、退款中、已退款、部分退款。每个状态旁边标注：触发条件、可执行操作、超时自动流转规则。
步骤二：列出每个状态下的"信息×操作"矩阵
横轴是订单状态，纵轴是页面模块（状态横幅、物流区、地址区、商品区、价格区、订单信息区、底部操作栏）。每个格子填写：这个状态下该模块显示什么内容、优先级是P0（必须首屏）还是P1（可下滑）还是P2（可折叠）还是不展示。填完这个矩阵，页面的信息架构就出来了。
步骤三：确定移动端和PC端的差异策略
C端订单详情页70%以上的流量来自移动端，所以移动端设计是主版本，PC端做适配。PC端可以利用更宽的屏幕，把商品清单和物流信息左右并排展示，减少纵向滚动。底部操作栏在PC端不需要固定悬浮，可以直接放在页面底部。
步骤四：画线框图，先不碰视觉
先用灰阶线框图确定每个模块的位置、大小、间距。拿待收货状态做第一个版本，因为它包含最多的信息模块（物流+地址+商品+价格+操作）。待收货版本确定后，再基于同一个框架调整其他状态的差异。每个状态的线框图都要单独评审，不要只画一个状态就当全部完成了。
步骤五：视觉设计+异常状态补全
在线框图确认后开始做视觉设计：颜色、字体、图标、圆角、阴影。同时补全所有异常状态的设计稿——网络加载失败、订单不存在（用户扫了一个错误的二维码）、订单已过期、数据为空、价格计算异常。这些异常状态的展示方式和文案，至少要和正常状态一起输出。
步骤六：输出标注文档，不要只给设计稿
设计稿交给开发时，附上一份标注文档：每个字段的数据来源（哪个接口的哪个字段）、截断规则、空值展示规则、状态颜色映射表、按钮的loading态和禁用态规则、页面各模块的加载顺序。开发拿到这份文档，能减少至少50%的来回沟通。
最后说一句，订单详情页是整个电商产品里最"重"的页面之一——它不是一次设计完就再也不用改的。业务每增加一种订单类型（预售、拼团、秒杀、周期购），订单详情页就可能需要适配新的状态和信息模块。所以前期设计的时候，信息架构的扩展性比视觉好不好看重要得多。把状态机画清楚、把"信息×操作"矩阵填完整、把异常状态想透彻，这三点做到了，订单详情页的设计就完成了80%。剩下的颜色、字体、圆角，说实话都是细节，后面慢慢调就行。
订单详情页设计自查清单
| 检查项 | 通过标准 |
|---|---|
| 状态机是否完整 | 所有状态+子状态+流转条件已画成状态机图，产品/设计/开发三方确认 |
| 每个状态是否有独立的信息架构 | 每个状态首屏展示的信息不超过5个模块，次要信息已折叠或移到下滑区 |
| 操作按钮是否清晰 | 每个状态底部最多2个操作按钮，主按钮用品牌色实心，危险操作用弱化样式 |
| 异常状态是否覆盖 | 加载中/加载失败/数据为空/订单不存在/网络异常五种异常状态都有设计稿 |
| 商品快照是否独立存储 | 订单详情页的商品信息读取下单时刻的快照数据，不实时查询商品表 |
| 移动端和PC端是否分别设计 | 移动端单列垂直滚动为主版本，PC端左右分栏适配，底部操作栏PC端不悬浮 |
| 数据截断和脱敏规则是否明确 | 地址超长/姓名手机号脱敏/金额格式/商品名截断等规则已在设计阶段确定 |
| 操作反馈是否即时 | 所有按钮点击后0.3秒内进入loading态，操作完成后有Toast提示+页面状态刷新 |
