為什麼做產品不只是把畫面切出來

本文記錄 2026 年 10 月 23 日當時的合作表單與流程；現行委託範圍為平面設計、UI/UX 與前端開發，依確認範圍報價，詳見合作頁。

合作表單有姓名、Email、幾個文字欄位和送出按鈕，看起來很容易描述成一項切版工作。但真正要交付的，不是讓這些元件排在一起，而是讓有需求的人說明現況，讓接手的人有足夠資訊判斷下一步。

欄位問什麼、哪些問題可以先不知道、送出後看到的訊息代表什麼，都會改變這件事能不能完成。這些決定不會在畫面切好之後自動補上。

以下以本站在 2026 年 10 月 23 日使用的合作表單為例。我會沿著一份詢問的工作路徑，區分頁面已經提供的部分，以及仍要另外確認的接收與後續處理。

先定義這份表單要幫人完成什麼

本站合作頁的起點是「不用先準備完整提案」。相對應地，表單先詢問目前卡住的地方、希望先推進的事，以及手上已有的資源與限制，而不是要求來訪者一開始就交出完整規格。

這不是單純換幾句比較親切的標籤。它決定第一次接觸要取得哪一種資訊：先知道問題和可動用的條件，才能討論值得做的那一段。

如果頁面邀請人帶著尚未釐清的需求來，欄位卻要求每個人都填出精確預算、固定時程與完整功能表，前後承諾就不一致。使用者可能只好亂選一個答案，接手的人再花時間猜它有多確定。

所以我會先寫清楚這次互動要支持哪個決定，再回頭看欄位。不是畫面裡有空間，就多放一個可以收集的問題。

必填與選填，決定了什麼時候可以開始

目前表單的稱呼、Email、卡住的地方、希望先推進的事，以及已有資源是必填。合作方向、參考連結、時間與預算則是選填；方向、時間和預算也保留不確定或先討論的選項。

這些設定可以沿著後續用途來讀：

資訊	想支持的工作	不應自行補成什麼
稱呼與 Email	知道如何稱呼與聯絡對方	已驗證身份，或 Email 一定能收到信
現況、優先事項與資源	判斷問題、可開始的範圍與限制	已經確認的完整需求規格
合作方向、時程與預算	提供討論的背景	已接受的報價、交期或合作承諾

表格是對欄位責任的整理，不是讀者研究或成效量測。這份必填組合是否對每個來訪者都剛好，仍需要實際使用與回饋；程式裡標上 required，不能代替這個產品判斷。

「尚未確定」也應該被當成有意義的狀態。它表示還需要討論，不應在後續整理時被悄悄換成一個看似完整的日期或金額。

畫面上的欄位，要接到真正送出的資料

本站表單使用原生 form，以 POST 送往外部表單端點。可見的標籤與控制有對應關係，欄位也保留 name，例如 stuckPoint、firstPriority 和 availableResources。畫面上的問題因此能對應到送出的資料名稱，而不只是一組排版文字。

這份關係需要在修改時一起保護。如果文案改成「希望先完成什麼」，接收端卻仍把內容理解成完整專案規格，即使畫面沒有壞，交接仍可能走偏。

原生的 required 與 type="email" 可以協助瀏覽器先檢查必填與格式，但不等於驗證寄件者身份或信箱可送達。MDN 也明確指出，瀏覽器端驗證不能取代伺服器端的資料與安全檢查。[4]

把接收工作交給外部服務，是一個實作邊界。它沒有讓驗證、通知與資料後續用途自動消失；若沒有檢查服務端，就應該把那些結果留在未確認，而不是從 HTML 屬性推導出來。

成功提示，只能代表它真的知道的事

目前表單設定送出後回到合作頁，透過 form=success 或 form=error 選擇顯示的狀態。頁面腳本讀到 success 時會隱藏表單、顯示成功訊息；讀到 error 時則顯示失敗提示。

但這個畫面判斷只讀取網址參數。直接開啟帶有 form=success 的合作頁，也會進入相同狀態；頁面本身沒有因此取得一份經過驗證的接收憑證。

因此，「成功提示有顯示」「外部服務已接收」「通知已到信箱」和「有人已讀過並準備回覆」，必須分開確認。唯讀檢查可以證明頁面如何呈現成功或錯誤，不能順便替服務端與收件者作證。

這裡沒有實際送出測試詢問，也沒有查閱服務端收件或 Email。本篇能說明的是目前頁面的判斷依據；若要確認整條送出路徑，仍需要在獲准的測試下，核對一份明確的測試資料是否真的到達。

沒有 JavaScript 時，原生表單仍保有提交的 HTML 結構，但這套網址參數提示目前由腳本切換。不能把「表單不是 client-only」擴大成所有無腳本回饋都已完整處理。

第一版先交付一段可運作的工作，不必假裝整個流程都已自動化

本站這個例子不是專案管理系統。表單先收集合作詢問，頁面文案再交代會閱讀內容、以 Email 回覆；這不代表系統已經能自動估價、排定時程或承諾合作。

如果第一版只需要讓雙方開始討論，就不必為了看起來完整，先加入沒有依據的即時報價或自動交付狀態。但接收之後由誰處理、回覆前還要確認什麼，仍應該有明確的責任，不因為沒有畫成一張管理介面就被省略。

我會用一份詢問走完整段工作來看第一版：對方知道要寫什麼，資料以可辨認的欄位送出，結果提示不超出證據，接手的人知道如何繼續。哪一段仍需要人工，哪一段還沒驗證，就保留在對應的位置。

這也是畫面之外的產品工作。它不要求每個前端開發者獨自承擔所有職能，而是要求把依賴的決定找出來，交給有責任與資訊的人確認。否則，一張看似完成的表單，可能只把真正要處理的問題往後移了一步。

Sources

[4] https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Forms/Form_validation — MDN — Client-side form validation