物聯網中的通信 - 即設備如何向網絡發送和接收數據 - 可以以不同的方式處理，通信方式主要由應用層中的協議來控制。了解數據在您服務中的設備周圍的流動方式可以讓您了解其可能的響應以及數據在設備之間的同步速度。

推（push），拉（pull）和輪詢（polling）

作為一名UX（用戶體驗）設計師，您需要注意的關鍵因素包括：

?設備如何將消息傳輸到網絡中：它是定期推送（push）還是滿足某些條件后再推送？還是僅當客戶端設備（如智能手機應用程序）或者服務請求（pull：拉）它時才會傳輸（即）？

?設備如何從網絡中接收消息：消息是否是從服務或者其他設備推送過來的，還是第一個設備根據需要請求它們接收的？

?設備連接頻率：它是不斷地持續連接，還是定期連接的，還是只有當它知道它需要連接時才連接？

?指令或數據可能多快通過？這是一個組合的問題包括以下的問題：

->設備建立連接需要多長時間

->連接可能有多快

->需要發送多少數據

->它可以多直接地被路由（任何信息要通過Internet可能需要花更長的時間）

如圖1的例子所示，說明了您可能會遇到的一些問題：

電池供電加熱控制器使用ZigBee每兩分鐘聯系其網關登記注冊其狀態信息并尋求新的指令。這種方式稱為輪詢（polling）：控制器不知道什么時候會有新的指令，但必須定期地檢查更新。

用戶使用移動應用程序來加熱使溫度從19°C升高到21°C。該應用程序將該指令傳遞給Internet服務。網關設備定期輪詢（polls）Internet服務并接收指令。 （網關具有主電源供電，因此可能會相當頻繁地進行輪詢，也許每隔幾秒鐘就輪詢一次。）加熱控制器（polls）輪詢網關并接收指令。

圖1、加熱系統中的輪詢和推送

如果用戶在加熱控制器面前使用移動應用程序app時，則可能會看到控制器花費長達兩分鐘的時間來響應來自移動設備的命令。

在此期間，手機UI（用戶接口）和控制器顯示器將顯示不同的狀態信息，并且可能會不同步。手機可能會說是21°C，控制器則可能顯示19°C。控制器反映系統當前的真實狀態。在連貫性方面，這是一個連續性問題。

它可以更快地將指令從Internet服務推送到網關和設備中。但這通常不太可能通過家庭路由器來實現。大多數路由器向世界呈現的是單個公共IP地址，并將本地網絡上的設備地址保留為私有（這種共享一個IP地址的技術稱為NAT：網絡地址轉換（network address translation））。因此，服務器難以推送（push）到本地家庭網絡上的設備或者從本地家庭網絡上的設備中拉出（pull）信息。另外，安全防火墻也可能是一個問題。

所以，設備必須通過輪詢來檢查新的指令，這可能需要更長的時間。

如果用戶使用安裝在加熱控制器設備上的控制來升溫，則延遲可能會較短?？刂破髦老到y發生了變化，并通過集線器（hub）將更新信息的消息推送（push）到Internet服務中。它知道它需要連接，所以它不會等待計劃的下一個輪詢。如果用戶的智能手機加熱控制應用程序打開，那么它可能會每30秒向服務請求新的數據。所以如果用戶在同一時間看著他們的智能手機加熱應用程序，他們可能仍然會觀察到不連續性，但可能只是一個短暫的延時。

智能手機和加熱控制器正在輪詢互聯網服務以進行更新，這是一個拉（pull）的例子。當他們知道他們有最新的信息或者命令要分享時，那么它們兩者都能夠推送消息。

智能手機和加熱控制器都不會保持與網絡的持續連接，因為這樣會耗盡電池的電量。但手機可以比控制器更頻繁地檢查更新，因為它的電源受到的限制較少。

雖然這種安排確實會暴露偶爾的不連續性，但是對于加熱系統的應用情況，這些不會是災難性的影響。大多數時候，用戶不會拿著智能手機站在加熱控制器的面前。另外在大多數時候，發出加熱指令和實際開啟指令之間的兩分鐘延遲滯后并不是一個問題：加熱器的工作時間是以小時為單位的而不是秒。

