NAS 运营管理后台
所有角色看同一个真相
一套 NAS 硬件的运营管理后台。生产、质检、出货、激活、运行监控、告警、售后，一台设备的整条链路都在这里管。
17→1
同一台设备的信息，旧版散在 17 个页面和弹窗里；重制后收进一张设备详情
5→4
旧版讨论期留下 5 套导航框架；重制按任务收成 4 个任务中心，另设工作台
22/68
设备详情 68 个字段，22 个常驻，其余按需展开
01Context
没有完整 PRD，先理清业务对象和角色
设备从工厂出来，要经过生产、质检、入库、出货，到用户手里激活。之后还有运行监控、固件升级、告警和售后。
生产、运营、运维、客服四类人围着同一台设备工作，关心的事完全不同。团队小，没有完整 PRD，我从业务结构反推每个角色要做什么，再把各自的信息挂到同一个设备 ID 上。
02Main task
运维处理一台异常设备：从告警走到售后
这是后台里最高频、也最能说明问题的一条任务。在旧版里，它要在几个模块之间来回跳。每跳一次，运维都要重新输一遍 SN。后面三个决定，都是为了让这条路走直。
旧版 · 四个模块来回跳
2026 重制版 · 一条路走完
- 01收到告警发生了什么、影响、下一步
- 02找到设备顶栏搜 SN，直接筛出来
- 03判断原因设备详情顶部先说告警
- 04转给售后告警直接转工单，三段内容预填
03Anchor
拒绝按角色切后台，围绕设备 ID 组织信息
按角色拆成几个后台，看起来各管各的。代价是同一台设备的信息散在不同系统里，跨角色追踪会断。比较过三种组织方式：
1
按角色切分信息割裂
否决2
按流程切分流程不总是线性
部分采用3
按设备对象组织一台设备一个 ID
采用每台设备一个唯一 ID，所有信息挂在这个 ID 上。不同角色进来看到不同的默认视角，但随时能跳到完整信息。
04Structure
从功能入口堆叠，到围绕任务组织
旧版在讨论期前后出现过 5 套导航框架：先按功能分（产品管理、设备管理），再按部门分（生产与质检、仓储与物流），最后又改成左侧 8 个平级菜单。产品需求没理清、业务也没梳理好，每次调整都在“按什么切”上打转。
重制时换了一个问题：用户进系统是为了完成什么事？模块只是路径，任务才是入口。最后收成 4 个任务中心，另设工作台作为登录后的第一屏。这 4 个任务中心当年停在方案阶段，这次重制第一次做成界面。
同一件事，走几步
计步规则相同：从首页出发，每次点击、选择、输入、查询各算 1 步。
最后一条变长了，照实写。旧版点“处理”填完意见就结束，看不出谁在跟、跟到哪；重制版多一步受理，换来每条反馈都有状态和负责人。
Why旧版 5 套框架怎么来的
旧版 5 套框架依次是：
- 继承的多页签底座
- V1.0 设备生命周期主干
- 生产运维向（四组菜单变体）
- 用户运营向左侧竖菜单
- 上一套的改名版
顺序为推断，以当事人记忆为准。
出库登记与固件发布两条任务，重制版流程不同或尚未开放，不纳入对比。
05Layers
设备详情，是判断问题的工作台
一台设备的信息在重制版里有 68 个字段。哪些常驻、哪些收起，用三个问题判断。
Why常驻四组与收起六组
22 个常驻字段分身份与生产、运行、用户与服务、异常四组；其余 46 个按生产记录、出货物流、证书、运行明细、用户与服务、售后六组收起，按需展开。
关键字段完整展示，辅助字段在极限宽度下允许缩写或折叠；数值字段设最大列宽和安全间距，防止粘连误读。运维排查时的误读成本，比页面整齐重要得多。
这和 Case B 的“系统能替用户决定的，就别让用户反复配置”是同一个判断。
状态串成一条生命周期
旧版里有 11 个状态维度，散在各个页面上：占用、打印、注册、在线、测试、包装、返工、发货等。同一台设备要拼着看。重制版把它们串成一条生命周期，9 个状态分生产、运行、售后三段；在线、离线、从未上线单独一列，不和生命周期混在一起。
筛选分两层
5 个高频筛选常驻，6 个低频收进“更多”。普通筛选记住上一次的条件，常用组合可以存成个人视图；涉及用户手机号这类敏感条件，默认不记忆。
06Screens
所有推导，最终落成可用的界面
设备列表：高频筛选常驻，状态色一眼可判。这一页由 Ludi Design Kit 按项目合同生成；动画里的五步是 kit 的实际流程，见 Case C。
界面里的人名、设备和单号都是虚构数据。
07Then & now
同一台设备的信息，当年在哪，现在在哪
设备详情
出入库记录
08Design system
界面做完，再收成一套能复用的组件库
从基础控件到筛选区、表格、详情抽屉，每个组件都写了用法和禁止事项。21 张页面模板全部由这些组件拼出来，改一个主组件，模板跟着变。
- 31基础组件
按钮、输入、表格单元到提示 - 14复合组件
导航、筛选区、表格面板、抽屉 - 21页面模板
工作台到告警规则 - 40图标
16 像素网格，颜色走变量
10Review
B 端设计的核心：能判断、能处理、能追踪
做得好的
- 01从业务对象推架构——不按部门切菜单，信息都挂到“设备 ID”上，跨角色追踪不再断。
- 02字段分层有标准——68 个字段里 22 个常驻、46 个收起，用“能不能被告警兜底”等三个问题判断，可以复用到同类后台。
- 03按任务组织功能——4 个任务中心让一条异常从告警走到售后，不用在模块之间来回跳。
做得不够好的
- 01字段分层靠经验——22 个常驻字段是人工判断归的类，没有埋点数据看哪些字段真的常用；硬件加新指标时，归到哪一层还要人工定。
- 02没有上线数据——在职版没有正式上线，重制版在自建底座上跑通，处理时长、操作失误率都没有前后对比。
- 03权限还不够细——生产、运维、售后看手机号、家庭网络这类敏感信息时怎么脱敏、怎么留审计记录，要和正式后端一起定。
重制时补了一条教训：当年的封面数字没有留下计数口径，这次全部按设计稿和源码重新数过。