核心设计命题
在强规则服务中，信息完整性和规则确定性优先于形式上的极简。Overseas Web / 既有框架内体验优化
四川航空海外站
- 项目范围
- 海外官网核心自助服务 / 既有框架优化
- 我的角色
- 唯一设计负责人
- 负责范围
- 需求澄清、竞品调研、交互、视觉、HTML Demo、开发走查
- 项目状态
- 方案获甲方认可，进入开发与走查阶段
项目概览
项目背景与设计目标
在既有技术框架、页面结构和品牌规范内，提高核心服务的信息透明度，并把模糊需求转化为业务与研发可以共同评审的产品方案。
海外站缺少多项核心查询与自助服务，用户投诉又集中在规则和条件“没有说清楚”。甲方没有独立产品经理，业务需求通常以零散功能诉求直接进入设计。
项目约束
- 甲方没有独立产品经理，需求多以业务功能和用户投诉的形式直接进入设计。
- 既有技术框架、页面结构和品牌规范不能被推翻，优化必须在现实边界内完成。
- 开发走查期间业务范围仍可能变化，方案需要清楚区分规则、状态和可调整边界。
问题识别
从用户投诉识别真实设计问题
项目不是从完整 PRD 开始。现状页面、业务诉求与用户投诉共同构成输入，我先定位功能缺口、规则缺口和需要继续确认的服务边界。
现状首页与功能缺口
现状页面用于定位核心服务缺失、入口混杂和规则信息不足，而不是把项目包装成脱离约束的全面改版。
体验链路
核心体验链路
我把零散业务输入转译为六个连续步骤，并用可交互页面缩短设计、评审和开发之间的距离。
- 01业务诉求与用户投诉
- 02需求拆解与规则补齐
- 03流程与状态设计
- 04Figma 交互与视觉
- 05Codex + MCP 生成 HTML Demo
- 06会议评审、交付与走查
服务原则
让核心服务更清楚的设计原则
首页入口、规则说明和异常反馈分别回应用户在核心服务中的主要阻力。
高频任务优先
- 问题
- 海外站功能不足，现有首页又让服务入口、品牌与运营内容同时争夺注意力。 原始业务输入以功能清单为主，没有形成面向旅客任务的首页层级。
- 判断
- 先建立订票、航班状态、选座和行李等高频任务的清晰层级，再承接品牌内容。
- 结果
- 把订票、航班状态、选座和行李等高频任务放回清晰的首页服务层级。
规则就近可见
- 问题
- 用户最常见的投诉不是页面不够简洁，而是资格、限制和处理条件没有说清楚。 投诉反馈反复出现“没有说清楚”，说明核心矛盾是信息透明度，而不是页面留白多少。
- 判断
- 把规则放到用户做决定的位置，让用户在选择和确认前理解条件。
- 结果
- 在用户做决定的位置就近说明资格、限制、处理时间与不可办理原因。
选择符合服务条件的行程
查看餐食选项与限制
确认信息后提交申请
状态与异常完整覆盖
- 问题
- 无数据、不可办理和失败状态如果缺失，最终会由开发临时补充，也会让用户失去下一步。 业务与研发需要在评审阶段就确认异常由谁处理、页面应反馈什么。
- 判断
- 将不可用原因、状态反馈和恢复动作作为主流程的一部分设计。
- 结果
- 将空状态、失败反馈和下一步动作纳入主流程，使异常仍然可理解、可恢复。
按航班号或航线查询
Arrived：正常结果与详情入口
Delayed：异常原因与更新后的时间
不可用：说明原因并提供后续动作
关键交付 / AI 与人工收口
AI 用来补信息和铺底，关键判断由人自己收口
需求不完整时，AI 先帮助补齐问题、梳理业务并生成可讨论的草稿；信息筛选、业务优先级、交互状态和最终视觉由我完成。
- 01 / 补足信息ChatGPT
整理海外航空业务、竞品结构与待确认问题，产出只作为调研线索，不直接当作客户规则。
- 02 / 快速铺底Codex / Figma MCP
把已确认的页面结构和关键状态转成可操作草稿，缩短从静态稿到远程评审 Demo 的时间。
- 03 / 人工收口Manual review
我继续筛选信息、调整首页优先级、补齐规则与异常状态，并完成视觉和交互定稿。
- 04 / 规则反哺Design brief
把评审中确认的结构、状态和边界写回设计说明，供业务、设计和开发继续核对。
方案路径
方案推进与交付路径
将项目输入、方案形成与交付结果放回同一条推进链路。
| 阶段 | 工作内容 | 作用 |
|---|---|---|
| 输入 | 业务诉求与用户投诉 | 从功能要求和“没有说清楚”的投诉中识别真实任务与信息缺口。 |
| 澄清 | 需求拆解与规则补齐 | 将口头诉求整理为字段、前置条件、状态和需要业务确认的问题。 |
| 方案 | 完整产品原型 | 用页面流程和状态方案把业务输入转化为业务与研发可以共同评审的产品表达。 |
| 设计 | Figma 交互与视觉 | 在固定框架和品牌规范内完成信息层级、操作路径与界面表达。 |
| 原型 | Codex + MCP 生成 HTML Demo | 把核心设计稿转为可操作页面，验证状态切换和真实任务路径。 |
| 评审 | 远程会议演示与反馈 | 在视频会议中直接操作方案，暴露理解偏差并快速修改。 |
| 交付 | 开发走查与范围确认 | 持续核对视觉、交互和业务边界，并记录因现实条件发生的范围调整。 |
AI 评审
AI 如何改变方案评审
AI 的价值不在于代替设计判断，而在于把静态稿更快转成可操作的共同评审载体。
| 传统评审问题 | AI 辅助后的方式 |
|---|---|
| 静态稿难表达状态切换 | HTML Demo 可以直接操作 |
| 远程会议依赖口头说明 | 按真实任务路径演示 |
| 反馈后需要重做原型 | 复用代码结构快速调整 |
| 多页面容易出现结构偏差 | 共用页面规范与基础结构 |
结果与边界
项目结果、职责与验证边界
将已经确认的成果、个人职责、AI 工作方式与尚未验证的部分分开说明。
项目结果
将分散业务需求整理为可供业务与研发评审的产品方案，完成核心服务的交互与视觉设计，并进入开发与走查阶段。
我的职责
作为唯一设计负责人，我独立承担需求澄清、竞品调研、信息架构、交互、视觉、可交互 Demo、设计评审和开发走查。
AI 工作流
我先在 Figma 中完成业务逻辑与设计判断，再通过 Codex 与 MCP 生成可交互 HTML Demo，用于远程演示、反馈确认和结构复用。
验证边界
当前没有完整上线范围、真实用户验证和订票转化数据。开发走查期间的功能范围也可能根据业务与技术条件继续调整。
设计复盘
这个项目验证了两件事：在强规则业务中，设计师必须先补齐需求与服务边界；AI 可以缩短原型实现和反馈链路，但不能代替业务判断、规则梳理和体验取舍。
Codex + Figma MCP / 远程交互评审
用可交互 HTML Demo 验证核心服务
我先在 Figma 中完成业务逻辑和交互方案，再通过 Codex 与 MCP 生成可操作页面，用于远程评审流程、状态和页面结构。该 Demo 是方案验证工具，非最终视觉交付。四川航空SICHUAN AIRLINES
Travel notices, airport changes and operational updates are published here first for overseas passengers.
OFFICIAL ENTRY / GLOBAL SITE
Plan faster, travel with more confidence.
FromChengdu Shuangliu CTU
ToPhoenix PHX
Depart - ReturnFri 20 Mar - Mon 23 Mar
Passengers1 Adult
ClassEconomy
继续浏览