文章目录

Product Design / Interaction Design / Native Development

iPet 是一个基于开源桌宠 VPet 的 Apple 平台再设计项目。

它最初来自一个很简单的愿望：

如果我想在 Mac 上养一只这样的桌宠，它应该是什么样子？

原版 VPet 建立在 Windows 的桌面环境、交互习惯和技术体系之上。把它带到 macOS，并不只是让程序“能够运行”。

真正的问题是：

当一个属于 Windows 的桌宠进入 Apple 的设备生态后，哪些体验应该被保留，哪些需要重新设计？

因此，我没有把 iPet 看成一次单纯的软件移植，而是把它当成一次关于数字陪伴、桌面空间与跨平台体验转译的设计练习。

01 / 从一个“不存在的 Mac 版本”开始

我喜欢桌宠这种很特殊的软件形态。

它不像普通 App 那样等待用户主动打开。

相反，它长期存在于桌面边缘：

偶尔移动、偶尔说话、偶尔被注意到。

它和用户的关系，更接近一个数字空间中的“小生物”。

这也是我觉得 VPet 有趣的地方。

但原版主要面向 Windows。

于是最初的问题非常直接：

我能不能在 macOS 上拥有同样的体验？

真正开始后，我很快意识到，“做一个 Mac 版”其实包含两个完全不同的目标。

一个是：

让功能存在。

另一个是：

让它像一个 Mac 上本来就应该存在的产品。

我更关心后者。

02 / 桌宠不是一个窗口，而是一种空间关系

普通软件的交互关系通常很清晰：

用户
 ↓
打开 App
 ↓
完成任务
 ↓
关闭 App

但桌宠并不是这样。

它长期停留在：

桌面
工作窗口
浏览器
聊天软件
文件

之间。

因此，第一个需要解决的问题并不是“画一个角色”，而是：

这个角色应该怎样存在于用户的桌面里？

如果它像普通窗口一样：

  • 有矩形点击区域
  • 抢占键盘焦点
  • 遮挡下面的软件
  • 每次点击都激活应用

那么它虽然“运行了”，却并不像桌宠。

所以 iPet 最初的设计目标其实只有一句话：

让角色存在，但尽量不打扰。

03 / Presence without interruption

我逐渐把这种体验总结成：

Presence without interruption

有存在感，但不造成打断。

这成为后来很多交互决策的基础。

例如角色虽然视觉上只有一个小动物，但系统里的窗口实际上仍然是一个矩形。

如果直接使用普通窗口：

┌────────────────────┐
│                    │
│       Pet          │
│                    │
└────────────────────┘

整个区域都会挡住鼠标。

最终我选择让交互区域跟随角色本身的透明度：

可见角色
→ 可以点击 / 抚摸 / 拖动

透明区域
→ 鼠标继续操作后面的应用

这样用户可以在角色旁边正常操作网页、Figma 或其他软件。

角色“在那里”，但不会因为自己的存在破坏原本的工作流。

这也是 iPet 中我最喜欢的一类设计：

用户不一定能明确看到设计，但能够感觉到它没有妨碍自己。

04 / 从“窗口”变成“角色”

第二个问题是：

用户到底是在拖动一个窗口，还是在抓住一个角色？

这两者的感受完全不同。

如果按照传统桌面软件的逻辑，拖动对象应该是窗口标题栏。

但桌宠没有标题栏。

因此交互对象必须从：

Window

转变成：

Character

我逐渐建立了一套更接近“触碰生物”的交互：

轻触
→ 抚摸

长按
→ 捏住

拖动
→ 提起 / 移动

松开
→ 回到桌面行为

角色因此不再只是一个播放动画的 Sprite。

用户是在直接和它的“身体”发生交互。

这其实很接近实体产品设计里的一个问题：

用户操作的是“界面”，还是“物”本身？

在 iPet 中，我希望尽量减少这两者之间的距离。

05 / 不把所有功能都塞进角色

桌宠很容易出现一个问题：

功能越来越多以后，角色周围会不断增加按钮、状态条、菜单和信息。

最后它会从：

陪伴对象

变成：

桌面控制面板。

所以在功能增加的过程中，我开始刻意区分两种体验：

Ambient Interaction

与角色直接相关、低打扰的操作。

例如：

  • 抚摸
  • 拖动
  • 喂食
  • 简短对话
  • 状态反馈

