candy14432 使用者人物誌法則
任務定義
將研究資料整理為可用於設計決策的角色模型,明確區分主要角色、次要角色、目標、痛點與行為差異。
何時使用
- 完成使用者研究後,需要整合洞察時
- 團隊需要對目標使用者有共同理解時
- 做設計決策時需要參考依據
- 向利害關係人溝通使用者需求時
必要輸入
- 使用者訪談或研究資料
- 問卷、行為數據或客服回饋
- 目標產品與情境範圍
- 團隊目前的設計問題或決策需求
- 需要定義的人物誌數量與用途
預期輸出
- 使用者分群邏輯
- Persona 草案與關鍵欄位
- 目標、痛點與行為模式摘要
- 可溝通的角色描述文件
- 後續設計應用建議
完成條件
- 已清楚說明人物誌的資料來源與分群依據
- 已定義主要角色與次要角色,並說明其差異
- 每個人物誌都包含目標、痛點、行為模式與代表性情境
- 人物誌內容能支撐後續設計、內容或流程決策
- 已避免將未驗證假設誤寫為使用者事實
不適用情境
- 完全沒有研究資料,不應直接產出 persona
- 問題是流程卡點驗證,更適合 usability-testing
- 只需要描述單一任務使用者,不一定需要完整 persona 套件
常見誤用
- 把人物誌寫成想像故事,沒有對應研究證據
- 用人口統計資料取代真正的任務、動機與痛點
- 做出太多角色,讓團隊失去決策焦點
- 角色差異只停留在表面描述,沒有反映流程與資訊需求差異
- 人物誌做完後無法回扣到功能優先序、介面設計或內容策略
觸發條件
- 使用者提到「persona」、「人物誌」、「使用者角色」、「目標族群」、「使用者分群」
- 任務需要把研究資料轉成具體角色模型
- 任務需要讓團隊對設計對象建立一致認知
高複雜度觸發
- 任務涉及 B2B 產品、後台工具、管理平台或跨部門服務流程
- 使用者提到多種角色使用同一系統,但目標、權限或操作頻率差異很大
- 任務需要區分決策者、管理者、執行者、審核者或支援人員的不同需求
- 團隊對「誰是主要使用者」沒有共識,需要先建立角色優先順序
必要澄清
- 這個產品或流程中有哪些核心角色?誰是主要使用者,誰是次要角色?
- 每個角色的主要任務、成功指標與最在意的風險是什麼?
- 角色之間是否有交接、審批、覆核或資料移轉的關係?
- 不同角色使用的頻率、裝置、情境與技術能力是否不同?
- 現有研究資料是否足夠支撐角色區分?哪些角色仍然缺乏證據?
- 這次人物誌要用於什麼決策?例如流程設計、功能優先序、教育訓練或導入策略
可搭配技能
user-interview: 先補齊不同角色的第一手研究資料information-architecture: 根據不同角色的心智模型設計內容與導航prototyping: 為不同角色建立關鍵流程原型usability-testing: 驗證不同角色是否能順利完成任務
執行步驟
- 整理研究資料: 只保留可支撐角色差異的證據。
- 識別模式: 以任務、目標、痛點、頻率、權限分群,不要只看人口統計。
- 定義角色: 選出 3-5 個最能代表決策差異的角色。
- 建立人物誌: 每個角色至少寫清目標、痛點、行為模式、代表性引言。
- 驗證內容: 檢查每個描述是否有研究證據,移除臆測與刻板印象。
執行檢查
精簡範例輸出
# 角色: 高頻操作業務
- 主要任務: 快速更新客戶進度與追蹤商機
- 主要目標: 降低資料輸入時間,避免遺漏下一步
- 主要痛點: 資訊分散、欄位太多、狀態不清楚
- 行為模式: 每天多次使用,偏好桌機,時間壓力高
- 代表引言: 「我只想快速知道現在該跟進誰。」
範例資料庫
本技能提供完整的人物誌範例庫，請參考 examples.yaml：
- 人物誌範本：B2B 專業人士、一般消費者、開發者等不同類型範本
- 實際範例：忙碌的專案經理、精打細算的小資族等完整人物誌
- 屬性清單：人口統計、心理特徵、行為、目標需求、痛點等結構化屬性
使用方式：選擇適合的範本結構，填入研究資料，快速建立專業人物誌。
資料使用規則
- 產出內容前，先閱讀
TEMPLATE.md，確認欄位結構、最小必要欄位、品質標準與驗證方式。 - 接著再閱讀
examples.yaml，從既有範本、案例與屬性分類中選取最適合的內容。 - 若要新增資料，優先沿用
TEMPLATE.md的格式與命名規則，避免建立重複或過度接近的角色類型。 - 最終輸出必須優先對齊
TEMPLATE.md的格式要求，其次再引用examples.yaml的內容細節。