百度MUX智能硬件團隊從去年年初開始接手百度智能手表OS的設計工作，認為相對于智能手機的“碎片化”場景，智能手表在信息和任務維度更加輕量，呈現“微?；钡狞c狀用。本文將展示百度智能手表的OS創新設計。

背景與挑戰

2015年Google、Apple、阿里、華為均推出了智能手表或其操作系統，同時來自研究公司Strategy Analytics的最新數據顯示，Apple Watch 2015年的全球出貨量達到1500萬支，可以說2015年是智能手表的元年。

由于早期Android Wear?的部分服務無法在國內使用，各大互聯網公司設計的智能手表操作系統更是風起云涌，如出門問問、YunOS、TencentOS等等。但是由于業內對智能手表的形態尚處于探索階段，多數產品對于手表平臺所要承載的任務和信息并沒有進行清晰的定義。

百度MUX智能硬件團隊從去年年初開始接手百度智能手表OS的設計工作，認為相對于智能手機的“碎片化”場景，智能手表在信息和任務維度更加輕量，呈現“微?；钡狞c狀用戶體驗。需要重新設計承載他們的容器。本文希望嚴肅地說，智能手表的“微?；痹O計是一種怎樣的體驗？

為“微?；睍r間而生——?智能手表的屬性定義

定義新操作系統的第一步是定義設備屬性，我們分別從智能手表適合執行的任務和適合顯示的信息兩個維度進行定義。

智能手表有著極佳的便攜性和極低的輸入效率（輸入效率由精準度和速率兩方面決定），因此它只適合執行輕量的任務，比如收到一個推送后簡單執行附帶的操作，P圖這類需要長時間連續操作的任務顯然不適合在手表上進行。在信息維度，經測試智能手表一次使用舒適時長為15秒左右（從抬起手腕到手臂有疲勞感，看文章的你請可以自行測試），屏幕展現尺寸極小所以智能手表必須在繁雜信息中做出抉擇，把重點放在高頻的短信息上。

綜上分析我們將目前技術所能實現的智能手表屬性定義為“輕任務，短信息”的承載設備。如果說手機讓我們利用生活中的碎片化時間執任務和查看信息，那么智能手表就是利用我們的“微?；睍r間執行更輕的任務和查看更短的信息。

分析：細分手表承載的信息和任務

智能手表展現尺寸十分有限，因此有必要將短信息和任務按使用頻率細分，以便設計不同的“容器”承載它們。

將長線任務集成為輕輕一點

適合放在手表上執行的任務應該是能在很短時間內完成的，這意味手表的使用場景被限制！我們怎樣解決這一問題？我們發現將一些在手機上總是被重復的長線任務進行自動化處理后放在手表上能有效加快效率和擴展使用場景。比如打車這個任務我們用手機時的操作是“拿出手機 – 解鎖 – 打開App – 輸入地址 – 發出訂單”，在設計手表時我們把這個流程內最常用的一些任務（比如從家到公司）提取出來，利用智能手表用戶可以一鍵發出從家到公司的訂單，而不是單純的把手機的操作照搬一遍。

交互模型

承載任務和信息的“容器”

如前文所述我們將手表定義為“輕任務，短信息”的承載設備，由于手表屏幕展現尺寸的限制我們不得不將信息和任務分級以便用不同容器承載，那么我們設計什么樣的容器來承載這些短信息和輕任務呢？

表盤 – 智能手表首先應該是手表，因此表盤是用戶最常使用的頁面，除了顯示時間之外，我們用它承載最高頻的任務和信息。

快捷卡片 – 表盤的空間畢竟有限，而一些中任務和信息常常需要更大的空間，因此我們設計了快捷卡片，類似于安卓系統的Widght。

Laucher -是App集合，即長尾的信息和任務

不同于手機的App Laucher，手表的Lancher不是被最常使用的模塊，但是卻要承載大量的Icon，且由于手表屏幕尺寸的限制，給如何設計出足夠高效啟動器帶來很大的挑戰（后文將會講述設計和驗證的方法）。

Notification – 智能手表作為用戶抬手既得的屏幕，可以主動推動一些任務和信息，可以在不打斷當前任務的情況下讓用戶利用微?；瘯r間快速處理，而Notification適合承載這些被動任務和即時信息。

從“容器”到立體的交互框架

如果容器是承載著信息和任務一個個的房間，那下一步要做的就是將這些房間建立起聯系，以此建立Duwaer系統的骨骼-交互架構。

在Duwear的交互框架內將操作分為兩種：橫向操作和縱向操作，確?？臻g的秩序性，易于理解和記憶。配合新的輸入方式，借此創造適合手表單手操作的全新交互模型（輸入方式部分在下文詳述）

（橫向操作與縱向操作構成立體模型）

新的交互架構配合新的輸入方式

怎樣讓手表在執行輕任務和查看短信息時效率進一步提高？僅僅在交互架構層面做改進遠遠不夠，我們在交互架構更新的基礎上加入了新的輸入方式 – 轉動手腕和甩動手腕。經過用戶體驗測試，新輸入方式的加入使高頻信息的查看和雙手被占用的場景效率明顯提高。

加入新的輸入維度

實現單手查看信息

對新交互模型進行用戶測試

