用 AI 協助 UI 設計：從需求提示到可驗證的介面

請 AI 畫一個簡潔的查詢頁，可能會得到完整的輸入框、進度列和漂亮插圖。但它未必知道店家沒有配送服務，也未必知道訂單編號印在收據哪裡。提示的第一個任務，是提供正確的工作背景，而不是堆疊形容風格的詞。這對任何 UI AI 或設計 AI 都成立。

以下以原創洗衣店進度查詢頁示範，假設顧客要確認衣物是否可領取；這是假想專案，沒有真實顧客資料或測試成果。方法依 2026 年 9 月 14 日查閱的設計與使用者研究文件整理，工具功能、權限和價格另按所用產品確認。

先寫出使用情境與完成條件

在開啟生成工具前，先用一小段文字描述誰在什麼情況下做什麼事。例如：顧客在手機上拿著收據，希望輸入編號後知道能否到店領衣。完成條件是看懂目前狀態、營業時間及下一步，而不是停留在一張具有品牌感的首頁。

把已確認事實與尚待確認項目分開。店名和公開電話可以來自店家提供的資料；查詢需要哪些欄位、多久更新一次、過期訂單如何處理，則要先詢問負責人。沒有答案時請 AI 保留標記，不讓它自行補出客服承諾或取件規則。

Figma 的提示與設計脈絡文件都強調具體背景、目的及限制有助於工具理解任務。但資料寫進提示不代表答案已經正確，也不保證指定元件一定被採用。提示只是工作輸入，完成後仍要逐項對照需求與實際結構。

把提示組成可以核對的設計委託

原創提示可以寫成：為洗衣店製作手機版進度查詢草稿；顧客從收據取得編號，成功查詢後需看到處理中或可領取狀態。沿用指定按鈕樣式，使用繁體中文，未知店務資料用待確認文字標記。先列出需要補問的資訊，再提供畫面安排。

接著交代必要狀態：尚未輸入、格式錯誤、查無資料、載入中、成功及服務暫時無法使用。每個狀態都寫讀者需要理解什麼、可以做什麼。不要只要求加上錯誤提示，否則可能得到看似完整、卻沒有修正方法的紅字。

最後指定改動範圍與交付物，例如只建立查詢及結果頁，不新增會員、付款或行銷彈窗；提供畫面、元件對照和未解決問題。若工具只產出圖片，便無法直接驗證圖層或鍵盤行為；若產出程式，也要另查實際資料存取與錯誤處理。

用假設紀錄取代對生成結果的直覺認可

拿到草稿後，可以建立簡單表格，記錄設計決定、依據、風險及確認方法。例如：假設顧客找得到收據編號，因而只保留一個輸入欄位；確認方法是請可能的顧客看收據並完成查詢，而不是詢問 AI 這個設計是否直覺。

另一個假設是顧客理解處理中代表尚未開放領取。可以觀察參與者看到結果後準備做什麼，以及是否還會打電話確認。若多數人仍不明白，應先改進狀態說明與下一步，不急著換配色或加入動畫。這裡描述的是待執行的方法，並無調查數據。

請 AI 角色扮演顧客有助於列出可能遺漏的問題，但模型回答不是實際使用者的行為證據。整理出來的疑問仍標為假設，並透過店務資料、既有客服紀錄或有同意的使用者研究核對，不把模擬訪談寫成顧客已經認同。

修改時一次處理可辨認的問題

若首次結果在窄畫面擠成多欄，後續提示可以指定：保留原本欄位與文字，將結果資訊依狀態、領取說明、店家資訊排列；只調整版面，不更動查詢條件。這樣才能比較修改是否解決問題，並注意工具是否順手刪除必要內容。

每次保留變更前版本，記錄修改理由及影響範圍。將真實問題寫清楚，例如長店名換行後遮住按鈕，比要求再精緻一點更容易判斷成效。遇到工具反覆重做同一部分，也可以人工修正，再把需要保留的結果指定為下一輪基準。

投入工具前先刪除真實訂單、電話與可辨識顧客的截圖，改用虛構資料。核對上傳內容的使用條件、協作可見性及可用元件授權。已經設定不供模型訓練，仍不代表服務不會處理輸入，也不代表可以使用原本無權提供的素材。

1. 寫下顧客任務、完成條件、已知事實與待確認規則。
2. 提供畫面狀態、元件限制及交付要求，保留未知資訊標記。
3. 逐項比較草稿與需求，將設計決定整理成可檢查的假設。
4. 安排操作檢查與使用者任務，依觀察修正並留下交接紀錄。

從畫面檢查走到實際操作觀察

先做基本檢查：標題是否說明用途、欄位有無可辨識標籤、錯誤能否對應到欄位、文字是否清楚、放大後是否仍能閱讀。真正可操作的版本還要試用鍵盤移動焦點，確認焦點可見、順序合理且不會困住。圖片原型本身不能證明這些行為。

W3C 的 Easy Checks 是初步無障礙檢查方法，不是完整符合標準的證明。不能因為 AI 說已符合無障礙，或自動工具沒有警告，就宣稱網站已全面通過。依產品需要安排更完整的檢查，並記錄尚未驗證的項目及負責人。

GOV.UK 的使用者測試指引建議找實際或可能的使用者，提供中立任務並觀察操作。這個專案可以請對方確認衣物是否能領取，避免直接教他點某個按鈕。事前說明研究用途並取得同意；記錄困惑、錯誤與說明需求，避免把協助後完成當成獨立成功。

交接時留下決定的理由與驗證界線

最後整理需求版本、採用的畫面、必要狀態、資料欄位及未解決問題。對每項重要調整，說明根據的是店家確認、人工檢查還是使用者觀察。如果只有內部走查，就如實標示內部走查，不使用實測顯著改善等沒有證據的結論。

前端交接還要區分呈現和業務規則。查無資料的文案、再次查詢按鈕可以在介面規格中說明，但訂單讀取權限、查詢頻率和資料保存需由實作端另行設計。生成程式碼能跑出示範畫面，不等於已接上正確且受保護的服務。

工具換代時，這份需求與驗證紀錄仍然可用。保留可編輯檔、必要輸出及素材來源，讓接手者知道什麼可以改、什麼還待確認。AI 提示的價值，會落在團隊能否解釋並維護採用的介面，而不是提示本身有多長。

核對 Figma AI 的功能與資料權限

選擇線框與原型的驗證方式

了解 UI 與 UX 的工作分工

• AI 工具
• 教學
• AI 圖片、影片與聲音