Focused Interaction

需要用户明确进入操作状态的内容。

例如：

  • 商店
  • 背包
  • 统计
  • 设置
  • 日程
  • 详细活动管理

因此 iPet 最终形成了两个层级：

桌面上的角色
      ↓
轻量即时互动

功能面板
      ↓
复杂管理任务

这种分离让我避免把所有 UI 都贴到桌宠旁边。

角色首先还是一个角色。

只有当用户主动需要管理时，它才变成一个完整 App。

06 / 随宠工具栏：介于两者之间

但仅有角色和完整面板，中间仍然缺少一个层级。

例如：

用户只是想：

  • 看一下当前状态
  • 开始一个活动
  • 暂停工作
  • 看剩余时间

为了这些操作打开完整功能页又显得过重。

于是后来增加了一个 Pet Toolbar。

它更像一个依附于角色的小型控制器：

角色
 │
 ├ 状态
 ├ 活动
 ├ 时间
 └ 快捷操作

但这里又出现新的问题：

工具栏本身会不会开始打扰用户？

于是后来增加了自动隐藏机制。

当用户离开一段时间后：

Toolbar
→ fade / hide

鼠标重新回到角色附近：

Pet Hover
→ Toolbar returns

因此界面可以在：

需要时出现，不需要时消失。

这和我希望的桌宠整体体验是一致的。

07 / “活着”的感觉从哪里来？

动画数量并不等于生命感。

如果一个角色拥有几百个动作，但只是随机播放，它仍然很容易让人觉得像一个屏保。

因此我开始思考：

什么让一个数字角色看起来像是在“生活”？

最后我发现真正重要的是三个层次：

① Motion

它会动。

② State

它的行为受到当前状态影响。

③ Continuity

过去发生的事情会影响之后。

于是 iPet 的行为逐渐从简单动画发展成：

饱腹
口渴
体力
心情
健康
好感

        ↓

当前状态

        ↓

动作 / 消息 / 活动

        ↓

新的状态

例如：

它并不是简单播放“吃东西”动画。

而是：

用户选择食物
→ 角色进食
→ 属性变化
→ 产生反馈
→ 保存结果

这时角色才开始产生一种连续性。

08 / 时间成为产品的一部分

桌宠和普通工具软件还有一个非常不同的地方：

它是一个和时间共同存在的产品。

用户不会连续操作它几十分钟。

更多时候是：

工作
↓
偶尔瞥一眼
↓
摸一下
↓
继续工作

因此很多设计问题其实都围绕时间展开：

  • 多久自主移动一次？
  • 多久说一次话？
  • 工具栏多久隐藏？
  • 活动怎样显示剩余时间？
  • 睡眠期间状态如何变化？
  • 用户离开电脑以后发生什么？

这让我第一次非常明确地意识到：

Interaction Design 不只是 Button → Result。

它也包含：

Time → Behavior。

桌宠本身就是一种基于时间的交互媒介。

09 / 把 Windows 体验“翻译”成 macOS

在项目后期，我越来越少问：

原版这个按钮在哪里？

而更多会问：

原版为什么需要这个按钮？

这是整个项目里最重要的变化之一。

例如原版的一些功能依赖：

  • Windows 窗口机制
  • WPF
  • Steam
  • 系统托盘
  • Windows 特有输入模型

如果只是照搬界面，很容易得到一个：

长得像 Windows 软件的 Mac 应用。

因此我的原则逐渐变成：

保留意图
而不是保留形式

也就是：

Preserve the intent, redesign the interaction.

保留：

  • 功能目的
  • 行为逻辑
  • 角色反馈
  • 用户心智模型

但重新思考：

  • 界面
  • 输入方式
  • 页面结构
  • 生命周期
  • 平台反馈

这也是为什么 iPet 最终并不是一个视觉上一比一复制的 VPet。

10 / iPhone 上，桌宠还应该是桌宠吗？

当 iPet 后来扩展到 iPhone 和 iPad 时，我遇到了一个更明显的问题。

macOS 上可以让角色：

漂浮在桌面

但 iOS 不允许一个 App 的角色一直悬浮在其他 App 上。

如果追求“完全一致”，这个产品甚至没有办法成立。

于是问题变成了：

如果不能拥有“桌面”，桌宠最核心的体验是什么？