為了對新的交互模型進行驗證、迭代、調整。我們利用Form制作高保真原型進行用戶測試

利用Form 可以制作調用陀螺儀的高保真原型

我們通過設置任務讓用戶打分的方式來量化交互模型體驗

測試后我們發現，加入新的動作輸入后，明顯加快高頻信息的查看效率，以及在非佩戴手被限制為用戶提供極大的便利。

測試后也發現了一些問題 – 轉動手腕和擺動手腕只適合做執行任務的步長較短的操作，比在用戶想查看第3個快捷卡片后的信息時這種操作方式并不具備效率優勢。因此我們對交互模型進行了微調，加入了快速切換快捷視圖和消息的方式，用以補足新的交互模型短板。

通知

通知——現在就需要和以后再看

Duwear的通知處理里將通知區分為即時通知-即現在就要顯示的，在這種場景下用戶的需求是“讓我高效的閱讀信息”，因此不同于Android Wear半屏顯示，我們將信息全屏化。另一種場景是錯過或歷史的信息，這種場景下用戶的需求是幫我快速找到信息，我們將消息橫向List化加快查找效率。

即時消息全屏顯示提高閱讀效率

歷史消息關注查找效率

化繁為簡——將信息卡片化

短信已經成為日常收納信息的工具，將繁雜的信息卡片花，并且你可以將卡片添加到快捷卡片，當你想用時只需要抬起手腕 .

將特殊短信提取關鍵信息并做卡片化處理

當你收到影票兌換碼 你可以將卡片添加為快捷卡片 到影院后快速查看

laucher

小屏幕內的App Laucher怎樣設計？

我們對App Laucher的定義是承載長尾功能和信息的入口，即承載Watch App 的容器，不同于手機,手表App Laucher不會被經常使用，但它會承載大量的App,所以在設計時我們確定幾個體驗評估的維度：

1. 每屏展示App Icon的個數
2. 記憶與理解難度
3. 操作的準確性

App Icon的個數: 9 ?? ?操作的準確性: ?較高? ????記憶與理解難度：容易

App Icon的個數：6? ? ???操作的準確性：高 ???? ?記憶與理解難度：容易

App Icon的個數：3? ? ??操作的準確性：很高 ? ? ?記憶與理解難度：容易

App Laucher作為長尾功能和信息的入口，會承載大量的App,他的查找效率必須高，這意味這沒屏承載的App Icon個數要足夠多-我們首先排除了第三個。接下來我們要確定的是，方案1和方案2綜合來看那個更好？我們進行了新一輪的用戶測試。

用戶測試

通過與工程師合作我們實現了兩種方案的Dome, 并且可以輸出點擊的行為數據。測試環節我們關注如下三組數據，以此對比兩方案優略：

• 連續點擊12個Icon的時間（點擊精準度）
• 連續點擊3個最常用Icon的時間（常用App 點擊精準度）
• 查找特定圖標并點擊的時間 （查找效率）

我們將兩組方案的輸出數據并進行對比，對比測試我們發現，方案1并沒有由于沒屏顯示圖標數量的增多而明顯降低精準度，方案1（綠色線）的數據優于方案2（紅色線）。最終我們確定的方案1為最佳方案。

快捷卡片

如前文所述，表盤承載最高頻的信息和任務，Laucher承載低頻的信息和任務。那么用什么承載中頻的信息和人任務呢？為了解決這一問題，我們設計了“快捷卡片”，快捷卡片像安卓的桌面Weight一樣可以承載信息和操作，用戶也可以對快捷卡片進行“增刪改”等操作。

用戶可以通過在定位符上滑動快速切換卡片

總結：關于操作系統的設計

設計一個操作系統與設計一款App是完全不同的，當我們設計個新設備的操作系統時我們率先考慮的是——這種新的設備用來顯示什么信息和執行哪類任務，我們借由“輸入效率”“舒適時長”“便攜性”“展現尺寸”來定義智能手表的設備屬性，智能手表并不會像手機一樣承載所有的任務，而是像Pad從PC中拆分出打游戲和看視頻一樣，Watch要做的是從手機中拆分出部分任務，并使其效率更高。

其次當我們清晰的定義了設計的屬性，我們必須對這些信息和任務進行分析，是不同使用頻率的信息和任務存在于不同的層級，是高頻的信息和任務抬手即得。

設計操作系統很像建筑一所房子（而App是房子里的擺件），我們必須清晰的設計房間的結構，劃分功能區域，由一個房間到另一個房間的路線。這也是操作系統設計中接下來要做的—存儲信息和任務的容器以及他們之間跳轉的路徑，即系統的交互架構。

當我們設計新的設備，在設計的新的交互架構以后我們應該考慮是否需要加入新的輸入方式以進一步提高效率。

總結以上系統設計的步驟為：

1. 從信息和任務維度定義設備屬性
2. 分析信息和任務的層級
3. 設計系統的交互架構：承載信息和任務的容器，以及這些容器間跳轉的路徑
4. 檢視是否需要加入新的輸入方式（必須與交互架構協調）
5. 用高保真Dome檢視設計，并進行持續改進。
6. 設計統一的控件/統一的通知機制

本文系人人都是產品經理合作媒體@百度MUX 獨家授權發布，未經本站許可，不得轉載。