文森說技術

這幾天有人在問我怎麼驗證使用者經驗的設計（我說我忘了 :DDDD），於是看看過去學生時期的筆記，發現 PACT 這個東西。就翻些資料來看看。最後發現雖然忘記這是什麼，但是工作上的驗證基本上也不脫離這個分析方法。（內化？（笑

PACT 分析

PACT 是 People-Activity-Context-Technology 組合起來的縮寫。這個驗證分析方法可以對雛形做更細節的敘述，提出規格或產出使用者需求文件。

這個過程盡可能地讓各方有影響到的專家參與並給予建議。因為在設計上會影響產品未來的結果，所以可以的話，也讓行銷人員參與。

任務清單

• 在實行驗證之前，在 brainstorm 的時候，可以參考 PACT 各項進入考慮。
• 探索設計本身會造成的影響。
• 在合併 PACT 的驗證結果之後，尋找之間的 trade-offs。
• 思考 PACT 驗證結果對現有設計的影響。

PACT 各自該做的事情

先列出各自會做的驗證大綱，再接著詳列這些會做的事情。

• People - 探索與產品相關人員（或稱使用者）的角色以及技能
• Activity - 這些行為會產出什麼、以及為什麼會有這些產出？能怎麼改進？
• Context - 使用這個產品時的環境為何？
• Technology - 既有產品使用的科技，以及新開發的時候將會使用什麼科技？

People

這個項目主要都是跟人有關的分析

• 角色認知 - 專注程度、知覺、記憶、學習力、認知程度、恐懼、人格特質。
• 角色實體性質 - 年齡差異、行為能力。
• 動機、愉悅及參與感 - 的影響。
• 經驗與預期 - 初心者及專家的差別。
• 文化 - 不同文化的使用習慣及方式都有可能會有差異。
• 語言
• 特殊需求 - 盲人、色盲、行動不方便者。
• 同質與異質的使用者 - 舉例來說，普通的入口網站，就是一群異質（ heterogeneous ）使用者；某公司的內部網站的使用者則偏向同質（ homogenous ）使用者。
• 離散或收斂結果 - 如果有選項可以讓使用者選擇，則提供使用者方式可以輸入他們預期結果。
• 使用的頻率 - 當使用者不常使用時，對於複雜的操作要提供有效的協助。

Activity

• 目標、任務以及動作
• 定期於否 - 定期的任務的話，應該要是很容易去達成；不定期的任務的話則要易學及好記憶。
• 定義 - 定義明確或模糊。
• 持續性 - 使用者需要能夠知道他目前所在的位置。
• 單人或多人協作。
• 多工或單一工序。
• 被動或主動。
• 數量與品質的 trade-off 。
• 資料輸入的需求。
• 每個任務所需要的時間，需要能讓使用者更快的回應
• 錯誤訊息 - 要能夠適當呈現錯誤訊息、能讓系統適當處理錯誤並順利執行。

Context

• 實體環境 - 噪音、冷、濕、壓力之下、操作危險物質中或是正常環境。
• 社交環境 - 或指使用環境，分散式或集中使用、行動中、家中等。
• 組織性環境 - 和產品顧客的關係、其他員工、對現有工作流程的影響。
• Activities 執行時的情形 - 時間、地點、壓力及每項任務需要執行的時間。
• 支援 - 支援 activities 的數量和種類，教學、手冊、 demo、新知識以及新技術。

Technologies

• Input - 輸入資料、取得回應以及安全性。
• Output - 輸出的介質性質，如影片、照片、聲音或是畫面呈現。
• Communication - 藉由什麼介質傳播，人與人、裝置間以及溝通速度。
• 畫面的大小
• 圖形化使用者介面（ GUI ）
• 是否有聲音
• 有網路連線或離線操作
• 維持連線或是呼叫才使用
• 即時系統（ Real-time ）
• Safety Critical Systems - 在系統出問題時是否還是安全的，或可以說 fail-safe 。
• 呈現技術 - Kiosks 、 辦公室系統或是行動裝置、網站等。

結論

這個分析方法可以驗證一個新的產品或技術及做出相對應的變更。更有部分論文驗證及比較新舊技術（如 Augmented Reality ）時便有使用 PACT 來分析新技術對現有技術的影響及差別。

因此在產品初步發展的階段時可以導入這個分析方法，可以提早察覺在 brain storm 或是建立 prototype 時沒有發現的問題或沒有考慮到的面向。