问题不只是把货飞起来。
真正的摩擦发生在“最后一公里”：用户看不到落地过程，调度员同时盯多架无人机，物业只能被动处理噪音、安全和秩序投诉。
飞行能力之外，需要信任能力。INTERFACE · FLOWS · ATMOSPHERE
Interface
as a quiet
conversation.
From low-altitude logistics systems and travel decision tools to medical recruitment platforms, my interface work balances operational logic with tone of voice. 复杂服务被拆成角色、任务、状态与反馈；界面不再只是视觉表层，而是让行动、判断和协作自然发生的秩序。
MEDICAL UX
TRAVEL EXPERIENCE
INTERNAL TOOLS
DRONE SERVICE SYSTEM
12
36
88
115
SYSTEM
A QUIET INTERFACE FOR BECOMING
SHI
CASE 01 · SKYPICK · DRONE INTERACTION SYSTEM
SkyPick
从下单到落地
无人机物流配送的全链路交互体验设计。项目不是把无人机做成一个炫酷硬件展示，而是围绕消费者、调度员、物业三类角色，把下单、起飞、航线监控、异常预警、社区治理和签收确认组织成一个可信任的服务闭环。 A low-altitude logistics UX system that turns flight status, risk signals, and handoff rules into visible trust.
LOW-ALTITUDE ECONOMY
THREE-END CLOSED LOOP
UI / UX SYSTEM
TRUST RECONSTRUCTION
飞跃云端，使命必达。SkyPick 基于低空经济和多场景研究，将“运力的游戏”重构为“信任的系统”：让用户知道包裹在哪里，让调度员提前看到风险，让物业拥有社区空域治理工具。
把等待变成可掌控。
消费者端覆盖弱网下单、实时轨迹、落地前环境自检、人脸识别签收，让“包裹在哪、何时到、能否安全落地”都被界面讲清楚。
Passive waiting → Active control让物业有前置工具。
社区空域地图、禁飞区、禁飞时间、站点设施管理和投诉闭环，让物业从“事后处理”转向“事前治理”。
Community airspace becomes operable.人和物的摩擦被放大。
大件搬运过度依赖人工，包裹堆积导致查找低效；根源不是单点功能缺失，而是包裹、路线、社区和人的协同链路断裂。
Objects and people need one shared flow.三端一体，全链路闭环。
SkyPick 把消费者、调度员、物业放进同一条数据链：订单与签收、航线监控与预警、社区治理与反馈在系统内持续同步。
Order · Flight · Governance · Feedback从监控转向预测。
调度端以 2D/3D 空域监控、红橙黄预警、语音指令调度和备用无人机交接，降低多机任务下的信息负担。
Monitoring → Prediction → Dispatch每个角色都看到自己的确定性。
用户获得物流透明感，调度员获得异常优先级，物业获得空间治理权限；系统用同一组状态把三方动作连接起来。
Trust is distributed by role.从骨架验证到可信体验。
低保真验证信息架构、层级和核心路径；高保真则把可用性推进到可信任感，建立控制感、专业感和服务记忆点。
Usable → Trustworthy → MemorablePROJECT DETAIL · UI / UX SYSTEM
从研究、系统到界面，把无人机配送讲完整。
研究、服务蓝图、三端架构与高保真界面被放在同一条服务链中：SkyPick 的核心不是展示一架无人机，而是让低空物流从下单、调度、社区治理到签收反馈都具有稳定秩序。
RESEARCH
SERVICE BLUEPRINT
VISUAL SYSTEM
HI-FI UI
01 · WHY THIS PROJECT
低空物流真正缺的是服务确定性。
文档中的问题定义指向三类不确定：用户缺少落地过程控制，调度员缺少主动预警工具，物业缺少社区空域治理手段。SkyPick 的价值，就是把这些不确定变成可读、可控、可追踪的界面状态。
CONSUMER ANXIETY
从“等通知”改为“看得见”：路线、预计到达、环境检查、签收安全都在交付链路内呈现。
DISPATCH LOAD
多机并行时，系统将风险分级、航线冲突和备用机交接前置，避免调度员被动救火。
COMMUNITY ORDER
物业拥有禁飞区、时间窗、站点和投诉闭环工具，降低社区接受无人机物流的心理门槛。
TRUST SYSTEM
创新不在单一功能，而在把低空物流从“运力游戏”重构为“信任系统”。
01ORDER弱网下单与地址确认
02DISPATCH载重、距离、航线生成
03FLIGHT实时轨迹与异常预警
04LANDING环境自检与站点协同
05SIGN OFF人脸签收与服务归档
02 · THREE-END ARCHITECTURE
三端共同闭环，而不是各自独立。
消费者端解决透明化交付，调度员端解决主动化预警，物业端解决前置化社区治理。三个角色围绕同一条物流状态链协作，让每个动作都有上下文。
01 · USER APP
消费者端
LIVE ROLE
SYNC
SYNC
下单、弱网保护、实时追踪、落地前环境自检、人脸识别签收，让配送不可见带来的焦虑被逐层消解。
SIGNAL 01可见轨迹
SIGNAL 02实时 ETA
SIGNAL 03安全签收
03 · RESEARCH TO STRUCTURE
从行为映射到信息架构。
研究部分包含竞品分析、用户画像、行为映射、需求层级、生命周期和信息架构。它们共同回答一个问题：无人机配送在不同角色眼里，哪些状态必须被提前看见？
BEHAVIOR MAPPING
把取件通知、信息刷屏、订单堆积、站点维护、人货寻找和低空穿梭拆成连续行为节点。
INFORMATION ARCHITECTURE
从用户生命周期反推信息层级：先给状态，再给原因，最后给可执行动作。
04 · PROTOTYPE EVOLUTION
从骨架验证到可信界面。
低保真阶段确认路径能不能跑通，高保真阶段确认系统能不能被信任。这里把“寄件配置、无人机监控、登录验证”串起来，展示从任务骨架到真实服务入口的演进。
先验证距离、续航、载重和确认动作是否能形成清楚任务链，再进入视觉精修。
监控页把电量、净重、速度、预计到达和站点信息组合成可读状态。
登录与验证码不是孤立页面，而是账号安全、服务权限和后续签收信任的入口。
05 · VISUAL SYSTEM
视觉系统服务于信任感。
视觉不是装饰。凌云蓝负责科技与行动提示，使命黑负责专业度，航迹灰控制信息层级，晴空白保证阅读，天际蓝让状态反馈更轻。
COLOR TOKENS
凌云蓝 · SOARING BLUE
主行动色，用在关键按钮、航线高亮、实时状态和科技感连接线，承担“可以继续操作”的信号。
TYPE / ICON LANGUAGE
PingFang SC · iOS native rhythm
11-34 pt
Caption / Footnote / Body / Title 11 / 13 / 17 / 28
桌面启动图标：精准、高效、可靠 DRONE SYMBOL
底部导航：用户与核心功能的视觉桥 BLUE / BLACK STATES
功能图标降低认知负荷 TWO-TONE UI
06 · UI DESIGN
把可信物流变成可操作界面。
高保真阶段从“能用”推进到“可信”：启动页强化品牌记忆，登录降低进入门槛，物流专区把等待焦虑转成可见飞行体验，消息和客服让问题可以迅速回到服务闭环。
LOW-FI PROTOTYPE
低保真是骨架阶段，用来验证信息架构、层级、核心路径和三端可行性。
HI-FI EXPERIENCE
高保真是信任重构：把控制感、专业感和配送安全感转译成视觉与交互细节。
START / GUIDE
先建立品牌记忆，再进入任务。
启动与引导页避免空白等待，同时提前告诉用户权限、角色偏好和服务边界。
07 · OPERATION SCREENS
调度和空域也被界面化。
对调度员和物业来说，高级感不是更炫，而是更快判断风险。蓝色状态层、预警色和空间面板共同形成专业、冷静的操作语气。
SkyPick 的创新不在于单一功能，而在于把低空物流重构为信任系统。
当每个角色都能在自己的场景里从被动焦虑转向主动掌控，无人机才不只是“飞过来的设备”，而成为一条完整、可解释、可被信任的城市配送体验。
CASE 02 · YUNYE 云野｜旅行决策产品原型
Runnable travel decisions. 云野｜把旅行攻略从松散信息流整理成“规划 → 验证 → 打包”的决策产品原型。
云野来自真实旅行规划里的反复犹豫：想去哪里、值不值得去、路线怎么排、出发前要带什么。项目不是再做一个攻略集合，而是把评论、收藏和对比信息重新组织成可执行的决策链，让用户先获得判断，再进入行动。 UX strategy + runnable prototype, built from real planning friction.
CHAPTER 01 · HOW I RESEARCH 调研方式
From "feeds" to "decisions". 先收集真实纠结，再把它们整理成可用路径。
我没有先写抽象人设，而是从评论区、收藏夹和“还是不确定”的提问里找重复摩擦，再把它们压缩成三个决策时刻：去哪、怎么去、带什么。 Instead of starting from personas, I start from hesitation in the wild and translate it into decision moments.
01 · Capture raw hesitation （小红书/论坛/收藏夹：真实纠结句）
02 · Cluster into decision moments （去哪/怎么排/怎么验证/怎么打包）
03 · Translate into structure （IA + Flow：把"内容"变"决策路径"）
04 · Prototype early & test rhythm （可运行验证：节奏/边界/落地性）
研究不是"证明我对"，而是让每一步决策更可复用、更省脑力。
WHAT THIS MEANS
When people say “this already exists”, they often mean:
the surface exists, but the decision layer doesn’t.
（表层功能有了，但决策链没被照顾。）
CHAPTER 02 · COMPETITIVE SCAN 竞品拆解
Not "who is better", but "what decision layer is missing".
我拆解竞品时不比较“谁更强”，而是看它们在帮助用户做决定时缺了哪一层：信息是否可信、路线是否可对比、下一步是否明确。 The goal is not to copy features. I keep useful clarity, refuse the ad-first rhythm, and add a proof layer for trust.
| Product | Strengths | Weakness / Friction | Takeaway for YUNYE | |
|---|---|---|---|---|
Mafengwo
马蜂窝
|
Huge travel note base, mature “guide + note” structure, strong destination indexing | Commercialization heavy, feed noise, mixed incentives, decision scattered by “content gravity” | Borrow "content structure", refuse "ad-first rhythm"（内容结构强，但决策链被信息流冲散） | |
Round Trip
圆周旅行
|
Clear itinerary entry, readable planning flow, “day-by-day” structure feels actionable | Thin proof layer / date contrast missing（缺少"不同日期对比"的可信度机制） | Keep planning clarity, add “proof layer” + “date contrast” | |
Xiaohongshu
小红书（内容决策入口）
|
Fresh UGC, strong “real scene” perception, quick trend discovery, rich comments as friction source | Search results noisy, commercialization + “note economy”, information hard to converge into a plan | Real friction signals（收藏/评论/反复问）→ compress into Plan/Prove/Pack（把"信息"压成"动作"） | |
Ctrip
携程（资源与交易）
|
Strong resource coverage: tickets/hotels/transport, stable supply chain, one-stop booking | Often “booking-first”, decision support layer is secondary, content layer can feel template-like | Booking strong, decision weak（资源很强，但"怎么选"仍靠用户自己） | |
Refuse
Ad-first rhythm, fake notes, endless scrolling.｜拒绝：广告节奏、伪内容、刷到疲惫。
Borrow
Structure + signals: guide skeleton + real friction clues.｜吸收：结构骨架 + 真实信号（收藏/评论/日期对照）。
Differentiate
Decision-layer product: Plan → Prove → Pack.｜独特：把"出行犹豫"做成可闭环的决策链。
CHAPTER 03 · FROM DATA TO DECISION 证据链与方法
Research that can be checked.
I don't "invent numbers". I build a traceable chain: source → sampling → coding → clustering → decision artifacts（来源→抽样→编码→聚类→产出物）. This makes the UX decisions explainable and reusable.
SOURCES
0 channels｜四类真实来源
CLUSTERS
0 moments｜三类决策时刻
ARTIFACTS
0 layers｜三层产出物
EVIDENCE SOURCES 证据来源
Where friction comes from.
此处只展示证据类型与决策层级，不声明百分比；真实截图与来源保留在项目归档中。
METHOD 数据化方法
From messy inputs to runnable structure.
0
steps
Evidence nodes. 研究信号节点。
PRODUCT ARTIFACTS 产出物
Decision layers, not decoration.
Plan｜路线与节奏可执行
decision layer
Prove｜可信度证据层
decision layer
Pack｜装备与行前清单
decision layer
云野想解决的不是"信息不够"，而是"信息太多但无法下决定"。所以把证据链做进流程里，让人更快做出可执行选择。
Public comments · “值不值”
Source type: public comments and repeated hesitation phrases
Saved lists · time / transport friction
Source type: saved lists, itinerary notes and route comparisons
Map reviews · weather / altitude / gear
Source type: map reviews and pre-trip checklist questions
云野不是“又一个攻略 App”，而是把 犹豫 → 比较 → 行动 压缩成一条能跑的决策链。
CHAPTER 04 · BUILD IT 可运行原型
Prototype that can be used, not just shown.
我先把流程做成可运行原型，用来验证导航深度、决策节奏和边界情况；AI 只是轻介入的辅助，不替代用户自己的判断。 A connected prototype tested the product rhythm before any intelligence layer was added.
CHAPTER 05 · INTERFACE GLIMPSES 界面瞬间
Selected moments only.
Key process frames｜把"美"压在"可用"之下。
hover to breathe · click to view
CLARITY
Hierarchy for decisions, not decoration.｜层级为决策服务
TEMPO
Micro-motion guides attention quietly.｜微动效引导节奏
ATMOSPHERE
Morandi restraint, highland-night mood.｜克制氛围感，适配徒步/露营场景
EPILOGUE · 结语
Design is not decoration.
It is decision, made visible.
I build concepts fast, then turn them into runnable structures.
我更在意“想法是否成立”，也有能力把它做成可以上线的东西。
If a product can’t help people decide, it becomes noise.
如果一个界面不能帮助人做决定，那它只是另一种噪音。
CASE 03 · JIAHUI 嘉会｜招聘运营 HR SaaS 概念重设计
Operational clarity. 嘉会｜面向招聘运营的 HR SaaS 概念重设计，让状态、字段和下一步更清楚，减少 HR 反复确认。
从真实招聘运营摩擦出发，而不是先做功能假设。
基于我在上海嘉会国际医院招聘运营实习中的岗位发布、简历筛选、面试流转与 offer / 入职状态回收等实践，我做了一次流程复盘，并将高频摩擦转译为一个虚拟 HR 招聘 SaaS 概念重设计。它不是对现有系统或内部访谈数据的复刻，而是基于招聘运营实践与流程复盘形成的概念方案。 A status-first HR SaaS concept redesign.
My Design Position
01
Reduce high-frequency ops friction
（把"筛选/流转/确认"做得更省心：少点跳转、少做重复判断）
02
Make status & next-step explicit
（任何时刻都能回答：现在在哪、卡在哪、下一步是谁负责）
03
Increase decision confidence with structure
（用信息层级与关键字段，让 HR 不必反复"问一圈"才能下结论）
Research I Did
梳理招聘运营的高频任务流：岗位管理、简历筛选、面试推进、offer/入职状态回收。
Recruiting process review
Mapped recurring checkpoints from recruiting operations practice to clarify decision moments and handoff rules.
（确认"谁在什么节点做决定"，以及信息交接需要哪些最小字段）
Mapped recurring checkpoints from recruiting operations practice to clarify decision moments and handoff rules.
（确认"谁在什么节点做决定"，以及信息交接需要哪些最小字段）
Platform usage reflection
Heuristic review of common recruiting SaaS patterns: status logic, info hierarchy, batch operations, and collaboration cues.
（重点复盘：状态可信度、字段优先级、批量操作效率、协同提示）
Heuristic review of common recruiting SaaS patterns: status logic, info hierarchy, batch operations, and collaboration cues.
（重点复盘：状态可信度、字段优先级、批量操作效率、协同提示）
我以招聘运营执行者、候选人与用人侧协作的多视角，把体验问题落到可验证的流程与界面结构上。
Key Insight
A recruitment SaaS is not a timeline.
It's a decision system that reduces uncertainty.
对 HR 来说，后台价值不是"看起来流程在走"，而是让每个节点的状态可信、信息可用、下一步明确，从而降低协同与决策成本。
用候选人侧小原型反向验证后台状态是否清楚。
这个轻量级 App 原型不是正式产品，而是验证工具：候选人能否读懂当前进度、是否知道接下来会发生什么、反馈节奏是否稳定。它用来反向校验后台状态设计是否真的可被理解。 Candidate-side validation for back-office status logic.
Web Console UI Snapshots （招聘后台的关键页面快照（概念方案，用于呈现信息结构与关键交互））
A focused set of screens covering the core ops loop: job management, pipeline, candidate profile, interview ops, and handoff states. （覆盖高频任务链路：岗位、人才库、候选人档案、面试推进、状态回收与协同提示）
01 · DASHBOARD
OPEN
Status Hub
Dashboard overview
招聘运营需要先看清整体状态：待筛选、面试排期、关键提醒和数据概况放在同一张工作台里。
DESIGN PROCESS · STEP BY STEP
How I approached the problem As a recruitment operator, not just a UI executor.
在一开始，我并没有直接进入界面设计，而是先回到招聘工作的本质：
为什么这个节点需要存在
为什么 HR 会在这里犹豫
为什么信息在系统中是"看得见但不好用的"
STEP 01
Problem Framing
在真实招聘流程中，我发现核心问题并不集中在某一个页面，而是出现在流程衔接与状态理解之间的断层。
HR 经常需要反复确认：
这个候选人现在算不算"推进中"？
是否已经进入下一轮？
这个状态是系统规则，还是人为判断？
HR 经常需要反复确认：
这个候选人现在算不算"推进中"？
是否已经进入下一轮？
这个状态是系统规则，还是人为判断？
Focus
Reduce unnecessary confirmation
Goal
Clear and explainable status
Tone
Operational, not emotional
WHAT HAPPENED AFTER THE STEPS
From assumption to structured rules.
在形成系统结构后，我并没有直接假设方案成立，而是通过对比与拆解把规则写清楚。
Evidence Board
Decision
左侧证据与右侧规则保持同一组判断线索。
UX Rule
01
UX Rule 01
HR Perspective: Align system status with real recruitment logic
HR Perspective: Align system status with real recruitment logic
系统中的每一个状态，都必须能够对应到现实招聘中的真实行为或判断，
而不是仅仅作为流程占位。
Status-rule clarity
状态规则清晰度
状态规则清晰度
Mapped
Next-step visibility
下一步可见性
下一步可见性
Explicit
Process trust cues
流程信任线索
流程信任线索
Traceable
Micro-interaction
Status that speaks operational language.
我将状态设计视为一种内部沟通接口， 而不是单纯的视觉反馈。
- 01 Status must be explainable
HR 能清楚知道：为什么会停在这里。 - 02 Feedback must be predictable
下一步是谁，大概多久，会发生什么。 - 03 Key confirmation should be lightweight
减少重复确认，而不是制造心理负担。
Submitted
SUBMITTED
我们已收到该候选人的投递
当前处于简历初筛阶段
预计 1–2 个工作日内完成判断
当前处于简历初筛阶段
预计 1–2 个工作日内完成判断
ETA
24–48h Next
Initial Review
24–48h Next
Initial Review
Evidence (What I Actually Changed)
I translated ops pain points into concrete UI rules: status taxonomy, field priority, batch actions, and collaboration cues.
把"难用"拆成可落地的规则：状态体系、字段优先级、批量操作、协同提示。
Structure (How It Holds Together)
The design centers on a stable mental model: Pipeline → Candidate → Action → Feedback. Every screen supports clearer decisions for recruiting operations and hiring-side reviewers.
以稳定心智模型串起页面：流程 → 候选人 → 操作 → 反馈，服务招聘运营与用人侧的判断效率。
EPILOGUE · 结语
Design is not decoration.
It is clarity, made deliberate.
在这个医疗 UI 项目中，我关注的并不是界面是否"更丰富"，
而是每一个结构、层级与反馈，是否真正减少了犹豫与误解。
医疗场景本身已经足够复杂，
设计的责任不是增加存在感，而是让关键信息自然浮现，
让人知道自己身在何处，接下来会发生什么。
这一章所呈现的，是我在 Interface 层面的核心立场：
让界面成为秩序，而不是干扰。
NAVIGATION