輪詢時間間隔太長可能會使服務感到反應太遲鈍。例如，使用If This Then That（IFTTT）， 當有電子郵件從特定收件人傳遞到您的Gmail帳號上時Philips Hue bulb可以配置為閃爍或者更改顏色。雖然這是一個好主意，但是IFTTT只能每15分鐘輪詢一次Gmail（這可能是由Gmail限制的，以避免輪詢太頻繁而導致其服務器過載）。這意味著在收到電子郵件后15分鐘內，燈泡可能不會響應。這是一個非常不及時響應的通知系統。

如果您希望設備能夠快速響應命令，則要么必須保持打開連接以監聽推送的命令，或者更頻繁地進行輪詢。給消費者推送通知的一個很好的例子是Google通訊錄（Google Contacts）。如果您使用Web來更新Google聯系人（Google Contact），則幾秒鐘內就會將更新推送到您的手機。手機不經常輪詢：它只是收到從Google服務器發來的自發更新通知。

當沒有什么新的東西可以分享時，頻繁的輪詢可能會導致服務器過載（以及會耗盡電池）。維持與許多不同設備之間的許多開放連接也是不切實際的。但是，你無法連接到一個沒有打開連接的設備上來告訴它進行連接。當您需要一個設備快速響應時，您可能至少需要一個打開的連接。例如，如果氣體傳感器檢測到泄漏，則關閉家庭電源的開關將立即關閉。

控制設備發送命令的時間更容易。一個設備可以被配置為在滿足某些條件時向網絡發送數據;例如，加熱時間表發生了改變，或者濕度傳感器檢測地下室中有水。它也可以配置為在某些條件下更頻繁地發送數據。如果一個檢測可能的火災的熱探測器僅每2分鐘發送一次狀態信息，則可能會在接下來的20分鐘時間內每隔一秒傳輸一次狀態信息。如果它不能聯系到其通常的網絡網關時，那么它可能通過網狀網絡上的替代節點來嘗試跳躍通過。使用靜態IP地址（例如IPv6）和適當的應用程序，那么從理論上也可以在緊急情況下嘗試使用相鄰的網絡。

當消息沒有通過時，設備也可能需要有提醒用戶的方法。例如老年人的緊急警報按鈕需要盡可能的可靠，并提供如蜂窩數據這樣的備份連接。但是，該按鈕仍然應該可以告訴用戶不僅是他們的幫助呼叫是否被發送出去，而且也要告訴用戶該呼叫是否已經被另一端的系統所接收。

UX（用戶體驗）的一個關鍵考慮是了解數據在系統周圍傳遞的速度，以及它是否適合在應用的上下文環境中被使用。例如，用于家庭用電的家庭能源監控系統可能會每隔幾分鐘或者更長時間將最近24小時的數據上傳到互聯網服務中。當您請求此信息時，它將從Internet服務中發送過來而不會直接查詢能量監視器。這樣做可能會更快，和/或降低與您的能源公司連接的蜂窩數據的成本。但是，如果您想知道您家的前門是否被鎖緊，那么知道該數據是否是2分鐘前的舊數據是非常重要的 - 因為有人可能在其期間已經打開它了。

物聯網（IOT）的應用層協議

應用層協議位于Internet網絡的最頂層。他們建立計算機進程的通道來進行交流。它們形成設備通過網絡并從網絡中獲取數據的連接模式。您的系統使用的應用程序協議的選擇主要是一個技術設計問題，并不太可能對UX（用戶體驗）產生重大的影響。但是，值得注意的是要留意您聽到的一些可能的選項，并了解您正在處理的系統如何傳遞數據的。

IoT應用程序通常是使用超文本傳輸協議（HTTP）通過Internet來進行通信的。

HTTP是一種可靠的方式來傳遞圍繞著少量設備的不需要立即更新的任何更改信息。但是它不是按照推送（ push）或者流式（streaming ）而設計的，因此通常需要輪詢。圍繞著很多設備來傳遞數據的也不是最流暢的方法，特別是對于電源和計算能力受限制的設備來說更是如此。它需要在需要共享數據的任何設備（點對點網絡，參見圖2）之間建立直接連接，并且消息占用了大量的字節。

