磨人在專案進行中看到約定範圍之外的機會時，先主動提案，做小規模驗證，用畫面與結果和客戶討論，再由客戶決定是否納入正式範圍。這個流程與範圍管理並行。提案階段的產出是路徑、畫面與測試結果，不取代既定的規格與設計；納入與否由客戶決定，納入之後內容才寫進計畫。
以下做法來自磨人配合教育部專案的過程，包含戶外教育資源平臺的維運，以及2026 全臺戶外教育季的製作。
研究怎麼看試作、實驗與風險
Boehm，1988提出螺旋模型，以風險驅動、逐步演進的方式引導軟體流程。磨人把這個思路用在範圍之外的提案：先找出最不確定的一點，只驗證那一點。
Flyvbjerg 與 Budzier，2011以一家服飾業者作為開頭案例：該公司決定遷移到單一系統，轉換期間一度無法出貨，後來認列了上億美元的損失。大型系統一次切換的後果可能很大，所以磨人在放大之前，先看小範圍的結果。
提案前先畫使用者路徑與示意畫面
整合各單位的路線資料時，磨人表示若單靠文件無法讓相關單位理解，會另外出線框圖輔助對接。路線資料牽涉多個單位，用畫面比文字更容易取得共識。
地圖體驗是另一個例子。磨人主動整理了一份體驗問題與可能解法的參考清單，並把 3D 地圖的相關資料分享給設計師，在既定設計之外探討更好的呈現。
戶外教育資源平臺的一項規劃功能，則是在既有維運之外提案。磨人先把使用者路徑畫出來，老師與民眾的體驗路徑分開，再貼出可操作的示意畫面與吉祥物概念。專案團隊以相關概念文章、使用情形、需求調查問卷和教案教材回覆，作為規劃功能設計的研究參考，雙方因此進入同一份規劃輸入。
這個階段先用具體的畫面與路徑驗證想法，再決定是否納入正式範圍。畫面出來之後，專案團隊可以直接指出要改的地方，討論從具體的內容開始。
依文中戶外教育資源平臺與廣告測試的做法整理；各階段的內容隨題目調整。
先小規模測試，確認可行再放大
專案團隊開放粉專廣告管理權限後，磨人先做廣告測試，確認成功，才排定開始擴大投放。
測試成功之後，磨人整理多款影片與圖片廣告的提案簡報與廣告素材資料夾，請專案團隊確認後向上級請示。確認完成即規劃下一輪投放，目標是當週定案、下週起算。
Thomke 與 Manzi，2014在哈佛商業評論指出，手上的資料無法預測顧客對創新的反應，要知道全新概念是否成功，必須做嚴謹的實驗。廣告測試就屬於這類實驗。
磨人在功能提案上沿用同樣的順序：先小範圍看結果，再談擴大。
自行設計的規則與方案，先寫明再討論
場域列表的推薦排序由磨人自行設計，並在固定的溝通管道公開說明。權重分數由三項依據加上少量隨機組成：資料完整度、累積瀏覽次數、搜尋字詞與分析標籤的比對度，三項的比重相同，隨機只佔一小部分。
另有一組穿插機制，把排序靠後的場域固定穿插到列表前段的幾個位置。縣市入口圖沿用同一邏輯，取當地推薦第一名場域的封面圖。目的是增加使用者發現新場域的機會與驚喜感。
規則寫明之後，每個權重與穿插位置都可以檢查，調整時也知道改的是哪一項。
設計階段的插畫運用，同樣是磨人主動提出的方案。磨人參考使用率高的大型平台不做大面積插畫的做法，改用象徵性的圖示插畫與輔助溝通的插畫，分別放在標頭、畫面兩側、分類與項目代表處，並邀設計師共同討論要畫什麼。這樣可以在不佔用文字內容的前提下增加平台識別度。
由客戶用畫面與結果決定是否納入
專案團隊請磨人針對年度計畫草案中的「推動方式」提出行銷建議。磨人把會議中談到的整體遊戲機制寫成條文：平台投稿經審核後，自動產生含使用者專屬角色的手機尺寸分享圖，可一鍵分享到個人社群，並附專屬邀請連結；好友註冊投稿後，分享者獲得積分，積分可用於角色蒐集、活動排名或抽獎資格。設計目的是引導使用者主動邀請朋友，形成自然擴散與長期參與。專案團隊表示期待這個機制能做起來，條文被納入計畫，並已提交給主管單位。
積分活動的獎項機制，由磨人專案窗口先擬出，分成依排名與依抽獎兩條線。工程師確認可行，並提醒確認獎項數量；專案團隊再核對平台與其餘活動之間的獎項分配，確認獎項數量無誤。先把規則寫成可實作的條件，目的是確認獎項與其餘活動不重複。有獎活動的帳務、防刷與預算控管，另見有獎活動平台的帳務、防刷與預算控管。
跨單位研商會議前，磨人提前貼出年度主視覺與簡報預覽，並輸出部分角色卡。專案團隊當日中午就拿去與專家討論。角色數量很多，磨人盡量讓每一隻差異化，期望形成記憶點。專案團隊對視覺與卡片的反應是喜歡，並帶入當日討論。
磨人專案窗口也主動發起教材徵集計畫中場域組別的功能擴充討論。專案團隊回覆時附上 2026 全臺戶外教育季場域與已進駐平台場域的交叉比對清單，日後徵件時，老師可以從清單中挑選場域撰寫教案。
磨人製作教材徵集的懶人包後，專案團隊確認並整理出需修改處與聯絡資訊。磨人修正後，另主動提議為專案團隊的社群專頁出一張封面，使用到徵集截止日。專案團隊表示懶人包好看，封面當晚換上並發佈貼文。
平台內的許多互動不在 GA4 的統計範圍，磨人在後台新增「流量分析」分頁，補上活動、場域、路線等平台內的細部數據，並可匯出。磨人也更新了流量總表，告知專案團隊搭配既有 GA4 資料可滿足報告需求。專案團隊回覆資料清楚，打算把排名前段的數據收進期末報告。
這幾次的共同點，是磨人先備好畫面、條文或清單，由專案團隊與主管單位判斷要不要採用。
提案與範圍管理的界線
範圍外的提案不等於無限追加。Komal 等，2020在 IEEE Access 發表的研究，以文獻回顧與專家訪談找出範圍蔓延的因子，再以問卷與 PLS-SEM 分析，發現這些因子與軟體專案成功度呈負相關。範圍失控會傷害專案成效，所以磨人在提案之外，同時守住範圍管理。
磨人把提案與正式範圍分開處理。提案階段的產出是畫面、清單與測試結果，每次驗證只針對一個待確認的問題。客戶決定納入之後，內容才寫進計畫或條文，進入正式範圍。客戶決定暫不納入時，既定範圍維持原樣。
納入之後的費用，涉及 AI 功能時的估算方式見AI 專案的費用怎麼估。評估廠商如何處理追加與範圍，見軟體外包廠商的評估表與簽約前查核項目。
- 磨人提出畫面、條文或測試結果每次只針對一個待確認的問題
- 專案團隊與主管單位討論
- 客戶決定納入寫進計畫或條文，進入正式範圍由專案團隊提交給主管單位
- 客戶決定暫不納入既定範圍維持原樣提案階段沒有改動正式內容
納入之前，既定的規格與設計不變。
不適合先做驗證的情況
以下情境不適合在約定範圍之外先做驗證：
- 做法已由法規或招標文件逐條規定，沒有可調整的空間。
- 上線日已近，既有功能的驗收還在進行，時間要留給正式交付。
- 要驗證的資料或權限尚未取得，驗證的結果沒有參考價值。
- 客戶端沒有人能在期限內看畫面並做決定。
遇到這些情境，先完成正式範圍，機會留到下一階段再提。
開始前要準備什麼
驗證前，客戶端先備好下列項目，驗證才能在短時間內完成：
- 想驗證的問題，用一句話寫明。
- 能看畫面並回覆的人，以及回覆的時間。
- 已有的研究輸入，例如調查問卷、使用情形、教案教材。
- 驗證需要的權限，例如廣告管理權限。
- 納入與否由誰決定，是否需要向上級請示。
這類提案多半發生在長期維運與平台建置的合作期間。
準備好以上幾點之後，可以先與磨人聯絡，說明想驗證的機會與專案目前的階段，磨人會先判斷驗證的範圍，再提出做法。
