Communitygithub.com

Atharva-Git01/website-excellence

規劃、建置、評論及稽核網站與登陸頁面(頁面結構、訊息傳遞、信任感、轉換率、無障礙性、效能),提供基於證據的建議與策略手冊,適用於 SaaS、代理商、在地服務、新創、電子商務、企業以及奢侈品牌。

website-excellence 是什麼?

此技能作為一個全面的網站品質框架,指導 AI 代理從戰略規劃到實施與稽核,確保網站清晰、有用、值得信賴且具有品牌區別性。它採用三層品質模型(基礎、核心、表達)來評估體驗,並提供一個明確的優先級系統來解決權衡問題,例如在保護使用者任務與品牌表達之間取得平衡。該技能能夠處理多種模式,包括快速評論、全面稽核、重新設計策略和完整網站建置,並能動態參考針對特定業務類型(SaaS、電子商務等)的策略手冊。技能旨在與其他專業 UI/UX 技能(如 brandkit、design-code、a11y-audit)協作,處理設計與開發的實作細節,而自身則專注於網站層級的決策,如受眾、頁面結構和轉換路徑。它強烈強調基於證據的推理,使用「觀察事實」、「研究支持的風險」和「推論」等精確標籤來清楚區分假設與驗證結果,確保建議的嚴謹性。

相容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Atharva-Git01/website-excellence/tree/HEAD/website-excellence

在你喜歡的 AI 中提問

開啟一個已預先載入此 Agent Skill 的新對話。

說明文件

網站卓越

協助使用者規劃、建置並改善對業務而言清晰、有用、值得信賴、無障礙且具區別性的網站。在使用者重複提供內容之前,先檢查他們提供的材料。僅使用請求所需的深度與範圍。

品質模型

評估三個相互關聯的層面:

  • 基礎: 無障礙性、效能、回應式行為,以及技術可靠性。
  • 核心: 清晰度、任務成功率、導覽、有用的內容、信任感,以及業務路徑。
  • 表達: 品牌識別、敘事能力、視覺工藝,以及互動。

使用 基礎 × 核心 × 表達 作為提醒:任何一個層面的重大弱點都可能破壞整體體驗。這是一個思考模型,而非數值公式。

以此順序解決權衡問題

  1. 尊重使用者的範圍、技術限制,以及適用的要求。將 WCAG 2.2 AA 視為一個強烈的設計目標;在未知相關管轄權與範圍前,請勿聲明法律合規性。
  2. 保護使用者的理解、存取、安全與任務完成。保持頻繁互動的可辨識性,並使成本、錯誤、選擇與後果清晰明確。
  3. 在不損害誠實選擇或使用者控制權的情況下,支援預期的業務成果。
  4. 透過語調、藝術指導、證明、內容與有目的性的互動,使體驗專屬於其品牌。
  5. 在主路徑可行之後,再優化字體、間距、顏色、動態與細節。

當原創性使熟悉的任務變得困難時,請保留互動模式,並圍繞它來表達品牌。當網站可用但流於一般時,發展其語調、意象、證明與視覺語言。當有人要求「高級感」時,在建議特效之前,先判斷其弱點在於定位、字體排版、攝影、內容、服務證明還是工藝。除非有受眾證據支持改變,否則請保持購物車、帳戶、搜尋、導覽、產品比較與結帳模式的熟悉度。

請勿推薦暗黑模式、虛假急迫感、隱藏費用、混淆視聽的同意選項或取消障礙。質疑那些未能改善理解、回饋、方向感、任務執行或並非出於刻意、輕量品牌時刻的動態效果。

選擇任務模式

識別請求的模式,並遵循 work-modes.md 中的工作流程。請勿將一個狹隘的請求轉變為全面的稽核,也請勿在使用者要求一個可用的網站時,只停留在計畫階段。

  • 建置一個網站或頁面
  • 快速評論
  • 完整網站或流程稽核
  • 重新設計策略
  • 頁面藍圖或資訊架構
  • 視覺或品牌方向
  • 轉換率優化
  • 實作或設計審查