其他協議，尤其是MQTT協議，是專為物聯網而設計的。這些優先級更小的數據傳輸以及更有效的方式適合用來在低功耗設備的大型網絡上傳輸數據。MQTT沒有采用直接連接而是使用一種發布訂閱模型，其中的設備將數據推送到一個中央消息代理器中。其他設備可以訂閱他們想要的數據源（“主題（topics）”）（見圖2）。這種方式可以很快：Facebook Messenger就是運行MQTT協議的。它也是管理大量設備之間的互連的一種更靈活的方式：每個設備只需調整到它們所需的主題上。

但HTTP得到廣泛的支持。它可以通過Web API以易于訪問和通用的方式利用傳感器網絡。它也通過使用防火墻來增加安全性，因為它看起來就像普通的網頁瀏覽。

圖2、像MQTT這樣的發布訂閱應用程序協議可以提供一種比點對點協議（如HTTP）更有效的方式來傳遞大型設備網絡中的數據。在這種情況下，每個接收器從發送方1和2獲取數據，但并不都需要來自發送者3和4的數據。在這種發布預訂（Publish-subscribe）的網絡中，只需要較少的連接來正確地分發消息。

互聯網服務

在本節中，我們將介紹Internet服務在IoT系統中的作用，以及API（應用程序編程接口）的設計與UX（用戶體驗）設計之間的關系。

互聯網服務的作用

物聯網系統通常需要依靠某種的遠程集中式互聯網服務來收集，處理和分發數據和指令（少數的連接設備可能沒有遠程集中式Internet服務。例如，許多WiFi打印機都有自己的嵌入式Web服務器，從而可以托管它們自己的互聯網服務。但這在物聯網的應用中就相對少見）；

互聯網服務通常包括一些存儲和處理方式：

?系統數據（例如，傳感器數據或者設備的當前狀態）；

?運行在頂層中的應用（例如，健康監控或者照明控制）；

該服務通過應用程序編程接口（APIs）來使數據和系統命令可用于移動或者Web應用程序中。服務提供商越來越多地將APIs提供給第三方開發人員以使其他服務能夠與系統集成。

例如，從傳感器網絡獲取的數據由Internet服務器進行匯聚和處理，然后因特網服務器發布數據總結。

系統設計人員可以選擇處理發生的位置：在遠程服務中（“云”），網關中或者邊緣設備中。在云中進行更多處理可以更容易地維護對系統的一個集中式視圖。但是當設備丟失連接并且無法訪問云時，系統將無法正常工作。

對于非緊急的數據，例如空氣質量監測，這是可以接受的。如果傳感器暫時離線，他們可以存儲數據，并在重新連接時再將其上傳。發生的最糟糕的事情是一些數據可能是舊的。

但是，對于數據必須盡快完成這樣做是不行的。如果嬰兒監視器沒有及時警告隔壁房間的父母導致孩子已經停止了呼吸，那么這是不能接受的。這就是需要進行本地處理的地方，因此設備可以在沒有互聯網的情況下工作（例如，具有設備上控制功能或者網關的恒溫器可以繼續控制家庭照明）。

互聯網服務可能是專有的（針對您的服務定制），也許使用API來與第三方服務共享數據?；蛘咚赡苁且环N開放式服務（例如，Thingspeak的開放數據平臺）。如果您依賴別人的服務，那么請記住，如果他們出現中斷，提高價格，丟失或者公布您的數據，或者它們破產了...，那么最終您也會如此。

平臺（在這種情況下）是一種可用于構建多個遠程服務應用程序的軟件框架。 Thingspeak，Kaa，Xively，以及Thingworx是開發人員可以用來創建IoT服務的平臺例子。平臺可以使工程師更容易地讓系統運行起來，但是可能也會限制您或者使您的服務缺乏靈活性。依靠第三方平臺需要承擔平臺提供商可能會停業的風險。與開放標準連接的獨立服務可能會提供更多的控制和選擇：如果需要，您可以用一個等效的服務來替換現有的服務。

APIs（應用程序編程接口）

