PCA 架構之旅 02 — 定義 User Personas
PCA
讀完 case study 之後，很多人會急著畫架構圖。先停一下——你連系統要給誰用都還沒想清楚。
User Persona（使用者輪廓）是把抽象的「使用者」變成具體的人物，讓後面所有的技術決策都有對象可以對照。沒有 persona，你的架構會是「通用」的，而「通用」常常等於「哪邊都不夠好」。
這是 PCA 架構之旅 的第二步。上一篇是 01 · 讀懂案例情境。
為什麼這一步重要
在 PCA case study 題目中怎麼出現
Google 的 case study 會描述不同角色的行為，例如「消費者每週登入一次」「供應商需要批次上傳 CSV」「資料科學家要跑月報」。考試裡很多選型題（例如選 Cloud Run 還是 GKE、選 Pub/Sub 還是 Cloud Tasks）都要你先判斷「這是哪種使用者的哪種場景」。
考生常見錯誤
- 把 persona 寫成功能需求列表：persona 應該是「人」，不是「系統要做什麼」。
- persona 太多或太少：寫 15 個 persona 的設計會失焦，只寫 1 個又漏掉關鍵角色（例如忘記管理員、維運、外部整合方）。
- 忽略內部使用者：PCA 題目常考管理後台、資料分析師、客服——這些不是外部客戶，但對架構有很大影響。
核心概念
一個合格的 persona 應該包含：
| 欄位 | 說明 |
|---|---|
| 姓名與角色 | 給人感，例如「Lily，28 歲，行動裝置重度使用者」 |
| 目標（Goals） | 這個人用系統想達成什麼 |
| 使用頻率與場景 | 每天？每月？通勤時還是辦公時？ |
| 使用裝置與網路環境 | 手機 4G？辦公室有線？ |
| 非功能需求敏感度 | 對延遲、準確度、可用性的忍受度 |
| 資料敏感度 | 他們接觸到什麼層級的資料（PII、PCI、PHI） |
PII（Personally Identifiable Information）是個資、PCI（Payment Card Industry）是支付卡資訊、PHI（Protected Health Information）是醫療資料，分類會直接影響儲存與加密的選擇。
思考框架
把每個 persona 放進這 5 個問題：
- 這個角色最在意什麼？ 消費者在意速度、管理員在意正確性、分析師在意資料新鮮度。
- 他在尖峰時段的行為是什麼？ 你的 scaling 策略要服務誰的尖峰。
- 他失敗時會怎麼樣？ 消費者看不到商品會跳走，但會計結帳失敗會報警、會影響合規。
- 這個角色對成本的影響？ 免費會員的大量讀取 vs 企業客戶的高頻 API 呼叫，計算資源模型完全不同。
- 有沒有「非人類 persona」？ 批次排程、外部系統、合作夥伴 API——這些也算 persona。
走一遍範例 — 登雲書店
登雲書店的 4 個核心 persona：
Persona 1 — 一般消費者「阿元」
- 32 歲，上班族，通勤時用手機瀏覽書目，週末用筆電下單。
- 目標：快速找到想看的書，結帳流程不要卡關。
- 使用頻率：每月 2–4 次。
- 裝置/網路：iPhone + 捷運 5G，偶爾訊號弱。
- 非功能敏感度：首頁超過 2 秒直接離開；結帳失敗會客訴。
- 資料敏感度：會輸入信用卡與地址（PCI、PII）。
Persona 2 — 電子書訂閱者「小葵」
- 25 歲，喜歡閱讀冷門類型，每天通勤閱讀 30 分鐘。
- 目標：閱讀進度即時同步，換裝置接著看也不卡。
- 使用頻率：每日。
- 裝置/網路：Android 平板 + 家裡 Wi-Fi、捷運 4G。
- 非功能敏感度：書籍下載要秒開；進度不能遺失。
- 資料敏感度：閱讀紀錄（個人偏好，屬於 PII）。
Persona 3 — 書商合作夥伴「天下出版 IT 窗口」
- 外部系統角色，每日凌晨 3 點批次上傳 CSV 更新庫存與價格。
- 目標：確保每日批次在 30 分鐘內完成，失敗時能收到 email。
- 使用頻率：每日 1 次大批量。
- 非功能敏感度：對延遲不敏感，但對準確性與可追溯性極敏感。
- 資料敏感度：庫存與成本（商業機密）。
Persona 4 — 內部營運分析師「Marcus」
- 34 歲，每週跑 10 份報表給行銷主管。
- 目標：能用 SQL 直接查詢昨日資料，不要寫程式拉 API。
- 使用頻率：工作日 9am–6pm。
- 非功能敏感度：資料新鮮度 D+1 可接受；查詢慢一點沒關係。
- 資料敏感度：去識別化後的會員行為資料。
這 4 個 persona 直接決定了後續選型：阿元與小葵需要全球前緣快取、天下出版需要非同步批次管線、Marcus 則指向 BigQuery 類的分析型儲存。
常見陷阱
- 把 persona 寫得像廣告文案：「熱愛科技、樂於嘗鮮」——這種句子對設計沒幫助，要寫行為與限制。
- 漏掉非人類使用者：外部 webhook、排程、第三方 SaaS 整合都會影響架構，別只寫「消費者」。
- 所有 persona 都給最高規格：Marcus 的報表不需要 99.99% 可用性，硬要給會浪費預算，考試也會扣分。
延伸閱讀
- Design Thinking for Architects — GCP Docs — 官方提到的「以使用者為中心」設計思路。
- Nielsen Norman Group — Persona Definition — 業界最常被引用的 persona 方法論。
- Google SRE Workbook — Ch. 2 Implementing SLOs — 講如何把使用者期望轉成 SLO。
下一步：有了 persona，就可以寫使用者故事（User Stories），把「誰」與「做什麼」連起來。
🎯 換你練習
理論讀完，換自己來。到 架構師設計工作坊 · 步驟 2 填入你的 case study，邊寫邊內化。
pca-architect-journey — 2/13 完成
查看系列全覽 →