WithZeng/design-skills

網站設計

從 Scientify 網站重新設計（2026-10）學到的經驗：設計只有在展示草稿並獲得核准後才算真正落地，強制單一頁面系統套用到每個區塊，而且驗證能找出由於動態庫所引入的對比度與標記錯誤。

工作流程與閘門

1. 需求摘要。 收集產品、目標受眾、區塊、真實的樣本資料，以及使用者喜歡的 1–2 個參考網站。如果使用者沒有，從 references/ui-references.md（圖庫、真實產品 UI 庫、元件來源）挑選 2–3 個符合網站類型的參考網站，並展示給使用者核准。將參考網站的畫面截圖並儲存為 --ref 圖片；當被要求推薦時，顯示編號的截圖以及 2–3 個組合供選擇（方法：ui-references，「擷取參考」）。
2. 先草稿，後程式。 在使用者核准草稿之前，永遠不要為了視覺變更而編輯程式碼。使用 image-gen 技能。順序：
   1. 如果方向不明確，每個方向一張概覽圖（通常是 2 張）；使用者先挑選一個方向，然後再進行細節工作。接著一張全頁長圖（1024x1536）來確定頁面系統。
   2. 每個區塊/面板一張全解析度的細節圖。
   3. 子頁面，然後是互動分鏡圖（每個互動 3–4 格）來說明動態。 分批展示，收集反饋，疊代修改。提示範本： references/draft-prompts.md。
3. 建置 只針對已核准的草稿，並放在預覽路由後面，直到使用者說要取代正式頁面。模式： references/build-patterns.md。
4. 驗證 在任何提交/拉取請求之前： references/verification.md。
5. 將草稿和截圖存放在專案中已加入 gitignore 的草稿資料夾（例如 tmp/design/vN/），每輪一個資料夾，提示文字與圖片一起儲存。

頁面系統（消除「割裂感」的方法）

一個頁面感覺像一個整體，當每個區塊都重複使用相同的系統時。從核准的草稿決定系統的值，然後將其寫入每個提示和程式碼代碼中：

• 整個頁面使用統一的背景處理；避免每個區塊各自發明自己的色帶或漸層。
• 一個統一的區塊模組（容器、圓角、填滿、邊框、內距、寬度）以及其內部少量佈局樣式，各區塊間重複使用。
• 統一字級系統：所有區塊標題使用相同的大小與粗細，一個內文樣式，一致的間距。
• 一個標誌性元素承載藝術方向（通常在首屏），其他部分在佈局上保持低調，但仍回應互動。這個元素來自需求摘要，而非範本：請參閱下面的「藝術指導」。
• 所有展示的產品 UI 必須是同一個應用程式（相同的導覽、主題、資料），以使頁面讀起來像是同一個產品。
• 調色盤要足夠精簡，以維持系統一致性（某個網站使用純粹的單色）；標誌保留其原始顏色。在所有地方使用真實的品牌標誌，永遠不要用一個方塊中的字母作為預留位置。
• 內容：使用產品領域的真實資料（合理的人名、數字和時間），並為文件和物件決定一個命名慣例（每個專案決定一次）；不要使用假文字、假推薦或統計數據、以及行銷流行語。

應用程式 UI 與驗證頁面

相同的閘門機制適用於產品內部，但使用不同的參考資料和權杖：

• 參考資料來自真實的產品 UI（例如 Refero、同類產品網站上的產品截圖、用於聊天/代理程式的元件說明文件），而不是登陸頁面圖庫。
• 重複使用應用程式自己的權杖和元件；不要匯入行銷網站的調色盤。首先固定一組少量的共享基本元素（面板、頁面容器寬度、對話框寬度、分段控制），然後使用這些元素重新造型畫面。
• 登入/註冊頁面搭配託管的驗證小工具（例如 Clerk）：透過其外觀 API 和在地化功能設定樣式，並檢查建置模式中的常見陷阱（「驗證頁面」）。