應用程序編程接口（API： application programming interface）是開發人員的接口。API為開發人員提供了一些組件工具來構建系統里的東西。它們可能是您自己的前端網絡或者移動應用apps或與您的系統交互的第三方服務。 API是創建可互操作的設備和服務生態系統的重要組成部分。

API使開發人員可以創建易于鏈接到其它服務的Web服務。因此，您無需為您的雨量預報設備而構建自己的天氣預報服務：您可以輕松地呼叫第三方天氣服務的API。 “小件（small pieces），松散加盟（loosely joined）”的原則鼓勵開發商創造有針對性的服務：做好一件事，同時與其他服務進行良好的互操作。這提供了將不同服務組合在一起來創建完全不同的應用的靈活性。

UX（用戶體驗）人員通常不負責設計API，但API設計可能會對您能夠創建的UX（用戶體驗）產生重大的影響。您在APIs中提供的功能可以決定您可以使用自己的UX設計做什么以及其他（第三方）可以對您的服務做什么。

設計API非常像為內容網站設計信息架構。您需要了解您的用戶需要哪些信息，以及如何分塊和組織，以便使用戶輕松快捷地找到自己想要的內容。

有時設計決策將涉及到權衡：您可能通過使一些任務變得更容易，而卻使別的任務變得更難。

如果您的UX（用戶體驗）設計和您的API（應用程序編程接口）設計相互不適合，其結果可能是導致長時間延遲，響應速度差以及服務器過載。 API設計應與產品定義和UX設計緊密相連。

web API是如何工作的？

API可以描述數據或者函數調用。它們可以用多種語言編寫，但在本章中我們將使用基于HTTP的標準Web API的示例。

Web API調用將操作應用于URL。以下是一個連接的家庭系統的一種可能的API URL架構的示例：http：// api.[服務供應商的名字].com /屬性（property）/網關（gateway）/設備類型（devicetype）/設備（device）/信道（channel）。

·第一部分是服務提供商的公共域名。

·屬性（property）是系統所在的家（例如，克萊爾的房子）。

·網關（gateway）是網關設備的名稱（如果您有多個網關設備的話）。

·設備類型（devicetype）是設備的類型（例如，運動傳感器，接觸傳感器，燈開關）的名稱。

·設備（device）是由用戶分配的特定設備（例如餐廳運動傳感器或者后門接觸傳感器）的名稱。

·信道（channel）是來自該設備的數據饋源。設備可能有多個（例如，所有運動和接觸傳感器也可能感測溫度，因此將有兩個數據饋源：運動和溫度）。

您可以使用API檢索數據，或在某些情況下通過使用HTTP方法發送請求將命令發送給系統。

GET是最常見的，用于檢索數據的方法。使用下面的示例：如果您想從房間中的所有運動傳感器中檢索到狀態信息，那么就可以通過使用GET方法來發出請求：http：// api.[serviceprovidername] .com / claireshouse / gateway1 / motionsensors。

系統會回應以下XML代碼：

<channel type="motion">

<events>

<event type="motion" detected="no" timestamp=""

location=""/>

<event type="motion" detected="no" timestamp=""

location=""/>

... (在房子里的每個運動傳感器的一個條目)...

</events>

</channel>

如果您有這樣做的授權，您也可以使用其他方法修改服務器上的數據。

在這個例子中，如果你想把飯廳的燈光調暗50％，你可以提出一個PUT請求：

