Day6_我理想中的網頁，應該要是什麼樣子？

前言

拿到需求規格後，我以前很容易直接想：「登入頁要放在左邊還是右邊？按鈕要用什麼顏色？」後來才發現，這些都不是第一個要回答的問題。UI 設計真正的起點，是把使用者要完成的事情、操作順序、權限限制與失敗情境，逐項轉成看得見的畫面。

這一篇會沿用 Day3_在開始設計之前，先看看User Story 的需求規格，示範如何從 User Story 拆出頁面，而不是憑感覺畫一套看起來漂亮的介面。

第一步：先確認系統要解決什麼問題

Day3 的產品目標寫得很清楚：這是一套公司內部使用的專案管理系統，團隊要能管理專案成員與 Task Item，並追蹤指派對象、狀態、交付期限及留言。由此可以先整理出兩條主要操作路徑：

1. 一般成員登入後，找到自己參與的專案，再查看、篩選及更新有權限處理的 Task。
2. 後台管理員或 Admin 登入後，管理使用者、專案成員及 Task Item。

規格沒有要求 MVP 提供工時、成本、甘特圖或工作量統計圖，所以現階段不需要為了「可視化」硬塞一張儀表板。對這個版本來說，清楚的狀態標籤、交付期限、指派對象、篩選條件與空資料提示，就是最實用的資訊呈現。圖表可以留到後續真的有統計需求時再設計。

第二步：從角色與權限決定畫面能做什麼

UI 不能只畫正常情況。Day3 將系統角色分成 User、Administrator、Admin 與 Viewer，專案內又有另一組專案角色。這表示同一個 Task 清單，使用者看到的按鈕不一定相同。

例如，沒有修改權限的 Task，其 checkbox 必須停用；要求後端逐筆檢查專案權限、指派關係與狀態轉換。因此草圖除了要畫「批次修改」按鈕，也要畫出 Disabled 狀態及權限不足時的錯誤訊息。前端隱藏按鈕只是減少誤操作，真正的授權仍由後端負責。

第三步：從 User Story 拆出頁面

接著把每一則 User Story 對應到使用者會看見的頁面。這一步的重點不是追求完整配色，而是確認欄位、操作與頁面之間的關係。

登入畫面（Sign In）

畫面需要帳號、密碼、登入按鈕及一般性的登入失敗訊息，不能用錯誤文字透露帳號是否存在。未驗證或停用的帳號也要有適當提示。

註冊畫面（Sign Up）

除了帳號、密碼、確認密碼與 Email，還要呈現必填、格式錯誤、帳號重複及密碼規則。註冊成功不是直接登入，而是引導使用者收取驗證信。

使用者清單（User List）

只有 Admin 可以進入。清單要能依帳號、姓名、Email 與系統角色搜尋，並顯示帳號狀態。啟用、停用或調整角色前，也要考慮「不得停用系統最後一位 Admin」的限制。

使用者設定（User Setting）

這張草圖可以承接使用者資料與偏好設定。使用者若選擇「不再顯示批次確認視窗」，之後必須能在這裡重新開啟。若此頁也要讓 Admin 編輯角色，最好把個人偏好與系統權限分區，避免一般使用者誤以為自己可以調整角色。

專案清單（Project List）

一般使用者只看得到自己所屬且未封存的專案，管理者則可以查看全部專案。搜尋欄位、空狀態訊息及專案狀態都要在草圖階段標出來。

專案詳情（Project Detail）

頁面要呈現專案基本資料、Project Owner、成員及專案角色。移除成員時，如果對方仍有未完成的 Task，就不能直接完成操作，因此確認視窗必須告訴管理者先重新指派工作。

工作清單（Task Item List）

清單包含 checkbox、Task 編號、標題、交付期限、狀態、建立者及指派對象，還要提供關鍵字搜尋、篩選、排序及分頁。這些條件要同步到 URL query string，使用者從詳情頁返回時，才能回到原本的位置。

工作詳情（Task Item Detail）

除了完整 Task 資料，頁面還需要狀態與交付期限的編輯區、留言紀錄、刪除確認及版本衝突訊息。一般成員與後台管理員可編輯的欄位不同，草圖也應分別標示。

目前這組草圖還少了 Email 驗證與重新寄送、批次修改確認視窗，以及 Loading、Empty、Validation、Forbidden、Error 等狀態。可以在開發前請你的AI工具幫你檢查缺陷，正式開發前補齊。

第四步：UI 草圖有特定工具去畫會比較好嗎？

沒有哪一套工具適合所有階段。剛開始討論需求時，用紙筆或 PowerPoint 畫低擬真草圖就夠了；當畫面需要重複元件、頁面跳轉或多人協作，再換成專門的設計工具會比較省時間。如果希望使用開源工具，可以從下面幾套開始比較：

Figma 當然也是常見的 UI 設計工具，但它是商業雲端服務，不屬於這裡整理的開源工具清單。工具不是重點，草圖能否清楚表達欄位、狀態、權限與操作結果，才會直接影響後續實作。

這個專案目前先用 PowerPoint 畫草圖，原因很單純：手邊就有，而且足以確認資訊層級。只是交給 AI 工具時，不能只丟一張圖片就期待它自行補完規格。最好把草圖、Day3 的 User Story、頁面路由、欄位規則與權限限制一起提供，並明確指出哪些畫面狀態尚未完成。

總結：把草圖與規格交給 AI，用 Vue 3 實作

畫完草圖後，下一步才是請 AI 工具協助產生 Vue 3 前端。提示內容可以這樣寫：

請使用 Vue 3 實作這組 Project Management Web 畫面。以 Day3 的 User Story 與驗收條件為需求來源，草圖只用來確認版面。請先整理頁面、元件、路由、角色權限與 Loading、Empty、Validation、Forbidden、Error 狀態，再分階段實作。不要自行加入 MVP 以外的甘特圖、工時或成本功能。

這樣做的目的，是讓 AI 知道「畫面長什麼樣子」之外，也知道每個操作為什麼存在、誰可以使用，以及失敗時該怎麼回應。產生的 Vue 3 程式碼仍要逐項對照 User Story 驗收，草圖和 AI 都不能取代最後的測試。

參考資料

• Penpot 官方網站與功能說明
• Excalidraw GitHub Repository
• Pencil Project 官方網站
• draw.io GitHub Repository
• Quant-UX GitHub Repository
• Figma Terms of Service