熊屋 | 技術小記

iOS, Web Development Notes

HCI - PACT 分析

| Comments

這幾天有人在問我怎麼驗證使用者經驗的設計(我說我忘了 :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 時沒有發現的問題或沒有考慮到的面向。

Comments