藝術指導（空間維度與動態）

從網站自身需求設計空間維度與動態部分，然後像其他視覺元素一樣製作草稿。不要重複使用之前網站的配方或固定數值。

1. 從需求摘要推導出來。 訪客必須獲得的一個核心概念是什麼（產品實際運作、轉變、規模、精準度、平靜感）？目標受眾是誰？品牌調性是什麼？目標裝置與效能預算為何？標誌性元素應該展現這個核心概念，理想情況下使用真實的產品。
2. 探索 2–3 個選項 符合頁面系統與調性，例如：透視的產品視窗、具有視差的分層深度、講述工作流程的滾動驅動場景、插圖或 3D 物件、資料/視覺隱喻，或是具有豐富微互動的平靜扁平頁面。每個選項製作一張圖片，若是動態則製作分鏡圖；由使用者挑選。
3. 規格化，然後建置。 針對選定的選項記錄：什麼東西會移動、觸發條件（載入、滾動、指標、時間、點擊）、靜止狀態、減少動態的版本，以及手機版版本。在瀏覽器中根據核准的草稿調整角度、時間與強度，而不是根據範本。
4. 檢查成本。 它不能損害可讀性、對比度、版面穩定性或載入時間；它必須在沒有 JavaScript 的情況下以及減少動態時也能優雅降級。

豐富互動，來自函式庫

靜態頁面顯得廉價。積極使用元件與動畫庫，讓每個互動都栩栩如生：

• 每個狀態都有回饋：懸停、按下、聚焦、載入/執行中、成功/錯誤、出現/消失、版型變化。在互動分鏡圖中規劃這些，而不是事後才想。
• 優先使用建立完善的現成元件，而非手寫效果。將每個互動對應到一個模式，然後從為此專案選擇的庫中挑選元件（references/ui-references.md「互動模式」）。
• 產品展示要有動態：真實任務正在進行、結果送達、數字變化、場景切換。
• 保持目的性：動態解釋狀態或將目光吸引到變化之處。過度的裝飾性效果屬於行銷頁面，不屬於工作畫面。在所有地方尊重減少動態設定。

選擇函式庫

為專案挑選元件與動畫庫；沒有強制要求。

• 現有專案：使用它已經有的庫；只在有缺口時才新增一個庫，而且永遠不要新增與現有庫重疊的庫。
• 新專案：根據專案類型、框架和需求選擇（標準與候選庫在 references/build-patterns.md「選擇函式庫」中）。除非有明確的理由，否則保留一個基礎元件系統和一個主要動畫庫。
• 優先選擇可以作為可編輯原始碼安裝到專案中（透過註冊表/CLI 或複製）的來源，而不是不透明的套件，這樣元件才能遵循專案的權杖。

辛苦得來的規則（詳細內容在 build-patterns）

• 每個文字色調在它所處的背景上必須通過 4.5:1 的對比度；檢查放在面板填滿上的最淡色調，而不只是頁面背景。
• 首屏進場不使用透明度淡入效果，也不使用透明度來表示「非活躍」狀態——輔助功能審核會在中間動畫執行時捕捉到並標記對比度問題。使用純 transform 的進場效果和顏色變化。
• 動畫包裝器不能放置在 <ul>/<ol> 與 <li> 之間；應在 <li> 內部進行動畫。
• 滑動標籤：將標籤放在一個 relative 的 <span> 中，並放在一個 absolute 的藥丸形狀背景之上；不要使用 -z-10 + isolate。
• 計數器在伺服器端渲染最終數字，且僅在進入視口時才進行動畫。
• 在多語言網站上，每個可見的字串（包括展示用視窗和重播工作階段中的示範 UI）都必須經過 i18n。
• 網格需要明確的單一欄位 / minmax(0, 1fr) 軌道，並且頁面根元素需要裁剪水平溢位，以避免在手機上發生溢位。