寫問題前先定義任務
明確誰填寫表單、當時掌握什麼、下一位處理者必須作出什麼決策，以及哪些證據能證明結果。沒有下游用途的欄位只會增加填寫負擔，並不能改善流程。
- 用一句話說明填表者的任務。
- 明確下一負責人及其要作出的決策。
- 只保留支援路由、行動、證據或報表的欄位。
- 區分系統已知資訊與填表者必須輸入的資訊。
表單設計指南
清晰易用的業務表單設計指南
設計清晰的業務表單，使用目的明確的欄位、條件區塊、有效校驗、無障礙錯誤提示、行動裝置適配佈局，以及下一負責人可直接採取行動的資料。
建立表單及其業務流程
將設計轉化為可執行的 Jodoo 表單、工作流程、紀錄檢視和儀表板
Jodoo 讓經過培訓的業務管理員在一個可配置應用程式中建立表單、條件規則、計算、角色權限、送出紀錄檢視、簽核工作流程和儀表板。
開啟 Jodoo 表單製作工具設計順序
從使用者任務和下一項決策開始
使用者能準確完成表單，下一負責人無需補齊缺失上下文即可行動，才算表單成功。
按使用者可以回答的順序對欄位分組
先從熟悉的上下文開始，把相關問題放在一起，並將依賴前面選擇的細節延後顯示。簡短且含義明確的區塊，比堆滿欄位的長頁面更容易瀏覽。
- 從使用者熟悉的身份、申請、據點、資產或事項上下文開始。
- 把日期、金額、單位和證據放在其所解釋的問題附近。
- 僅適用於部分情況的問題應使用條件分割槽。
- 讓填表者先檢查結果，再顯示確認與送出操作。
為實際執行工作的人編寫標籤和幫助文字
使用目標使用者熟悉的詞語。標籤應說明要輸入什麼；只有在能防止常見錯誤時，幫助文字才需解釋邊界、示例、格式或原因。
- 使用“要求交付日期”等明確標籤，不要只寫“日期”。
- 在數值或編碼欄位旁標明單位和可接受格式。
- 避免使用填表者無需瞭解的政策、實施和系統術語。
- 定稿佈局前檢查翻譯後標籤的長度。
透過驗證幫助填表者修正紀錄
驗證應阻止不可用的送出，並說明如何修正。不要把每個欄位都設為必填，也不要只重複欄位標籤而不給出指導。
- 只要求填寫目前階段所需的資料。
- 在必要處驗證範圍、格式、日期、合計值和跨欄位關係。
- 把錯誤提示放在欄位旁，並保留使用者填寫的其他答案。
- 將不確定或異常的值送審，不要強行製造虛假的精確性。
設計完成與退回狀態
送出後體驗仍應繼續。確認已收到的內容，在適當時顯示負責人或下一步預期，並讓填表者清楚理解退回修改要求，同時不暴露內部資料。
- 編寫有用的確認訊息和參考編號。
- 保留送出的證據和決策歷史。
- 紀錄被退回時，準確說明必須修改的內容。
- 讓更正與原紀錄保持關聯，而不是建立重複紀錄。
用真實的行動裝置資料和異常進行測試
空白的桌面預覽看不出長標籤、翻譯、校驗、照片、檔案、簽名、計算和條件分支帶來的問題。請在使用者實際使用的裝置上測試完整表單。
- 涉及現場工作時，應使用手機尺寸視口和真實裝置測試。
- 填寫所有長欄位、附加證據、觸發校驗並開啟條件區塊。
- 送出一條正常紀錄，並退回一條不完整紀錄。
- 讓下一負責人無需口頭解釋即可根據送出資料採取行動。
表單設計檢查清單
釋出前逐層檢查
在真實表單上使用檢查清單，並加入實際數值、角色、裝置和一個退回案例。
層級需要回答的問題需要檢查的佐證常見失敗情況
任務填表者要完成什麼任務？一句話任務和明確目標對象表單照搬內部資料庫，而不是圍繞使用者任務設計
決策下一位負責人要做什麼決定或行動？明確負責人、路徑、截止日期和結果欄位已收集，卻沒有明確負責的下一步行動
欄位每個欄位是否都支援行動、證據或報表？從現場到決策的路徑必填或重複問題過多
佈局使用者能否在行動裝置快速瀏覽並完成表單？用較長真實內容做手機端測試區塊過長、過早換行、送出操作被隱藏
邏輯無關問題是否已隱藏，必填資訊是否清晰可見？正常路徑與條件路徑可避免的錯誤發生後才提示必填欄位
驗證使用者能否理解並修正錯誤？無效範圍、格式、日期和缺失證據測試籠統的錯誤提示或丟失的答案
退回路徑複核人能否準確指出需要更正的內容？退回原因、責任欄位和保留的歷史再次送出會產生重複紀錄
報表指標能否向下鑽取到背後的源工作紀錄？從儀表板向下鑽取到紀錄圖表只顯示數量，沒有負責人或行動
實際測試
透過四輪簡短檢查改進一份表單
從任務和資料設計推進到行動裝置填寫與下游行動。
只有真實使用者能夠完成表單、下一角色無需重新拼湊上下文就能繼續處理時，表單才算真正可用。
刪除沒有實際用途的欄位
將每個欄位對映到路由、行動、證據或報表，並刪除其餘欄位。
- 明確目標對象。
- 明確決策。
- 標記系統已知值。
重寫結構和標籤
按自然順序整理剩餘問題，並替換內部術語。
- 使用簡短分割槽。
- 補充單位和示例。
- 檢查翻譯後的長度。
測試行動裝置、邏輯和錯誤處理
在手機尺寸檢視中使用真實數值、檔案、照片、計算和條件分支測試。
- 觸發每一種錯誤。
- 讓送出按鈕保持可見。
- 測試最長路徑。
測試送出與退回
讓下一負責人複核紀錄、退回一個問題，並完成更正後的案例。
- 保留歷史。
- 確認角色權限。
- 開啟儀表板向下鑽取。
範本
明確設計規則後再比較不同表單
申請、巡檢、登記和現場報告需要不同的術語與證據，但都可用以任務為先的設計方法避免多餘問題和無法使用的紀錄。
最適合開始使用的範本將本指南應用程式到真實請求表單
開啟採購請求表單，在桌面端和行動裝置完成填寫，退回一條不完整紀錄，並在修改欄位前檢查送出值、工作流程、負責人佇列和儀表板。
把表單設計原則應用程式到建立、移動收集和自動化
開啟工作表單和簽核示例
常見問題
表單設計常見問題
好的表單設計是什麼樣的？
良好的表單設計幫助特定目標對象準確完成明確任務，只收集下一負責人能使用的資料，清楚解釋錯誤，適配實際裝置，並讓回覆與行動和報表保持關聯。
一份表單應該有多少個欄位？
沒有適用於所有表單的固定數量。保留目前任務和決策所需欄位，僅部分情況需要的資訊應放在條件分割槽或後續工作流程步驟中。
每個欄位都應該必填嗎？
不需要。只有目前階段缺少該欄位就無法路由、處理、驗證或彙報紀錄時，才將其設為必填。過多必填欄位會增加虛假或低品質答案。
表單在行動裝置應如何工作？
使用清晰分割槽、便於點選的控制元件、簡潔標籤、合適輸入型別、儘量少的鍵盤輸入、就近說明、明顯的證據控制元件、可見錯誤提示和清晰送出操作，並在真實手機尺寸檢視中測試實際資料。
表單送出後應該發生什麼？
確認接收、分配紀錄、路由複核或簽核、顯示缺失或逾期工作、保留意見和決策、建立有人負責的跟進，並讓儀表板可從每個訊號向下鑽取到源紀錄。