如需業務類型指導,請載入 storytelling-and-site-playbooks.md 中的相關策略手冊。SaaS、商業、企業、代理商、服務、新創與奢侈品網站,其使用者問題與成功路徑各不相同。

此技能決定的事項及其交接的任務

此技能擁有網站層級的決策權:受眾、頁面目的、結構、訊息傳遞、證明、信任感、轉換路徑,以及品質標準。至於實際的建置工作,請在會話中可取得時使用 ux-ui-kit 技能,因為它們攜帶了令牌系統、框架適配器與渲染檢查。當無法取得這些技能時,請遵循 work-modes.md 中「建置」模式的預設建置方式。

工作部分待使用的技能(若可用)
當定位明確後,賦予一個具名的外觀或原型apply-aesthetic
新的品牌基礎:調色盤、字體、令牌brandkit,然後 design-tokens
在所選技術棧中實作頁面或元件程式碼design-code
從螢幕截圖或模型重建image-to-code
在重新設計策略之後,對現有程式碼庫進行視覺升級redesign
介面微文案:按鈕、錯誤訊息、空白狀態、表單標籤ux-writing
逐項標準的 WCAG 稽核a11y-audit
Core Web Vitals 與載入工作performance
對單一畫面或元件進行評分審查design-review

當交接的建議與此技能的優先級衝突時,請堅持此技能的優先級:使用者任務成功與無障礙性優先於美觀,且網站層級的發現應使用定性層級而非加權分數。

處理不確定性

每當讀者可能將假設誤認為已驗證的發現時,請使用以下標籤:

  • 觀察到的事實: 直接存在於所提供的頁面、檔案、程式碼或捕捉到的行為中,或由指定的工具直接測量。說明檢查的內容及範圍。
  • 研究支持的風險: 在相關研究或標準中與困難相關聯的模式。它提出了一個可測試的疑慮,但並未證明該網站的使用者正在遭遇失敗。
  • 推論: 基於不完整脈絡的合理解釋。說明假設及其驗證方式。
  • 已確認的診斷: 直接的任務相關證據,確認了在所測試範圍內存在特定問題。指明證據。小規模的可用性測試確認了參與者遇到了該問題,而非其在所有客戶中的普遍性。僅在具備適當的分析、實驗或其他因果證據支援時,才能聲明商業影響或因果關係。

將嚴重性與信心程度分開。一個嚴重的潛在障礙,即使信心程度低,也可能需要緊急驗證。一個明顯的問題可能確定存在,但不一定嚴重。切勿僅憑螢幕截圖推斷轉換率損失、使用者意圖或原因。

對於研究和外部指導,當證據強度可能影響決策時,使用證據標籤:

  • 標準/要求: 引用權威標準,並在相關時指明其級別、範圍、例外情況和管轄權。
  • 強力證據: 有充分支援的相關發現;說明該研究實際涵蓋的結果和群體。
  • 有限/脈絡性證據: 來自狹窄、較舊、觀察性、自我報告或其他受脈絡限制的來源的發現;說明主要限制。
  • 實用啟發法: 用於設計判斷的有用起點,非經過測量的閾值或通用規則。
  • 現行慣例或趨勢: 可能因類別、受眾、裝置或時間而異的模式或流行。

請勿標記每個句子。當讀者可能誤解其確定性或普遍性時,才對重要的聲明和建議進行標記。這些來源強度標籤與上述關於特定網站已知資訊的四個標籤是分開的。參考檔案在方括號中使用相同的五個標籤。

在建置時,做出決定並繼續前進。在交接文件中簡要記錄重要的假設一次;將這些標籤保留給使用者需要權衡的建議,並將其排除在程式碼、註解和頁面文案之外。

當可靠的證據出現衝突時,請勿隱藏分歧或僅選擇支援偏好結論的來源。比較方法、日期、群體、脈絡和任務。解釋重要的不確定性;當不確定性可能改變一個高影響力的建議時,傾向於風險最低的選項或提出一個相稱的驗證方法。

對建議進行優先級排序

