miki.
Page 01 / 08 — Cover
P2 — 纵深项目

CYG 智能仓储管理系统

Web管理端 + RF手持终端 | 双端全链路设计

为智能制造产线搭建可复用的组件体系，让不同客户的定制化需求通过模板组合覆盖，而不是每次从零开始。

角色 RF端独立负责 / Web端协作
交付 28页面 · 48弹窗组件 · 设计规范
状态 已上线
CYG WMS Hero Mockup
Page 02 / 08 — Situation & Tension
Situation

为什么这个项目很难

CYG集团的WMS服务于智能制造产线，要卖给不同行业客户。每家工艺流程和字段需求差异大，系统不能只服务一个客户，得是可持续迭代的产品平台。

我独立负责RF端UI与交互，和另一位设计师协作搭建Web端组件体系。产品经理给到HTML原型，原型侧重功能逻辑，交互细节和信息层级由设计侧定义。

与P1（质检机）最大的区别是资源条件：CYG是集团公司，开发资源和时间充足，设计自由度大。

Tension
矛盾 01
高度定制化 vs 交付效率
不同客户字段需求差异大，但不能每签一个客户就重新画一遍界面。
矛盾 02
Web端信息密度 vs RF端操作极简
Web端物料新增页五个区块、字段几十个；RF端是仓库工人在货架前操作——屏幕小、环境嘈杂、可能戴手套。
Web端侧边导航 — 系统体量一览
Web sidebar navigation
Page 03 / 08 — Tension可视化 + Trade-off 1
同一业务，不同呈现

信息密度差异：Web端 vs RF端

Trade-off 1 — Web端模板化策略

参考Material Design搭建组件规范，分两期迭代交付

三种列表模板——勾选版 / 序号版 / Tab+弹窗版。表单按信息类型分区块折叠。模块数量不固定，可按客户需求增减。

标准模板覆盖大部分场景，非标业务单独出图。

第一期 14 页面 + 26 弹窗
第二期 14 页面 + 22 弹窗
列表模板 3 种
Web view
Web端物料新增 — 5个信息区块
RF view
RF标准收货-按优先级重新分层
Page 04 / 08 — Trade-off 2 RF组件体系（上）
Trade-off 2 — RF端统一组件体系

四种收货模式 × 一套组件体系

PM根据不同客户工艺流程梳理出四种收货模式，业务上砍不掉。我的决策：用统一组件——扫码输入框、可展开卡片、明细折叠区、底部操作栏——承接所有流程，差异在信息层级和字段组合。

RF main flow
总入口
收货模式选择
四种收货模式的统一起点，同一扫码入口分流
Lite mode
轻流程
按单收货
扫码+确认，默认只显示3个关键字段
Standard mode
中流程
按箱收货
库位/托盘/箱号三级扫码 + Tab切换视角
Complex mode
重流程
标准收货
十几个字段，支持逐件扫描模式切换
扫码输入框组件
卡片列表组件
底部操作栏组件
同一组件，不同流程的统一起点
Page 05 / 08 — Trade-off 2 RF组件体系（下）· 核心展示页
深度对比 — 三种流程的信息层级差异

组件复用，但信息层级跟着场景走

轻流程 按单 · 步骤1
Light flow step 1
默认折叠：品名、应收/已收、收货数量三个关键字段。
轻流程 按单 · 步骤2
Light flow step 2
点击展开查看完整信息（重量、批次号、物料形态）。
中流程 按箱收货
Medium flow
Tab切换双视角：箱明细 / 物料汇总。
重流程 标准 · 步骤1
Heavy flow step 1
十几个字段全量展示，扫码自动填充减少手动输入。
重流程 标准 · 步骤2
Heavy flow step 2
逐件扫描开关：关闭批量，开启逐件确认。
四种模式 × 一套组件体系 — 开发只维护一套RF组件库，新增模式时组合现有组件即可
Page 06 / 08 — 操作反馈 + Trade-off 3 权限
RF端操作反馈体系

容错与反馈：左滑删除 · 二次确认 · 操作成功提示

Left swipe delete
收货核对 — 左滑删除
Delete confirmation
删除二次确认弹窗
Success toast
上架成功 — 可选继续/不再提示
Trade-off 3 — 权限设计

菜单权限 + 用户范围 + 仓库维度

Permission settings
与P1不同，WMS天然需要仓库维度的数据隔离。不做按钮级——同一角色进入页面后操作权限基本一致。两个项目权限粒度不同，是业务场景和资源条件的差异，不是设计标准的差异。
跨项目权限对比
P1 质检机
初创公司资源受限 → 只做菜单级权限，四类角色各看各的模块
P2 WMS
集团公司资源充足 → 菜单级 + 用户范围 + 仓库维度三层，但不做按钮级（无场景驱动）
权限粒度跟着业务场景和公司条件走，不是越细越好
Page 07 / 08 — 组件规范与设计系统
Design System

基于Material Design本地化的设计规范 · 跨项目通用

色彩体系、字体规范、图标库、组件使用规则全部文档化交付开发团队。这套规范不仅服务于WMS，也沉淀为公司跨项目的通用设计资产。

Color, font, icon spec
色彩 · 字体 · 图标规范
Popup component spec
弹窗组件规范
主色 #EA2028
辅助 #0066FF
字体 SimSun + Arial
两级标题体系
组件文档化 + 使用规则
Page 08 / 08 — Evidence & Reflection
Evidence — 结果

系统上线交付

28
Web端页面
48
弹窗/小窗组件
12
RF功能入口
4
收货模式全部落地

模块数量可按客户需求配置。组件规范文档化交付开发，沉淀跨项目通用设计规范。

具体业务数据未获取——toB项目数据反馈周期长，组件化交付后工作重心转向规范维护。

设计周期
双期迭代交付
规范文档
跨项目通用
当前状态
已上线运行
如果重来

两个我现在会改的决定

不接受红色做系统主色
品牌色#EA2028直接用在所有按钮和主操作上。但WMS里红色同时承担警告、异常、删除的语义——收货核对的删除是红色，提交也是红色。RF端小屏幕上满眼红色，时刻像在预警。应该争取把主操作色和警告色做区分。
给不同重量级的流程做不同交互节奏
标准收货十几个字段的重流程，和按单收货扫码确认的轻流程，当时给了几乎相同的界面节奏。轻流程应该有更短的操作路径——组件可以复用，但节奏应该跟着场景走。
跨项目对比结论

P1是资源受限下的极简设计；P2是充分资源下的系统化设计。
两者都是在当前约束下最合理的决策，不存在哪个更"正确"。