/{ claireshouse/gateway1/lightswitches/diningroom

<light>

<state value="on"/>

<dimming percentage="50"

</light>

這些是非常簡單的例子，但應該可以幫助您了解以下部分中描述的設計問題。

APIs的關鍵設計問題

在設計API時要做出的關鍵決定是數據和控制的顆粒度，以及如何將其組織到層次結構中去。

Granularity（顆粒度）：由連接到互聯網的一個設備組成的簡單系統可以具有一個簡單的API。該設備發布已收集的關鍵數據，如前面的例子所示您可以將簡單的命令（控制）傳回給它。這是一種細粒度（或者面向端點的）設計，因為它暴露了設備本身的底層數據。

端點/細粒度的APIs（圖3）允許控制特定設備或檢索特定的數據，這對于小型系統來說是足夠好的。但是，如果您想要同時從許多設備檢索數據，則細粒度的系統意味著需要大量單獨的API調用。這將是緩慢的：在3G連接上每個API調用每次往返可能需要1秒鐘。需要進行20個API調用的網頁或移動應用程序屏幕的加載速度要比只有兩個或者三個API調用的速度要慢得多。

圖3、細粒度和粗粒度APIs的簡單的例子

在具有大量設備的物聯網系統中，各個個體設備通常對用戶來說并不重要。如果您想知道您家客廳的溫度，您會關心您的房間而不是可以在房間監測溫度的設備。系統應該為您計算室溫，并通過單個的API調用就可以使其呈現給您。

這些是面向任務的（針對特定任務）或粗粒度（匯聚數據）API函數的示例。服務匯聚來自多個設備的數據，并在后端應用一些算法處理。您的智能手機應用程序只需要運行一個API調用，來知道房子中哪些燈是開的或者哪些是關的。

面向任務的API使得更容易實現在多個設備上支持復雜功能。您可以將API緊密地綁定到您的UI（用戶接口）上，匯聚通過單個API調用訪問的特定屏幕或小部件所需的所有數據。這將是高度響應的系統，但如果您想要更改您的UI，則需要重新設計。所有使用您的API的第三方都必須提供與您完全相同的屏幕/小部件塊數據。因此面向任務的APIs存在靈活性不夠的風險：UX設計人員和開發人員必須按照您設計API的方式來使用它們。

如果API的粗粒度過大，也可能會阻止您訪問單個設備或者數據。你可能有時候需要關掉所有的燈，但是你也有時候只想要關掉走廊上的燈。

來自Evrythng的Niall Murphy引用了現有使用單一API連接汽車的例子。這是為維修/制造商診斷而設計的，但對其它的用途來說是不切實際的：

“你可以打開汽車上的所有信息流，或者關閉它。當你回家的時候，家里一直不需要車位置的信息流來打開車庫門。您需要將大小信息縮小到與特定應用程序匹配的所需信息”。

有可能使用混合設計：一些聚合數據和面向任務的APIs以及一些端點（設備）APIs。這將使您能夠顯示家庭中所有電器的能源使用情況，也可以只跟蹤烘干機的使用情況。

結構體。除了選擇正確的數據和控制的顆粒度之外，還需要對API中的單位（設備和數據點）進行分組和組織，以使其他人能夠使用。當您擁有更多的設備和數據點后這一點會變得越來越重要。

數據/設備在您的API中的組織方式可以使您更容易或者更難以從您想要的設備組合中檢索數據或者應用控制。嘗試著從不適合的API設計中創建UX設計將會導致一個遲緩的，無響應的UX。

家庭中的設備可以通過其感測能力（例如，溫度或運動），位置（例如在廚房里或者在樓上），它們支持的應用（例如，安全性或者加熱）或者其它更多的方式來組織。有些設備可以做超過一件事情的 - 例如，一些設備既可以感測溫度又可以監測運動，以及和/或可能被多個應用程序所使用。如果您繪制了這些設備之間的相互關系的映射，那么它將看起來像一個網絡結構（見圖4）。

圖4、設備之間的相互關系形成網絡結構

用戶可能希望訪問不同的被組織起來的分組。例如，您可能想要看到房子周圍的溫度讀數?；蛘吣赡芟胍榭此邪踩O備?；蛘吣赡芟胍獧z查客廳中每個設備的當前狀態。

對于復雜的多設備系統，網絡類型的UX通常看起來像是一種直觀的方式來供用戶探索可用的內容。從客廳運動傳感器，您可以瀏覽其它的安全設備，其他運動傳感器以及其它測量溫度的設備。

麻煩的是，在UX中提供這種靈活性不一定會很容易地使用APIs。特別是查找相關數據往往是一個挑戰。 URL是分級的，因此它們并不反映數據可以相互關聯的所有方式。

還是以我們前面看過的餐廳溫度為例。在與餐廳溫度相同的屏幕上，您還想顯示家中其他溫度傳感器的讀數。對用戶來說，這似乎是一件很明顯的事情：從一個溫度讀數，我可以查看其它的讀數。但是在這個架構中，它們都位于樹結構的底部，并且彼此之間的關系沒有被映射。所以您必須單獨調用每個其它溫度傳感器的數據。這將是緩慢而低效的，就像您不得不從上到下瀏覽網站的樹結構以比較大量單獨的網頁頁面里的內容。

如果您正在設計一個只有少量設備的小型系統，那么潛在的低效率就會很小。但是，您必須應對的數據點和設備越多，那么讓您的API結構很好地適應UX就越重要。

作為一名UX設計師，重要的是確保您的工作與設計APIs的開發人員要緊密合作。

第三方API。您可以依賴于第三方例如Xively或Twitter的API。如果是這樣，您就受到他們的條款約束，您需要檢查您可以如何使用它們。供應商通常對您可以進行的調用頻率施加限制，或每天的API調用數量，以避免使他們的服務器過來。他們也可能收取API調用費用，如天氣預報服務forecast.io所做的那樣，另外與第三方平臺提供商一樣，他們也可能會停業。

總結

網絡對物聯網（IoT）系統的UX（用戶體驗）產生了根本的影響。許多連接的設備僅間歇地連接到網絡以輪詢新的指令。這可能會造成系統的部分相互不同步而產生較小的延遲。網絡延遲和可靠性問題可能意味著連接的設備的行為不與如我們期望的現實世界的對象所做的那樣。

系統架構決定設備如何圍繞系統傳遞數據，處理發生的事情，以及系統的某些部分離線時將會或者將會不起作用。設備可以直接連接到Internet或者通過本地網絡連接到網關。許多設備只能支持低功率網絡，如藍牙和ZigBee。網關使這些設備間接連接到Internet中。未來，通過為低功率網絡提供I功能P將使更多的設備能夠直接連接到互聯網中。這種互聯網標準的使用將使不同的系統能夠更容易的合作。

應用協議塑造了設備通過網絡并從網絡中獲取數據的連接模式。數據可能被推送（push）或者被拉到（pull）設備上;該設備可以不間斷連接或者以規則間隔來輪詢指令。 HTTP是常用的;而專門的IoT協議（如MQTT）針對具有有限帶寬的低功率設備進行了優化。

所有IoT系統都依賴某種遠程集中式Internet服務來收集，處理和分發數據和指令。該服務通過應用程序編程接口（APIs）使數據和系統命令可用于移動或者Web應用程序中。

應用程序編程接口（APIs）是開發人員的界面。它為他們提供了使用系統數據來制作最終用戶應用程序和其他系統的基本模塊。如果API設計不適合UX的要求，那么可能會導致緩慢的，無響應的體驗或者會過度限制您所提供的功能。

應用舉例

Proteus數字健康（Proteus Digital Health）：連接的藥丸

藥物是20世紀的一個驚人的創新，但它們只有在正確使用時才能奏效。來自世界衛生組織的專家估計，一半的藥物沒有按規定服用，意思是劑量不足，劑量不正確或藥物不正確.由于這些依從性的挑戰，大多數人不能從藥物中獲得最大的價值。 Proteus Digital Health正在通過在口服藥物中添加傳感器并將其連接到物聯網中來解決這個問題。

這些連接的藥物正在為患者，護理人員和醫護人員提供新的數據流。 Proteus的系統在人們服用藥物時，不可思議地捕捉到數據，并將數據與其他生理和行為數據（如心率，活動和睡眠模式）進行比較。這些信息匯聚在一起可以實現新的自我管理方法，并產生新的見解以便臨床決策。

技術

該系統的核心創新是在藥物制造的過程中可以藥丸中放入的一個小型，低成本的1mm×1mm可攝取傳感器（見圖5）。這種一次性傳感器被設計為從根本上安全的，由通?？梢栽谌祟愶嬍持邪l現的元素制成的。用戶也不可見，完全封閉在藥丸內，所以“連接”藥丸看上去與標準藥物沒有任何區別。

在設計物理傳感器時，我們認為保持人們對熟悉使用的藥物的習慣方式非常重要，因此拒絕使用傳感器對用戶可見的設計方法。

圖5、 Proteus的可攝入傳感器

可攝入傳感器通過專有的傳輸技術與由Proteus開發包含在佩戴在身體上并每周更換的小貼片內的小型穿戴式傳感器進行通信。佩戴設備可以收集其他數據，例如活動和心率，并將所有的內容傳送到手機中（參見圖6）。然后，手機將數據發送到云端，可以通過安全的門戶網站和應用程序對這些數據進行分析和訪問。這些應用可以針對不同的用例進行定制，并可以針對不同的用戶進行優化。人們對信息有不同的用途：患者管理日常護理，個人護理人員獲得對親人的保證，護士可以立即關注需要分診的病人，醫生參考它們來做臨床決策，醫護人員通過它們來了解其人群趨勢等。

設計一項使該技術成功推出的服務也很重要。最初這種系統有兩個服務設計目標：（1）降低使用不熟悉產品的障礙，（2）加快學習可以如何改進產品。為了達到這些目標，Proteus投資雇用了全職的“教練”，他們負責訪問家中早期的客戶，幫助他們使用系統，并報告他們所面臨的挑戰。這項投資至關重要，因為這使Proteus能夠快速識別和修復產品痛點。隨著產品變得更容易使用，客戶對新技術的信心越來越高，Proteus預計將其轉變為更具成本效益和更少資源密集型服務模式。

圖6、 Proteus系統

Proteus早期的設計任務之一是找出誰需要訪問什么數據以及如何訪問。由Proteus生成的數據可以用于各種各樣原因下的上下文環境中?？s小并集中在幾個用例上來開始是關鍵。

Proteus的業務團隊確定了一套潛在的市場。然后，為了定義產品，Proteus的設計研究團隊訪問了家庭或診所市場上的潛在客戶，并仔細觀察了最嚴峻的挑戰，傾聽了Proteus可以直接回答的具體問題。通過這些學習，Proteus的交互設計師以靜態截圖的形式創建了潛在的信息可視化，然后將其帶回到現場進行反饋（見圖7）。雖然Proteus早期的原型展示了大量的數據 - 展示了廣泛的系統功能 - Proteus收集的反饋意見促使他們更直接地實施信息可視化，更直接地關注所提問題，留下大量的原始數據。我們發現，提供太多的數據產生的噪音對幫助人們最大限度地利用系統的利益起到了適得其反的作用，特別是在用新技術建立“應用文化”的早期階段。

圖7、用戶測試可視化

早期用例1：護理

該技術非常適合幫助護理人員遠離脆弱的家庭成員。Proteus的員工和家人見面，聽了他們的故事。從護理者那里聽到的主要訴求是需要知道媽媽是否早上服用藥物，是否會在下午2點做她的三明治。媽媽的主要需求是要保持尊嚴。Proteus對這種用例的信息可視化涉及可以利用藥物治療和活動數據的一個簡單的功能區，允許家庭成員來看到親人全天的高級概述模式（參見圖CS1-4）?？梢暬梢员苊庵T如心率之類的臨床數據，這些數據并沒有為家庭成員提供有意義的洞察力，并且有可能在這種個人用例中侵犯媽媽的隱私。

圖8、顯示功能區的平板電腦應用程序

早期用例2：通知高血壓治療

第二個用例涉及幫助醫生確定為什么高血壓患者會出現不受控制的癥狀。醫生對于不服用藥物或由于處方藥物不當而導致病人不受控制的了解甚微。使用Proteus系統兩周后，醫師可以訪問回答了兩個關鍵問題的簡明報告：病人是否服用藥物，現在是否處于控制狀態？報告中沒有列出活動數據，因為它們在回答醫生的關鍵問題時沒有用處。大多數患者由于霍桑效應（Hawthorne effect）而在觀察期間按照規定服用藥物 - 意識在被觀察會在短時間內改變人的行為 - 因此臨床醫生現在已經驗證了遵守情況，并指出藥物是否正在起作用。這種組合提供可操作的洞察力，幫助臨床醫生作出決定是堅持治療還是要升級到下一療程。