錯誤層次結構和優先級突出顯示

1）為什麼需要錯誤層次結構

• 解釋出了什麼問題，
• 說明為什麼這很重要，
• 建議接下來要做什麼，
• 優先考慮一些錯誤。
• 錯誤層次結構降低了認知負擔，加快了修復速度，並提高了步驟轉換（註冊，支付，KYC）。

2）臨界水平模型（Severity）

1.Info（通知）-「配置文件不完整,可以稍後填寫。」不鎖定。

2.通知（註意）-「極限幾乎用盡了」。我們建議采取行動。

3.警告（警告）-「格式不匹配,部分保存數據」。可能會幹擾。

4.Error（錯誤）-「不正確格式/必填字段為空」。阻止特定動作。

5.批評（關鍵）-「付款被拒絕/安全風險」。鎖定腳本,需要立即采取行動。

• 一個屏幕-一個主狀態。
• 對於多個錯誤：我們從上方顯示關鍵,並始終滾動到第一個錯誤。

3）優先重點突出原則

1.視覺層次結構：顏色/圖標/厚度/對比度隨臨界值而增加。
2.空間接近度：相關字段/區域附近的錯誤。
3.焦點和滾動：自動滾動到第一個錯誤+焦點到問題領域。
4.一個主要呼叫：關於關鍵問題的常見橫幅/警報器+本地提示。
5.令牌序列：Info/Warning/Error的顏色/圖標/字體在整個產品中保持不變。
6.生活時間：局部錯誤-尚未修復；橫幅-在關閉/修復之前。
7.不要混淆狀態：「空」≠「錯誤」，「等待」≠「錯誤」。

4）視覺語言（UI令牌）

• Info-中性藍色/灰色，
• 通知是琥珀色/黃色，
• 警告是橙色的，
• 錯誤是紅色，
• Critical是飽和的紅色+對比度背景。
• 圖標：inf ⓘ o, notice, error/, success.

• 字段下方的Inline消息（最小邊框）。
• 每行/卡的排名。
• Page alert（橫幅）-常見/關鍵。
• 微動畫：柔和的外觀，沒有「抽搐」布局。

5）錯誤文本： 公式和示例

公式：不是+如何修復+（為什麼/限制）。

"日期格式不正確。以DD格式輸入。MM。GGGG"

"文件太大（最大10 MB）.下載較小的文件"

"驗證水平不足。通過KYC-需要~ 2分鐘"

"這筆款項被銀行拒絕。嘗試另一種方法或聯系銀行"

反模式：「錯誤400」，「出了問題」，幽默在壓力步驟。

6）復雜形式的層次結構（註冊/KUS/付款）

1.在blur上進行入線驗證：立即捕獲局部錯誤。
2.在submit上進行全局檢查：我們顯示「修復標記字段」橫幅和列表/錨點。
3.錯誤導航：鍵盤/制表,「跳到錯誤#1/#N」。
4.修復順序：首先是阻塞（Error/Critical）,然後是警告/通知。
5.保存上下文：輸入的數據不會因錯誤而丟失。

7）情景細節

7.1付款/結算

批評：供應商/銀行拒絕，可疑活動。
錯誤：地圖/IBAN字段，總和/頻率限制。
警告：網絡緩慢/超時等待。

文字： "付款被銀行拒絕。嘗試另一種方法或聯系銀行。委員會沒有註銷"

7.2 KUS/安全

批判：偽造的文檔/被阻止的國家/多帳戶。
錯誤：不可讀文件/日期不匹配。

文字： "文件的照片模糊。在良好的照明下下載更清晰的圖像"

7.3搜索/過濾器

這不是錯誤，而是零結果。

文本： 「沒有結果」{query}。移除「提供程序：X」過濾器或嘗試「{alt}。」［重置過濾器］"

8）可用性（A11y）和技術要求

錯誤聲明給屏幕閱讀器：aria-live=關鍵的「assertive」，其他的「polite」。
錯誤字段：aria-invalid=」true」，aria-describedby到消息。
焦點轉移到第一個錯誤；制表順序保留邏輯。
WCAG AA的對比；圖標不會取代文字。
文本必須大聲朗讀，而不會失去意義。

9）本地化和法律準確性

避免行話和文化隱喻。
商定術語（詞匯表）：「付款被拒絕」，「限制超過」，「驗證」。
以本地格式指定時間和限制：「最多15分鐘」，貨幣/日期。

10）質量指標

字段/步驟的錯誤率（遇到錯誤的用戶比例）。
修復時間（修復第一個錯誤之前的平均時間）。
錯誤發生後（有多少人在沒有糾正的情況下離開）。
每個用戶/會話的錯誤重復性（記錄）。
按錯誤類型請求支持。
在層次結構更改之前或之後轉換步驟。

• 自動滾動和焦點vs僅顏色/文本。
• 原因vs的確切表述是常見的。
• 背光順序（首先是橫幅→直線）vs（僅限直線）。
• 在錯誤旁邊添加「顯示要求」鏈接。

11）發行前的支票清單

• 每個錯誤都有級別（Info/Notice/Warning/Error/Critical）。
• 顏色/圖標/容器對應於水平。
• 有滾動到第一個錯誤和焦點轉移。
• 消息解釋了什麼/如何/原因。
• 術語與術語表相同；已驗證本地化。
• 可用性：aria屬性，對比，可讀性大聲。
• 數據不會因錯誤而丟失。
• 「零結果」和「等待」狀態不構成錯誤。

12）「之前/之後」示例"

日期表

之前： 「錯誤400」

之後： "日期格式不正確。使用DD。MM。GGGG"

付款

之前： 「付款沒有通過」

之後： "付款被銀行拒絕。嘗試另一種方法或聯系銀行。委員會沒有註銷"

KYC

之前： 「未通過文件」

之後： "無法識別文檔。下載照片沒有眩光，可以看到角度和文字"

零搜索（不是錯誤!）

之前： 「錯誤：找不到任何東西」

之後： ""live roulette"沒有結果。移除High limit過濾器或嘗試roulette。［重置過濾器］"

13）設計系統組件

``

Пропсы: `message`, `severity`, `ariaDescribedBy`, `compact`.

渲染：文本+圖標，顏色為「severity」。

``

Пропсы: `title`, `description`, `severity`, `actions[]`.

選項：「inf | o notice |警告| error | critical」。

``

錨點到字段的錯誤列表,鍵盤導航,「跳到第一」。

"（邏輯）

字段/形式/步驟，優先級，模式（例如JSON-Schema）上的規則，消息本地化。

14）快速短語模板

15）嵌入過程

與驗證邏輯同時設計文本。
將行存儲在組件旁邊的i18n中,進行轉換。
在PR支票表中：水平匹配，aria屬性的存在，正確的本地化。
定期對指標和支持反饋進行錯誤評論。

最終的spargalka

分級：Info →Critical。
在視覺和焦點上顯示優先級。
簡短而具體地解釋更正。
不要稱空虛為錯誤。

測量和改進： error rate, Time-to-Fix, drop-off.