初創方案介紹：把假設、測試與發現分開

一、先把問題假設寫成可被挑戰的句子

用『我們認為哪類人在甚麼情境遇到甚麼問題』開頭，再列出目前支持這個判斷的觀察。訪談意見、自己經驗與公開資料各有位置，不混作同一種證明。

挑一個最重要但最不確定的假設。例如使用者是否願意改變現行做法，比介面顏色更可能影響方案方向。先處理會改變決定的未知。

先寫測試目的、參與者類型、任務與完成條件。小型測試可以幫團隊看見問題，但不能自動代表整個市場；把樣本範圍寫清楚。

測試前記錄你期待看到甚麼，以及出現甚麼情況需要修改方案。避免事後只挑支持自己的反應，把原先目標悄悄換掉。

觀察欄記實際發生的事，例如完成了哪個步驟、在哪裏停下或問了甚麼。解釋欄才寫團隊認為的原因，並保留其他可能解釋。

引用受訪者文字時保存原話與使用同意；若不能公開，改成經核對的匿名摘要。不把團隊想像的理想反應寫成客戶證言。

分清概念圖、可操作原型、限量試用與持續使用中的版本，標明測試日期及當時具備的功能。演示影片展示的流程，亦應與實際可用版本對應。

尚未建成的功能列在計劃欄。若演示依賴人工處理，就清楚說明測試方式，不把背後人工工作包裝成已自動完成的產品能力。

用一段整理『保留甚麼、修改甚麼、暫時不做甚麼』，每項連到觀察。無法支持假設的結果仍有價值，因為它能幫助停止不合適的方向。

最後寫下一個具體測試和檢視日期。讓方案介紹展示學習與決策的連續性，而非把未來功能清單當作目前競爭力。

只有原型，可不可以介紹方案？

可以，清楚標明原型階段、已測試範圍及未建成部分，讓讀者理解目前完成度。

測試沒有支持原假設，是否應刪掉？

保留有關記錄，說明它如何改變決定。公開時按可分享範圍整理，不必把所有測試寫成成功。

本系列提供原創資料整理方法。2026 年度資料保留作歷史參考；2027 正式要求以相應年度公布為準。工作表不代替官方章程、資格判定或專業意見。