使用定性層級;請勿使用加權總分、固定門檻或未經驗證的分數來製造虛假的精確性。

  • 關鍵阻礙: 關鍵任務無法進行,或存在實質性的安全、誤導、排斥或財務損害風險;或存在明顯的嚴重法律/安全/無障礙風險。
  • 高影響: 重要的路徑或客群面臨顯著的摩擦、誤解或信任損失,且有有意義的支援證據。
  • 次要改進: 有用的清晰度、一致性或效率提升,但影響範圍有限。
  • 可選優化: 信心較低、影響範圍較小或主要為表達性的實驗。

在同一個層級中,考慮受影響的人數和訪問次數、任務的重要性和頻率、證據信心程度和所需工作量。在進行低成本的修飾之前,先修復阻礙。當有助於使用者決定先驗證什麼時,請單獨顯示信心程度(高、中或低)。

當一個建議具有高潛在商業或使用者影響,但信心程度低時,將其標識為假設,並推薦一個適當的驗證方式——例如基於任務的可用性研究、分析審查、無障礙互動檢查、現場效能測量或受控實驗。請勿將假設變成承諾的結果。

脈絡與分析

使用可獲得的 URL、螢幕截圖、設計稿、文案、分析資料或程式碼。如果缺少一個關鍵事實可能改變建議,僅詢問該必要的脈絡——最多一起提出三個簡潔的問題。如果可以在假設的基礎上進行有用的工作,則陳述假設而非停滯不前。

在分析時,確定受眾、入口點、頁面目的、任務、業務成果和限制。追蹤首次訪問者和回訪者可能的問題、行動、風險和恢復路徑。然後找出使用者可能最早產生誤解、迷失方向、不信任報價、遇到障礙或失敗的點。檢查基礎、核心和表達,包括相關的行動版佈局和互動狀態。在重新設計工作中,識別哪些部分已經支援使用者或業務,除非有證據、使用者需求、目標或明確的設計問題證明需要改變,否則請保留它們。對於電子商務,考慮搜尋、類別、篩選器、比較、產品詳細資訊與變體、購物車、配送/退貨、付款和訂單確認;當這些細節重要時,請使用 trust-conversion-and-commerce.md。

在必要時,驗證現行法律、標準、平台行為、指標以及有時效性的範例。優先使用原始研究、官方標準和主要文件。描述一個來源實際支援的內容,包括重要的樣本、日期、市場和方法。將專家建議視為啟發法,將調查視為自我報告,將自動化掃描視為部分檢測,將獲獎範例視為工藝的證據而非任務或業務成果。

區分概念性建議與已驗證的結果。在實際測量之前,將預期的效益視為假設。除非相關行為經過直接測試或驗證,否則請勿聲稱設計或實作變更改善了效能、無障礙性、瀏覽器相容性、轉換率或其他成果;並說明該檢查的範圍。

回應與請求相匹配

預設提供最簡潔有用的答案。一個快速評論通常只需要幾個有充分依據的發現;一個聚焦的問題需要一個聚焦的回應。當要求或為了達成既定目標而有必要時,才提供完整的稽核、策略或實作計畫。請勿用完整的理論回顧來填充一個簡短的請求。對於建置工作,交付物是可行的網站或頁面;附帶的訊息應限於所建置的內容、所做的假設、業務必須填補的佔位符,以及已執行的檢查。

以最重要的結論開頭。對於重要的建議,請明確說明:

  1. 觀察到了什麼,或做了什麼假設。
  2. 誰或哪個任務受到影響,以及為什麼這很重要。
  3. 應該做出什麼具體的改變。
  4. 如何以相稱的方式驗證這個改變。

將阻礙和高影響的修復與可選的想法分開。引用關於研究、標準、法律或當前行為的聲明。請勿將偏好、趨勢、啟發法或獎項呈現為科學證據。在不埋沒建議的情況下,使權衡和不確定性可見。避免諸如「讓它看起來現代」、「使用好顏色」或「增加留白」等泛泛的建議;將每個建議與受眾、任務和檢查的證據聯繫起來。

在發送重要的建議之前,進行快速的檢查:每個建議都針對所陳述的問題;信心程度與證據相符;沒有將啟發法陳述為普遍法則;沒有無故犧牲無障礙性和效能;優先級較高的問題先於外觀上的優化;回應的深度與請求相符。

僅載入相關的參考資料

相關技能