来源：The boring screens that run the world · Chijindu Amadi
核心结论
不是所有摩擦，
都应该被消灭。
B 端后台设计的目标，不是无条件地让所有操作变得更快、更顺，而是根据任务的风险与错误成本，判断哪些环节应该减少阻碍，哪些环节必须让操作员停下来确认。
无意义摩擦
不能帮助用户完成任务，只会增加理解、寻找、输入或操作成本。
应该尽量减少 ↓保护性摩擦
在高风险或不可逆节点增加确认，让用户识别错误、理解后果并避免损失。
应该放在正确位置 ↑去除无意义摩擦，
在正确的位置加入保护性摩擦。
两种摩擦
判断它是否真的
改善了决策质量。
- 信息层级混乱，重要内容难以找到
- 重复输入系统已经掌握的信息
- 操作路径很长，却没有增加安全性
- 提示文案含糊，下一步无法理解
- 页面状态不明确，不知道操作是否成功
- 为了形式感拆散本应同时查看的信息
它增加的是认知负担，
不是判断机会。
- 提交前集中展示关键确认信息
- 突出真正具有唯一识别力的字段
- 要求主动确认，而不是默认同意
- 条件未满足前禁用最终提交
- 对不可逆操作说明具体后果
- 提供撤销、二次确认或冷静期
它不是阻碍，
而是把判断机会还给用户。
对象误认
不要把识别责任，
完全交给用户。
金融和加密货币产品中，很多对象看起来相似，实际含义却完全不同。币种、网络、账户、交易方向与超长地址，都可能在高压操作中被混淆。
TN7xm4R9qU8pF2kL6aC3vD0bW5hJ9Qe2首尾字符已突出请确认网络与地址来源；条件允许时，可先进行小额验证。
- 突出地址首尾关键字符
- 同时展示币种、网络、地址和到账数量
- 网络不匹配时给予高优先级警告
- 首次地址增加二次确认
- 最终页汇总方向、金额、手续费和收款对象
- 提供地址簿、白名单、小额验证或风险标签
信息密度
数据密度，
不等于设计失败。
交易员、贷款审核员、合规人员和运营人员往往需要同时查看大量信息。过度留白和过度拆页反而会割裂上下文，使用户无法判断业务全局。
- 用层级、分组和对齐组织信息
- 采用紧凑但稳定的间距系统
- 统一数字、单位与小数位
- 保持表头、关键列和筛选条件可见
- 用克制中性色维持整体密度
- 让高饱和颜色只服务异常、风险和待处理状态
完整上下文
操作之前，
先让人理解全局。
后台的职责不是只提供一个按钮，而是让操作员理解当前对象、历史状态、风险因素和业务后果。
当前任务与处理进度
客户、账户或交易对象
操作、审核与审计记录
异常状态和待处理项目
截止时间、剩余时长、SLA
对资金、权限和后续流程的影响
设计师不能只围绕单个页面进行美化，
而要理解完整工作链路、决策依据与错误后果。
评估标准
后台设计的价值，
最终要回到业务结果。
视觉质量依然重要，但它服务于信息理解、操作效率和风险控制。真正需要追踪的，是错误、时间、损失与风险发生了什么变化。
错误选择、误提交是否下降
单项任务是否更快完成
错误交易与损失是否减少
重复劳动和返工是否下降
违规操作是否减少
发现与处理是否更及时
人工支持需求是否下降
记录是否完整且清晰
它获得了多少点赞并不重要。
重要的是：它帮助业务避免了哪些错误、损失和风险。
作品集表达
B 端项目，
不必假装成展示型 UI。
比过度美化更有说服力的，是用完整因果链证明设计判断与业务价值。
谁在什么环境下遇到了困难？错误造成了怎样的时间、资金或合规成本？
对象相似、上下文缺失、状态不清，还是高风险节点过于顺滑？
在哪里减少无意义摩擦，又在哪里加入保护性摩擦？
错误率、处理时间、资金损失或合规风险发生了什么变化？
可复用检查
下一次设计或评审时，
先问这四个问题。
摩擦是否合理？
是否区分了无意义阻碍与必要的风险保护？高风险操作是否提供二次确认、撤销或恢复机会？
能否防止对象误认？
名称、账户、网络、地址与交易方向，是否突出真正具有唯一识别力的部分？
上下文和风险是否清晰？
操作员能否同时看到判断所需的信息，并快速识别异常、风险和时间压力？
结果能否被衡量？
设计是否降低了错误率、处理时间、资金损失、重复劳动或合规风险？
B 端设计的成熟度，不在于界面有多“顺滑”，而在于设计师能否区分应该消除的阻碍与必须保留的停顿。
A designer’s case for taking admin tools seriously · Chijindu Amadi · 2026.08.25