负责分析需求、设计体验、制作 AI 可运行原型，并参与开发交接、联调、测试、培训和上线支持。
MEDICAL EQUIPMENT SERVICE
让医疗设备报修、进度查询和服务确认
让医疗设备报修、进度查询和服务确认
都在微信里完成闭环。
把复杂的售后流程变成清楚、可追踪的微信服务。
RoleProduct Designer
Time2025.10—2026.06
PlatformWeChat Mini Program
DeliveryPhase I launched
项目概览
把以电话为主的报修方式，改造成可在微信中追踪的服务流程。
同时，新流程还要连接 D365，并处理权限、隐私和异常情况。
系统只在关键变化时通知用户；签字和评价也进入同一流程。
验证覆盖 5 类职能与异常状态。
WECHAT MINI PROGRAM / SERVICE JOURNEY
从识别设备到查看进度，
从识别设备到查看进度，
用户可以在微信里完成报修。
一次报修从入口开始，依次完成设备确认、问题提交和进度查询。
Context / 01
原有线上入口使用率低，电话仍是主要报修方式。
电话报修直接，但难以保存完整、统一的信息，也不方便用户持续查看进度。
项目开始前，87% 的报修通过电话完成，原微信服务号 H5 占 13%。原有页面步骤较多，也不符合用户常用的微信操作方式。
项目需要让用户更快确认设备、减少重复填写，并把 D365 状态改写成清楚的服务进度。同时，签字和评价流程必须满足隐私、权限与系统限制。
87%报修仍通过电话完成
17早期 Workshop 跨职能参与者
5Service / UX / IT / Legal / Security
Constraints / 02
先定义信息边界，再开始设计页面。
方案必须同时考虑 B2B 客户数据、用户权限、隐私评估、系统接口和 D365 改造成本。
先理清用户、设备、报修记录、工单和服务状态的关系，再确定页面、字段与操作。报修时只填写必要信息；处理时显示简化后的状态；诊断记录不对外展示；完成后提供报告、签字和评价。
用户需要知道当前发生了什么、谁在处理、下一步是什么，而不是看到全部内部状态。
Design principle · Information disclosure
Ecosystem / 03
一个微信小程序，连接用户、D365 和服务工程师。
负责设计微信小程序与 D365 之间的用户体验。
这套服务是否好用，取决于四件事：数据怎样进入系统、状态怎样显示给用户、异常怎样处理，以及用户每一步能做什么。
Service ecosystem一个用户入口，连接完整服务系统
报修 · 查询 · 签字 · 评价
识别设备 · 提交报修 · 查看进度
Case · 工单 · 核心数据
诊断 · 派工 · 处理 · 完成
↖
处理进展被翻译为客户可理解的状态
↙Repair Flow / 04
先识别设备，再填写故障信息。
减少重复填写
设备识别后优先带出已有信息，让用户专注本次故障。
翻译内部字段
询问“是否停机”等直接问题，再映射为后台字段。
补充现场信息
用户可以上传图片、视频或音频，不必只靠文字描述复杂故障。
扫码或输入设备编号
确认设备与服务地点
回答业务问题
图片、视频或音频
减少后续沟通成本
同步 D365 并开始追踪
Focus用户回答直接问题，系统负责映射后台字段。
不要求用户理解内部术语，也不从空白表单开始。
Ingenia 3.0T设备与服务地点已自动带出
- 设备是否停机？
- 否，未停机是，已停机
- 是否造成人员伤害？
- 否，未造成伤害
- 故障描述与附件
- 补充现场信息
- Origin
- WeChat Mini Program
- Priority
- 2 · System Down
- Description
- Harm, fault and media evidence
- Asset
- Ingenia 3.0T · 2093791
Status / 05
把后台节点翻译成用户能理解的服务进度。
一个后台事件，需要同时回答三个用户体验问题。
每个后台事件都要判断三件事：是否改变总进度、是否显示在详情中、是否需要主动通知。只有受理、备件、工程师安排和完成等关键变化会触发消息；其他操作只更新页面进度。
One event → Three decisions
用代表性节点说明状态如何被翻译
D365 内部节点总进度详情里看到主动通知
客户提交报修Create Case · New已报修报修已受理发送
C1 / RSE 分配远程工程师Route to RSE · New已报修已分配工程师不发送
C2 备件出库Parts Delivery · In Progress服务中备件已出库发送
Resource Planner 完成派工Dispatched · In Progress服务中已分配现场工程师发送
现场工程师出发Initial Travel · In Progress服务中不单独展示不发送
设计原则
重要变化主动通知，内部操作只更新进度。
UI evidence / Repair detail
总进度保持稳定，详情展开此刻需要的服务信息。
同一页面显示当前状态、待处理工单、工程师信息和完整进度。用户可以直接知道发生了什么、谁在处理、下一步要做什么。
- 01当前状态与下一步动作
- 02工单状态与签字入口
- 03用户可读的服务进度
Closure / 06
从身份验证到服务评价，每一步都要说明当前状态和负责人。
01 / Verify
先校验签字人身份，避免错误账号代为确认。
从短信或服务卡进入后，系统对比当前登录人与工单签字人；不一致时进入验证码校验。
02 / Confirm
在竖版工单中查看服务内容，再完成确认签字。
保留暂不签、签字人更换、多人顺序签字和重新发起等状态，避免把签字简化成单次点击。
03 / Evaluate
服务完成后邀请评价，低分再追问，48 小时后关闭。
远程与现场服务分别评价，让后续改进可以回到对应的服务环节。
AI proof / Verified edge case
账号不是签单人，能否继续签？
在梳理 D365 签字人与微信账号关系时，AI 帮助我把“账号不一致”扩展成一条完整异常路径。
- 01 / Input
D365 签字人字段、微信登录账号、短信入口与远程签字规则。
- 02 / AI conflict
直接放行可能让错误账号代签；完全拦截又会让真实签单人无法继续。
- 03 / My judgment
账号不一致时不能直接签字，但用户仍需要一个简单、可靠的身份验证方式。
- 04 / Prototype & UAT
在可运行原型中加入手机号后四位验证，并覆盖正确、错误与取消等异常状态。
- 05 / Final adjustment
工单列表只对有效任务显示“去签字”；进入后先比对账号，不一致时验证签单人手机号后四位。
Human judgmentAI 加速了检查，但身份边界、验证强度与最终取舍由我负责。
Service closure
工单查看、签字和评价属于同一条服务完成流程。只有需要用户确认时，页面才显示相应操作；其他状态由后台处理。
AI Workflow / 07
AI 提高需求分析、方案探索、原型制作和测试准备的效率，但设计决策仍由人完成。
AI 输出是探索起点。涉及合规、系统状态与真实交付时，仍由设计者判断并在实际环境中验证。
使用 ChatGPT 整理需求、检查状态冲突并补充测试场景，用 Figma Make 探索页面结构，再用 CodeBuddy / Codex 制作和调试可运行原型。所有结果经过人工检查后才交给开发。
明确目标与边界
ChatGPT 整理逻辑
Figma Make 快速探索
Figma 架构与交互
Codex 可运行原型
SIT · UAT · 上线
Human judgment throughout
定义产品边界判断系统状态审核 AI 结果验证真实运行
Validation & Delivery / 08
完整流程通过验证后，再进入培训和上线支持。
01 / Service flow
3轮 UAT：部分、全功能与回归Validated scope
设备识别与微信报修
D365 服务进度映射
02 / State & closure
≈20每轮参与者，可能重复Validated scope
关键节点通知
远程签字与服务评价
03 / Enablement
4 场终端培训 · 单场邀请 300+Validated scope
AI 可运行原型与开发交接
SIT、UAT、培训与上线支持