設計思考怎麼練：從訪談到可測試的小原型

社區想改善雨天借傘服務，有人提議做 App，有人想增加傘架，也有人認為應該改用押金。這些都是可能的方案，但如果還不知道居民為什麼不借、借了為什麼沒還，直接投票選功能可能只是在挑大家最熟悉的答案。

以下以原創社區借傘練習，示範從理解情境到測試想法的方法。概念參考 2026 年 9 月 14 日查閱的 Stanford d.school、Design Council、IDEO.org 與 GOV.UK 資料。所有居民反應均作為待確認情境，沒有冒充真實訪談、實施成果或來源網站的案例。

把設計思考當成往返探索的方式

Stanford d.school 的入門工具以同理、定義、發想、原型與測試等模式組織方法，並說明可以從適合的位置開始。Design Council 的雙鑽石則強調先探索並界定問題，再發展與檢驗方案。這些框架幫助團隊看見工作重點，不必被當成只走一次的固定關卡。

社區借傘練習的起點可以是一份待了解事項清單：誰會需要借傘、目前在哪裡借、歸還有哪些限制、管理人員花多少心力處理。這時先不要把提升 App 使用率當成目標，因為 App 是否需要存在，正是還沒回答的問題。

如果測試後發現問題出在歸還地點，而不是借用操作，就可以回頭調整問題定義。已經畫好畫面不代表必須繼續開發。練習的價值是讓每一步產生新的理解，並用它決定接下來應該做什麼，而非湊齊一組漂亮的交付文件。

用真實經歷提問，避免先把答案塞進問題

先列出需要理解的情境，再準備訪談提綱。比起問你是不是覺得借傘系統很麻煩，可以請參與者描述最近一次出門遇雨時怎麼處理，再追問當時看見什麼資訊、如何決定及最後怎麼做。開放且中性的問題比較有機會聽到原先沒想到的因素。

對象應包含和題目相關的不同角色，例如可能借傘的住戶、使用過借傘服務的人，以及負責整理傘架的人。不需要在入門練習中追求一個號稱適用所有研究的固定人數；先說明選擇哪些情境、漏掉哪些人，以及這些限制可能如何影響理解。

研究開始前，說明目的、過程、是否錄音、資料用途與退出方式，取得相應同意。記錄時區分參與者實際說的內容、你觀察到的行為及自己的解讀。若只是和同學排演提問，就標記為練習訪談，不把同學扮演的住戶回答當成真正需求。

把資料整理成能採取行動的問題

訪談後先整理具體事件，再比較它們是否指向相近的困難。借傘後不知道能否跨棟歸還、出門時找不到傘架，以及傘架缺少可用雨傘，可能需要不同處理。不要只因都和借傘有關，就把它們合併成使用者體驗不好。

原創練習可暫寫成：如何讓跨棟活動的住戶，在借傘前就知道可歸還的位置？這個問法保留紙本標示、櫃台說明或數位提示等可能性，也比如何做出最好用的借傘 App 更容易界定範圍。若沒有研究支持，仍要在問題旁註明它是假設。

IDEO.org 的設計挑戰方法提醒，問題範圍應考量對象、情境、限制及想達成的影響，並容許不同方案。你也可以為練習加上限制，例如不能新增值班人力、資訊需方便更新；這些條件必須有來源，不能為了偏好某個方案而臨時編造。

先提出不同做法，再用條件比較

針對歸還資訊，可以先想傘柄標籤、傘架地圖、借用時的口頭提醒或簡單網頁。發想時先把做法說清楚，包括誰會看見、在什麼時候看到，以及要如何維護。若幾個點子只是在同一個 App 裡換顏色，還沒有真正探索不同解法。

整理點子後，用需求適合度、執行負擔與重要假設來比較。傘柄標籤可能隨傘移動，但需要處理磨損；網頁容易更新，卻要確認住戶是否會開啟連結。這些是原創推演，不是測試結論，應列出需要驗證的地方，而不是直接給每個方案一個精準分數。

選方案時保留理由與被捨棄的條件。若社區人力不足，可能先測標籤和固定告示是否能傳達規則，再考慮數位化。投票可以協助討論，但最高票只代表當下參與者的選擇，不能代替使用者理解，也不證明方案已經有效。

只做足以檢驗關鍵假設的小原型

原型不一定是能上線的網站。若想知道住戶看不看得懂歸還位置，可以先做紙本標籤和簡化地圖；如果要檢查借用到提醒的順序，可以用角色扮演或可點擊畫面。先寫出要學到什麼，再決定投入多少製作時間。

設計一個具體任務，例如從甲棟出發，活動結束後在乙棟附近，請參與者說明會去哪裡歸還。觀察他如何找資訊，再詢問判斷理由。過程中不要急著指向答案；如果必須解釋才能繼續，就記下介入的位置，避免把受到提示的完成當成自然成功。

在原型上標示它是練習，使用虛構棟別與測試資料，並讓參與者知道不會真的借出雨傘或更動規則。一次先處理重要的不確定性，測試後整理哪些假設獲得支持、哪些被挑戰，以及下一版要改哪一件事。

1. 界定生活情境，列出待了解角色、問題與現有資料。
2. 準備中性訪談提綱，取得同意後記錄事件並區分解讀。
3. 寫出有範圍的問題，提出不同方案並說明比較條件。
4. 製作能檢驗關鍵假設的小原型，依回饋修正問題或做法。

讓回饋形成下一個決定，而非只有心得

測試後可以用三欄整理：發生的事、可能原因、下一步。假設參與者把歸還範圍誤認為所有棟別，記錄應保留他看見的版本與說明，再考慮是字句、地圖還是服務規則需要調整。原因尚未確認時，就不要用肯定語氣寫成研究洞察。

少量質性練習可以幫助發現問題，卻無法直接推估所有住戶的比例。若要決定正式投資或制度變更，還需要符合決策需求的資料、管理端確認及後續驗證。練習成功的標準可以是找出值得修改的地方，不必宣稱已經提升借傘率。

收尾時記錄決定、負責人、下一次檢查方式及資料保存安排，保留版本讓之後的修改有跡可循。也可以選擇停止某個方案：如果它增加管理負擔，或需要取得目前沒有的資源，就把原因寫清楚。設計思考應協助團隊做出更有依據的決定。

分清 UI、UX 與研究的工作範圍

整理使用者旅程與接觸點

將練習過程寫成可信案例

• 教學
• 軟體與 App
• 行銷與 SEO
• 內容與品牌