我最后保留的是：

陪伴和养成。

而不是：

悬浮窗口。

所以 iOS 版本变成了一种：

In-app Pet

用户进入 App 后和角色互动。

保留：

  • 养成状态
  • 活动
  • 商店
  • 背包
  • 对话
  • 本地进度

重新设计：

  • 触摸
  • 页面结构
  • 导航
  • 移动端布局

而 macOS 独有的：

  • 桌面漂浮
  • 全局拖动
  • 鼠标穿透
  • 多屏移动

则不强行迁移。

这让我更加确定：

跨平台设计不是让两个平台完全一样。

真正需要统一的是产品核心，而不是所有交互形式。

11 / 从产品到系统

随着项目继续推进，我发现设计工作本身也发生了变化。

最开始我关注：

这个按钮应该在哪里？
这个角色应该怎么动？

后来开始关注：

这个状态应该由谁控制？

两个动画冲突怎么办？

用户隐藏角色后系统应该如何处理？

应用重新打开后应该恢复什么？

什么属于角色状态？

什么属于设备偏好？

问题逐渐从：

Screen Design

进入：

System Design

例如：

字体大小、工具栏自动隐藏属于设备偏好。

而：

金币
等级
库存
心情

属于角色本身。

这两类数据不应该被混在一起。

类似的区分越来越多。

这让我开始意识到：

产品设计不仅是在设计用户看得见的界面，也是在设计系统内部的边界。

12 / AI 成为了项目中的一种设计工具

iPet 还有一个对我很特别的部分：

它是我第一次真正长期使用 AI 参与完整项目。

AI 并不是单独替我“生成一个 App”。

我的工作方式更接近：

观察
↓
提出问题
↓
定义目标
↓
拆分阶段
↓
让 AI 分析与实现
↓
真实体验
↓
发现问题
↓
重新设计

例如某个功能：

活动菜单

第一版在逻辑上可能是成立的。

但真正放到桌面上使用以后，我会发现：

  • 层级太深
  • 展开方式不自然
  • 与角色关系太弱

于是再重新调整。

因此 AI 更像是一个非常快速的：

engineering collaborator

而我仍然需要不断完成：

判断
选择
体验
取舍

这个过程也让我重新理解了设计师在 AI 工具中的位置：

AI 可以极大缩短“从想法到可运行原型”的距离，但它不会替代设计决策本身。

13 / 设计结果

现在的 iPet 已经形成了一个相对完整的 Apple 平台桌宠体验。

macOS

一个存在于桌面的数字角色：

  • 透明背景
  • 按角色轮廓交互
  • 抚摸与拖动
  • 自主行动
  • 状态反馈
  • 对话
  • 工作 / 学习 / 娱乐
  • 商店与背包
  • 随宠工具栏
  • 完整管理界面

iPhone / iPad

一个以养成体验为核心的移动端版本：

  • 固定角色
  • 触摸互动
  • 活动
  • 商店
  • 背包
  • 设置
  • 独立本地进度

两个平台共享同一个产品核心，但拥有不同的交互方式。

14 / 我从 iPet 得到的东西

iPet 最初只是一次：

“我想让这个桌宠出现在我的 Mac 上。”

但最后它变成了我第一次真正经历的完整数字产品设计过程。

我开始接触：

Product Thinking
Interaction Design
System Design
Platform Design
State Design
Motion
Software Architecture
Testing
Open-source Collaboration
AI-assisted Development

更重要的是，我逐渐开始理解：

设计并不只发生在 Figma 里。

一个角色是否抢占焦点，

一个按钮什么时候应该出现，

应用关闭以后什么应该保留，

iPhone 和 Mac 是否真的应该拥有相同界面，

这些其实全部都是设计。

Reflection

如果让我重新定义 iPet，我不会把它称为：

“VPet 的 Mac 移植版”。

我更愿意把它描述成：

一次将 Windows 桌宠重新翻译到 Apple 生态中的体验设计实验。

我做的并不是把一个软件从一个系统搬到另一个系统。

而是在不断回答：

一个数字角色，应该怎样自然地生活在用户的设备里？

iPet

Digital Companion for Apple Platforms

Role

Product Design
Interaction Design
System Design
Development

Platform

macOS · iOS · iPadOS

Based on

VPet by LorisYounger