---
title: "在進入資訊架構前釐清需求訪談中的情境"
slug: servicedesign049
url: https://lms.soking.cc/posts/servicedesign049
published_at: 2025-10-02
modified_at: 2025-10-02
author: "Soking"
category: "服務設計"
access: public_access
---

# 在進入資訊架構前釐清需求訪談中的情境

By **Soking** - 產品與服務設計顧問 | 2025-10-02

哈囉，朋友最近我正帶著我們家的新人進入新的專案，並且手把手的帶他走一遍從需求訪談到資訊架構的過程。​這個案子要將客戶已經上線的舊站砍掉重練，因為有了舊站，其實範圍相對明確，比起從無到有要探索一個新站的範圍簡單多了。​隨著進度來到帳號註冊流程的規劃，新人在這個看似簡單的流程，卻被我接二連三的退稿。​我看著新人提出的 sitemap 問：「新站不是有討論過，要把學校這個身分獨立出來，變成像粉絲專頁的概念對嗎？」​新人：「對啊，怎麼了嗎？」​我指著登入的畫面：「為什麼你第一步就允許新用戶用教育雲登入？」​新人：「因為我想說他先登入，系統判斷這個學校有沒有建立過，然後就可以引導過去註冊新學校單位啊？」​我困惑的問：「你的意思是，某一個學校第一位使用教育雲登入的老師用戶，就會預設建立學校單位，並且成為管理員嗎？」​新人：「這樣會有什麼問題嗎？」​我不直接回答，繼續問：「那這邊，學校單位的建立流程中，為什麼學校單位的資料欄位中，要填寫聯絡人、聯絡電話？」​新人困惑的回答：「因為每個學校都要有聯絡窗口啊？」​於是我繼續追問：「所以你的意思是說，聯絡人資料是隸屬於學校單位嗎？」​新人遲疑了一下：「對啊？舊站的版本也是這樣呈現沒錯。」​很好，我就是在這邊等你這個回答。​我：「你還記得需求訪談的時候，客戶有提到學校端經常會面臨負責窗口的變動，可能這個學期是某位老師負責，下學期就換了人嗎？」​新人：「記得，所以？」​我：「那我們提出的解決方案是什麼？」​新人：「所以我們提出把學校單位抽象一層獨立，變成類似粉絲專頁的東西。」​我：「那為什麼你還把聯絡人資料綁在學校單位這個層級？」​新人：「咦！？我想說這樣寫工程師會自己知道去抓管理員資料？」​我：「我都看不出來你有這個意圖了，工程師看你的設計稿會看得出來嗎？你要人家觀落陰啊？」​新人好像模糊的感覺自己有點想當然耳了，我就繼續追殺。​我：「回到一開始登入的時候，用戶可以選擇教育雲，然後就預設要去負責建立學校單位成為管理員這件事情，你認為不是實際負責人的老師，先登入遇到這個流程的機率高不高？」​新人：「算高吧。」​我：「那不是負責窗口的老師，為什麼要被迫經歷這個流程？」​新人：「可是我們不知道誰負責，而且他可以離開這個流程啊？」​我發現新人聽不懂，所以換個角度問。​我：「你註冊一個新網站的時候，很喜歡填寫一堆五四三跟你眼前想做的事情無關的表單嗎？」​新人：「我會不耐煩。」​我：「那你為什麼要規劃一個很容易讓不需要這個流程的用戶不耐煩的流程？」​新人不知道該如何回答。​我引導的問：「現在你覺得學校單位的聯絡人以及電話，最適合填寫的時機是什麼？」​新人：「某個老師被指定成為管理員的時候。」​我：「為什麼呢？」​新人：「因為他現在變成負責的窗口，所以會覺得填寫這些資料理所當然，唉呀！原來是這樣！」​我：「所以你現在還堅持一開始就讓每個老師都被強迫看一遍學校單位建立流程嗎？你覺得這個流程的引導可以放在哪邊？」​新人：「我可以放在他登入之後，系統從教育雲取得用戶的學校隸屬關係，然後在某個 header 或一級功能選單中提醒用戶，這個學校單位還未建立就好。」​我：「現在你的結論比一開始的規劃好多了，整個砍掉重來吧。這些議題你不是都有在需求訪談中聽到過了嗎？」​新人：「聽到是聽到了，但你今天討論我才真的串在一起，之前想像不出來這些事情之間有關係。」​沒關係，被砍掉重來幾次之後，下次就會聽懂需求訪談的內容應該要注意哪些事了。​by Soking