01 项目概览
这个项目先要处理关系，再处理页面
App、智能设备、运营后台和售后团队都在使用同一台设备的信息，但各自关注的状态和动作不同。我负责把设备身份、用户归属、经销商关系和服务记录放进同一套业务规则。
02 业务背景
设备发生异常时，不同角色看到的是同一个问题
用户只知道“设备不能用”，经销商要判断服务关系，运营和售后还要核对设备身份、当前状态与历史记录。原有信息分散在不同入口后，一次故障很容易在角色交接时丢失上下文。
03 我先做的事
先画清角色、状态和责任边界
我没有直接把功能拆成 App 页面和后台菜单，而是先确定设备、用户、经销商和售后之间的关系：哪些状态由设备产生，哪些由业务操作产生，谁能修改，以及用户在什么节点可以继续下一步。
- 设备与用户关系不清时，后台难以定位服务对象
- 连接、绑定、授权和业务可用状态需要分别判断
- 故障信息必须关联设备、用户与历史状态
- 经销商、运营与售后拥有不同的查看和处理范围
- App 需要把受理、处理与完成状态反馈给用户
04 用户与场景
同一台设备，在不同角色眼中意味着不同任务
确认设备是否可用，查看设备详情，发起报修并跟踪处理进度。
确认设备归属与服务关系，为用户提供第一层支持。
从设备、用户和历史状态中定位问题，推进并记录服务结果。
05 我的职责
重点处理多端关系、设备状态与售后承接
- 梳理用户、设备、经销商、运营与售后关系
- 定义绑定、在线、授权、异常与服务状态
- 设计 App 侧设备查看、操作与报修路径
- 规划后台设备、OTA、工单与权限模块
- 输出核心原型、PRD 与评审材料
- 协同设备侧、研发和测试验证跨端流程
06 多端分工
每一端只承担自己能够确认的事实
查看设备、发起报修并跟踪进度。
提供身份、状态、数据与指令结果。
承接运营和售后动作，将处理节点同步给用户。
- 01用户 App
确认设备与异常
- 02故障报修
继承设备上下文
- 03后台工单
生成并分配任务
- 04经销商 / 售后
处理并记录结果
- 05用户查看进度
获取处理节点与结果
07 报修过程
一次设备异常怎样被后台接住
- 用户在设备页确认异常
- 报修入口继承当前设备身份
- 用户补充故障现象和必要凭证
- 后台生成带设备上下文的工单
- 经销商或售后接收并处理
- 处理节点同步到 App
- 用户查看进度或补充信息
- 完成后保留服务记录
08 产品证据
真实页面证明问题如何从 App 进入后台
以下为项目真实原型页面，截图中的设备名称、号码、时间和状态均为演示数据，不代表真实运营规模。
集中确认设备身份、状态和异常。
我的设计重点我把状态放在低频信息之前，异常紧跟可执行入口。
区分用于判断状态的信息与用于执行操作的入口。
我的设计重点实时状态和关键数据先回答“能否使用”，常用操作再回答“现在做什么”。
让当前设备的问题直接进入售后流程。
我的设计重点自动带入设备与账号信息，用户只补充故障现象和必要凭证。
让用户提交的问题在后台被识别、分配并持续处理。
我的设计重点工单保留设备、用户、经销商、优先级与当前节点，处理结果再回到用户侧。
回答当前由谁处理、处理到哪里。
我的设计重点用时间线呈现关键节点，并保留补充说明与联系入口。
09 三个具体判断
状态、入口和表单都围绕设备上下文
我把“已连接”与绑定、授权和业务条件分开；设备详情在阻塞位置直接给出处理动作。
异常最容易在设备页被发现，报修入口也留在设备路径中，避免用户重新寻找和描述对象。
表单自动带入设备、账号和已知状态；用户只补充现场现象和必要凭证。
10 协作难点
同一个“处理中”，各端可能理解不同
设备信号、App 展示和后台记录来自不同环节，我需要确认每个状态由谁产生、何时更新、失败后怎样恢复。
用户、经销商、运营与售后都参与服务，查看范围、处理动作和交接条件必须在评审时写清。
11 当前产品
App 与设备运营后台均可访问
App 供用户查看和操作设备、提交报修并跟踪进度；后台供运营、经销商和售后查询设备关系、分配工单与记录处理结果。
12 如果重新推进
我会更早拉齐设备状态与售后动作
我会在第一轮评审时就把设备信号、App 展示、后台状态和售后动作整理成同一份状态表，并让报修表单优先复用系统已知信息。这样能更早暴露“谁产生状态、谁负责处理、用户看到什么”这些分歧。