成功、失败、警告只用颜色区分，会带来哪些真实问题

很多团队做状态设计时，会默认大家都懂那套颜色默契：绿色就是通过，红色就是失败，黄色就是提醒。问题是产品不是海报，状态一旦被看错，后面接的不是审美分歧，而是业务动作。该重试的没重试，该停止的没停止，该跟进的被当成已经完成，这才是真正贵的地方。

颜色一失效，语义就会瞬间塌掉

最典型的场景是后台列表、审批流、账单中心和运维面板。表格里一排小圆点，绿黄红各一个，设计稿很干净，评审时也没人觉得有问题。等真上了线，用户在强光下看、投影上看、旧显示器上看，或者本身就不容易区分某些颜色，这时候“状态已表达”这句话就站不住了。

更麻烦的是，很多系统把关键动作也绑在颜色语义上。比如绿色按钮默认代表“可以继续”，红色 tag 代表“失败已结束”，黄色 badge 代表“稍后处理”。一旦用户把黄色当绿色，警告就会被当成已完成；把红色当成普通强调色，失败任务就可能被忽略一整天。这里的损失不是抽象的无障碍分数，而是漏工单、错放款、误发货、错发通知。

真实业务里，误判代价往往比大家想得大

颜色只表达状态，最容易出事的不是营销页，而是运营和协作工具。因为这些系统节奏快，用户不会停下来研究每个角标是什么意思。

举个很常见的例子：客服后台把“发送成功”“发送失败”“部分发送”做成三种颜色小字。客服同事如果只扫一眼颜色，很可能把“部分发送”看成“已经完成”，结果后续没补发，最后锅落到一线。再比如财务审批里，黄色如果既表示“待确认”又表示“风险提醒”，那就不是视觉问题了，而是语义定义从根上乱了。

所以这类问题不能只靠“把对比度做高一点”解决。对比度当然重要，但它解决的是看见；状态设计还要解决看懂、看准、看完以后知道该做什么。

设计系统该修的，不是某一个页面，而是状态语义本身

真正有效的修法通常发生在设计系统层。别让每个页面自己发明一套成功、失败、警告的表达方式，不然今天补个图标，明天换种文案，后天又冒出一个只靠底色区分的新组件，问题会一直回潮。

一套更稳的做法通常包括这些东西：

1. 每个状态都配固定文案，而不是只给颜色 token。
2. 状态组件自带图标或形状差异，让用户不用盯颜色猜。
3. 高风险状态要有下一步动作提示，例如“重试”“查看原因”“联系管理员”。
4. 同一种黄色不要同时承担“提醒”“处理中”“低风险异常”三种含义。
5. 在列表、图表、徽标、按钮这些高复用组件里统一落地，不让业务页面自由发挥。

你会发现，一旦把状态语义补厚，色弱用户当然更轻松，但受益的绝不只是这一类用户。所有在移动端匆忙操作、在差屏幕上工作、在复杂后台里连续处理任务的人，都会少掉很多误判。

延伸阅读

如果你想继续顺着这条线往下拆，可以接着读 为什么无障碍审查不该把“模拟器截图”当成全部答案、招聘、驾驶、学校场景之外，普通 SaaS 为什么也该重视色觉无障碍 和 用在线色觉测试做团队培训，最适合讲清楚哪些概念。这几篇更适合拿来和状态设计、组件规范一起看。