← 返回作品

商家 SaaS

06 / 08

婚礼纪案例管理改版

统一改版商家 Web 与 App 的案例管理体验

项目一览

问题商家反馈和产品规划都指向案例发布、分类和管理流程中的阻力。

我的工作我负责商家 Web 与 App 的完整案例改版,包括流程、信息层级、案例管理、响应式表格、发布体验和跨端 UI。

历史结果旧作品集记录上线一个月后的完成率、时长和流失变化,但原始统计口径已无法核对。

婚礼纪海草云案例流程改版封面。
海草云是婚礼纪的商家端产品,所有需要上传案例的商家类目都会使用这套流程。

背景与证据

商家反馈和产品规划都指向案例流程

海草云是婚礼纪的商家端产品。所有需要上传案例的商家类目,都会通过这套流程发布作品并维护案例库。

项目由商家反馈和产品规划共同推动。旧数据漏斗显示,不少商家开始填写,却没有走到发布;但数据只能指出问题位置,不能解释原因。

产品和运营完成了 100 多次电话访谈,并由产品团队把信息提供给我。商家提到表单太长、进度不清楚、分类调整慢,小屏笔记本上的表格也不好读。

案例发布各阶段流失的数据漏斗。
漏斗确定了需要调查的位置,但没有直接给出原因。
案例发布和管理问题的访谈结论。
访谈把流失与具体的流程、管理和阅读问题联系起来。

设计范围

把 Web 与 App 作为同一个案例管理项目

我负责商家 Web 与 App 的完整改版。两个端使用相同的案例字段,也服务同一批商家,因此我把它们作为一套系统设计,而不是两个独立项目。

发布和浏览案例是高频工作。排序与分类管理仍然需要保留,但不必占据同样的视觉层级。我把分类编辑放进列表,减少页面跳转;低频操作仍然可用,但不会压过主要内容。

导航、案例发布和内容管理的设计目标。
设计范围同时回应业务目标和商家反复提到的问题。
案例分类编辑改版前后的流程。
分类调整从独立页面移回当前列表。

案例管理

让大量案例更容易浏览和调整

我提高了案例状态、分类和主要操作的可见性。商家可以直接查看分类数量,修改名称和排序,不必逐个打开案例。

小屏笔记本是真实使用场景,因此我为表格定义了疏密度、图文行高、列宽适配、横向滚动和重要列固定等规则。

改版后的婚礼纪商家案例管理页。
列表页成为浏览、筛选与管理案例的主要位置。
列表内的分类管理与排序细节。
分类数量、命名与排序放在被修改内容附近。
表格疏密度、行高和响应式规则。
表格被整理成可复用规则,不只是修补单个页面。

案例发布

把长表单拆成看得见的进度

发布案例需要填写很多信息。我没有继续拉长单页表单,而是把内容分成三个清楚可见的步骤。

商家能看到当前进度,也知道提交前还剩什么,并可随时保存草稿。

海草云商家的三步案例发布流程。
三步进度减少了长表单带来的不确定感。

跨端设计

保持同一套案例模型,再为移动端调整界面

商家 Web 与 App 属于同一个项目,也都由我负责。两个平台面向同一批商家并使用相同的案例字段,如果采用不同的底层逻辑,反而会产生不必要的歧义。

我保持信息层级和视觉规则一致,再为移动端调整布局。发布入口保持突出;分类管理和排序收为次要操作;案例卡片则展示快速浏览时需要的信息。

婚礼纪商家 App 案例管理改版前后。
App 降低了低频管理操作的视觉权重,也让发布入口更容易找到。
婚礼纪商家 App 不同案例管理页面采用统一卡片结构。
相关管理页面复用同一套卡片层级和操作样式。
婚礼纪商家 App 的三步案例发布流程。
三步发布结构也延伸到 App。

上线验证

由相关产品团队验证上线后的体验

上线后,相关产品团队对 Web 与 App 的体验进行了验证。现有项目记录保留了下方一个月后的结果数据。

原始 Dashboard、样本定义和具体验证方式已无法取得,因此这些结果属于历史证据,并非重新核验过的 Analytics。

历史结果

方向有改善,但数据有明确边界

旧作品集记录:上线一个月后,案例填写时长减少 30 秒,总发布时长减少 48 秒,完成率提高 18.4%,页面流失率降低 12%。

原始 Dashboard、样本定义和计算方式没有保留下来。这些数字可以作为产品团队保留的历史记录,但不能视为重新核验过的数据。

旧作品集记录的上线一个月结果与项目总结。
结果沿用旧项目记录,未作为重新验证的 Analytics 呈现。

下一个项目

婚礼策划频道改版

继续查看围绕真实案例、信任和决策信息的消费端改版

查看 Project 07 →