智能穿戴 App 原型设计的重点不是把手机页面缩小，而是让手表、手环和手机在有限屏幕、短交互和不稳定连接下仍能完成任务。一个可评审的方案至少要覆盖设备形态、运动或提醒主路径、关键状态、手机协同和断联恢复。下面以“查看一次运动记录并同步到手机”为例，给出可直接跟做的原型方法。
如果你要先搭建圆屏、方屏和手环界面，可以从墨刀智能穿戴界面设计开始，再在墨刀原型中补齐页面状态和手机协同。产品页适合确认组件和设备场景，本文聚焦一个 App 原型如何落地、评审和交接。
先定义交付：一次操作要在哪个设备完成
智能穿戴方案常见的问题是只画手表主界面，却没有说明数据从哪里来、手机何时接手。开始前写一张任务卡：
- 任务：用户结束跑步后在手表上查看摘要，并在手机上查看完整记录。
- 设备：圆形手表、手机 App；手表支持触控，手机负责详情和历史。
- 关键结果：手表显示距离、时长和保存状态；手机显示同步进度和失败后的重试入口。
- 边界：手表剩余空间不足、蓝牙断开、权限未开或数据尚未同步时，都要有可理解的反馈。
任务卡把“看起来像一个手表页面”变成可验证的跨设备流程，也为后续评审提供统一目标。
第一步：按设备形态确定信息优先级
圆屏会出现边缘裁切和弧形安全区，方屏更适合列表与卡片，手环通常需要更短的文本和更少的操作。不要把同一套布局直接等比例缩放。
| 设备 | 首屏优先 | 交互取舍 |
|---|---|---|
| 圆形手表 | 当前值、状态和单个主要动作 | 避开边缘放置小字号和次要按钮 |
| 方形手表 | 摘要卡片、列表入口和返回关系 | 可增加一层信息，但保留清晰的焦点 |
| 手环 | 单个指标、提醒和确认 | 减少输入，复杂操作交给手机 |
| 手机 App | 趋势、历史、设置和解释 | 承接详情、编辑和长期任务 |
第二步：先画状态图，再画视觉稿
以运动记录为例，至少画出以下状态：待开始、进行中、暂停、已完成待保存、保存成功、同步中、同步失败。状态之间写明触发条件和返回路径。
- 用户点击开始，手表进入“进行中”，显示计时和暂停操作。
- 用户暂停或离开运动页面，恢复时保留当前数据，避免误结束。
- 点击结束后先显示摘要和“保存”，不要直接假定数据已经同步。
- 保存成功后提示“等待手机同步”；蓝牙断开时提供“稍后同步”和“重试”。
状态图能让设计、产品和研发讨论同一件事：哪些数据已经写入、哪些只是等待传输，而不是只看一张静态截图。
第三步：用墨刀搭建设备和手机的可点击路径
在墨刀原型中可为不同设备建立页面或画板，并用连接关系表达动作。建议按下面的顺序搭建：
- 先完成手表主路径：开始→进行中→结束→保存结果。
- 再补异常分支：暂停恢复、权限拒绝、空间不足、蓝牙断开。
- 创建手机详情页和同步状态页，分别承接查看历史、重试和设置。
- 给关键组件添加批注：数据来源、更新时机、交互触发和需要研发确认的限制。
- 邀请评审者按真实任务点击，不要只问“页面好不好看”。
对于需要快速调整的文字、颜色和组件，可以先在原型中完成可编辑修改；涉及真实蓝牙、传感器、后台同步和功耗的结论，应在工程测试中验证，不能用原型点击代替。
第四步：验证可读性与触控边界
- 在目标尺寸上查看数字、单位和状态，不只在大屏设计稿里检查。
- 把主要动作放在单手容易触达的位置，避免把“结束”与“暂停”做成难以区分的相邻小按钮。
- 长文本改成分层提示：当前状态、下一步、需要等待的原因。
- 强光、运动中和短暂抬腕场景下，优先保证对比度和一眼可读。
- 为无数据、权限未开、同步延迟和重复提交提供反馈，避免用户误以为设备失灵。
第五步：交接给研发的检查表
| 类别 | 交付内容 |
|---|---|
| 页面与组件 | 各设备画板、组件状态、尺寸和文字层级 |
| 交互 | 主路径、异常路径、返回规则和重复操作处理 |
| 数据 | 字段名称、单位、刷新时机、缓存和同步状态 |
| 系统能力 | 蓝牙、权限、传感器、功耗和后台限制待研发确认项 |
| 验收 | 在真实尺寸或模拟器中逐条点击并记录问题、状态和下一步 |
常见问题
智能手表原型要不要先做完整手机 App？
不必。先用一条跨设备任务验证手表和手机的分工，再扩展历史、设置等页面。这样能更早发现同步和状态问题。
原型能验证蓝牙和传感器是否可用吗？
原型可以表达连接状态、等待提示和失败恢复，但不能证明真实蓝牙、传感器、功耗或后台能力。工程需要用设备和接口做专项测试。
圆屏界面为什么看起来总有内容被裁切？
常见原因是直接套用方屏布局，没有预留弧形安全区。应在目标尺寸检查边缘、字号和按钮热区，再决定是否把次要信息移到手机端。
先用一条真实任务验证穿戴体验。进入墨刀智能穿戴界面设计选择设备场景，再用墨刀原型串起状态、评审和交付。
